[Due for payment 2026-03-30] [Due for payment 2026-03-13] Investigate slow app cold start (11s to reach Settings page)

[mountiny]

Nikki reported that opening the app (cold start, force closed) on v9.3.20-6 took 11 seconds to reach the Settings page. Her account has fewer than 1,000 reports.

Eliran inspected the logs and BootSplash appears to be taking most of the time (~7.86s for ManualAppStartup span). Sentry profiling from Hubert showed several contributors including derived values computation, SidebarOrderedReportsContextProvider, SearchContextProvider, and an Onyx job.

Cold start P90 metric has been flat around 5.2s for multiple weeks (target: 3s). Warm start keeps improving but cold start remains stuck.

We need to investigate Nikki's traces and the BootSplash flow to identify what's blocking the cold start and find actionable improvements.

Sentry profile link: https://expensify.sentry.io/explore/profiling/profile/app/cba294ae869b4de7aae3aac5ea78

Slack thread: https://expensify.slack.com/archives/C05LX9D6E07/p1771428213490469

Platform: iOS (HybridApp mode)

Issue Owner

Current Issue Owner: @sosek108

[sosek108]

Status

On friday and today I've checked three leads where I thought the significant delay can be found:

Today I've investigated 4 clues I had:

1. LHN is calling unnecessary for requiresAttentionFromCurrentUser — while rendering items for LHN application tries to calculate requiresUserAttention field via requiresAttentionFromCurrentUser(). This field is however already defined in reportAttributes derived values so same value is calculated twice. This leads to unnecessary CPU usage for large accounts
2. OnyxDerived reportAttributes recomputing during render — reportAttributes.ts:188/224 reduce loop keeps firing while React is mid-render, causing re-render cascades
3. computeReportName / getReportActionText — report name computation + markdown parsing (Parser.htmlToText) on every render cycle

Results

1. fix to this issue gives as little ~10ms gain for about 1200 reports. Fix to this issue is small so I'd suggesst to implement this
2. No meaningful increase
3. No meaningful increase

[sosek108]

Sorry for no updates. I've been divided into several tasks. Unfortunately profile from this run ends after ~6seconds, so we have no knowledge about rest 5seconds.

During these 6 seconds there are common works being performed - these occurs on all high traffic accounts. I did not find anything Nikki-account-specific.

Functions that takes a lot of miliseconds:

• 514ms getReportsToDisplayInLHN (SidebarUtils.ts:293)
• 470ms recomputeDerivedValue (OnyxDerived/index.ts) — full LHN recompute on every Onyx event
• 396ms shouldReportBeInOptionList (ReportUtils.ts:9458)
• 337ms requiresAttentionFromCurrentUser (ReportUtils.ts:4320)
• 253ms getIOUReportActionToApproveOrPay (IOU/index.ts:10466) — O(n×m) scan, called per report
• 210ms NavigationRoot (NavigationRoot.tsx)
• 176ms SearchContextProvider (SearchContext.tsx)
• 172ms getAdaptedStateFromPath — nav config
• 122ms ExpensiMarkWithContext#htmlToText — text parsing per report name

[sosek108]

Here I will be posting updates to my local tests, based on 1076 reports:

396ms shouldReportBeInOptionList

• called 3827 times for total of ~300ms

514ms getReportsToDisplayInLHN

• called 4 times for total of ~200ms

[sosek108]

I've posted a proposal that aims to reduce getReportsToDisplayInLHN calls from 4 to 1. Automatically shouldReportBeInOptionList call count is also reduced.

Tomorrow I'll check other functions from the list