The single most under-monitored metric in most mobile apps is cold-start time: the seconds between tapping the icon and seeing usable content. It decides more about retention than almost any feature you could add.
Most apps we audit are at least 30% slower than they could be on cold start. Most app owners haven't measured it in months.
Why it matters more than people think
The data is uncomfortable for app owners who haven't thought about this:
- Apps with cold-start times over 2 seconds lose roughly 20% of users within the first week, mostly to silent uninstall.
- Apps over 4 seconds lose closer to 40%.
- Apps under 1 second have retention curves that are visibly different from everything else.
The reasons are unsurprising once you think about them. Mobile use is interstitial — between meetings, in queues, on commutes. The user has 30 seconds of attention. If your app spends a third of that on a launch screen, they're going to look at something else.
Google and Apple know this and are tightening the requirements. The Play Console now flags apps with cold-start P95 over 5 seconds as low-performing. Apple's launch metrics in Xcode Organizer are increasingly visible to developers and reviewers.
What's actually slow
Three categories of slowness in cold starts:
1. App initialisation
Everything that happens before your code runs main(). Dynamic frameworks load, dependency injection wires up, observability libraries phone home, app delegate runs setup.
On a fresh install, this is often 800ms–1500ms by itself. Mostly invisible to product owners because no-one shows them the numbers.
2. First-screen rendering
The work to draw the first screen the user sees. If that screen does a network request before rendering, you've added the round-trip time to your cold start. If it does five network requests in series, you've added five round-trip times.
The worst pattern: a "splash screen" that does network work in the background, then transitions to the actual first screen which also does network work.
3. Authentication and session restoration
Apps that require a session check on every cold start are often the slowest. If your session restore takes 600ms and you do it before showing anything useful, every user pays it on every cold start. They probably shouldn't.
Fixes that work
The biggest improvements we've made for clients, in rough order of leverage:
Lazy-initialise third-party SDKs
The third-party SDK ecosystem is full of "initialise me first" libraries that don't actually need to be first. Analytics, error tracking, A/B testing frameworks, push notification services — all can typically be deferred until after the first frame is drawn. Done properly, this alone often shaves 300–600ms off cold start.
Show cached content first, refresh in the background
If you have any data to show that's even 30 seconds old, show it immediately. Fetch fresh data after the user can see and interact with the cached version. Most apps have data this could apply to.
Skip the splash screen for return users
A splash screen is fine on first launch — it covers initialisation that has to happen. On subsequent launches, the user has been here before. Show them their content, not the brand.
Move auth restoration off the critical path
Restore the auth token in the background while showing the previous session's content. If the restoration fails, then prompt for re-auth. Most users come back authenticated; optimise for the common case.
Optimise the binary
App bundle size correlates with cold-start time, especially on lower-end devices. Strip unused architectures, code-shrink, drop bundled assets you don't need on every install. iOS App Thinning and Android App Bundle do some of this automatically but most apps still have low-hanging fruit.
Measure on real devices, not just the M-series Mac in the office
Cold-start time on a 2020 budget Android phone is very different to a 2024 iPhone Pro. The 50th percentile of your user base is using something closer to the former. Use real-user monitoring (Firebase Performance, Sentry, etc.) to see the distribution.
What to instrument right now
If you want to start improving cold-start without committing to a project:
- Add real-user cold-start monitoring with breakdown by device class.
- Set a target P95 for cold-start — something like "P95 under 2 seconds on devices from the last 3 years".
- Treat regressions against that target as bug priority, not enhancement priority.
- In every release postmortem, look at whether cold-start moved.
The compound effect from twelve months of small wins is usually significant. Apps we maintain consistently show cold-start improvements year-over-year because we keep an eye on it.
How we help
We do performance audits as standalone engagements and as part of broader maintenance retainers. The audit produces a list of fixes ranked by effort vs likely impact, plus the monitoring infrastructure to confirm improvements once shipped.
If your app feels slow to start and you want a senior team's view, book a discovery call.
