Users judge an app in the first couple of seconds, and the first couple of seconds are usually spent on work that did not need to happen yet. Cold start is one of the few performance numbers that every user experiences on every install, and it is one of the easiest to let drift, because it degrades a little with each feature rather than breaking outright.
Measure the cold start you actually ship
A warm start on a flagship device over office wifi is not the number that matters. Measure a genuine cold start, on a mid-range device, on a slow connection, with the analytics and crash reporting that ship to production actually enabled - those SDKs are frequently the largest contributor and are usually absent from local testing.
Move work off the startup path
Most initialisation does not need to complete before the first frame. Feature flags, analytics, remote config, session restoration and cache warming can nearly all be deferred, parallelised or made lazy. The question for each one is not whether it is needed, but whether it is needed before the user sees anything.
- Third-party SDKs initialised eagerly at launch
- Network calls blocking the first render rather than filling it in
- Database migrations run synchronously on the main thread
- Fonts, images and config parsed before they are displayed
Render something truthful immediately
A screen that appears instantly and fills in is perceived as faster than a spinner held for the same duration, and it is a better experience because it gives the user somewhere to look. Skeletons should match the shape of the content that is coming, so the layout does not jump when the data lands.
Avoid showing an empty state that later turns out to have content - that reads as a bug even though it is a loading artefact.
Put a limit on it and defend it
Startup time regresses one small addition at a time, and no single pull request looks unreasonable. A budget checked automatically turns a slow drift into a conversation at the moment it happens, which is the only point at which it is cheap to address.
Nobody files a complaint about launch time. They just open the app slightly less often, and the reason never appears in a bug report.