Mobile App Performance: Cutting Cold Start Time and App Size

Users do not file bug reports about slow apps. They just stop opening them. App performance is one of the few product qualities that everyone notices and almost nobody articulates, which is why it tends to lose every prioritisation argument against a new feature until retention starts sliding.

The two metrics that hurt most are cold start time, meaning how long the app takes to become usable after a tap on an icon, and download size, meaning how many people abandon the install before it finishes. Both are measurable, both are fixable, and both are usually neglected because they are nobody's specific job.

This guide covers how to diagnose and fix mobile performance problems on iOS and Android, in the order that produces the largest gains for the least engineering time.

The Three Numbers That Matter

Before optimising anything, agree on what you are measuring. Most teams argue about performance because they are each describing a different number.

• Cold start. The time from launch to the first screen a user can meaningfully interact with, not the time to first pixel. A skeleton loader that appears instantly and then sits empty for four seconds is a slow app wearing a costume.
• Download and install size. The compressed size a user sees in the store, which drives abandonment particularly on constrained networks and older devices. This is a growth metric as much as an engineering one.
• Interaction responsiveness. Frame drops during scrolling and delay between a tap and a visible response. Users experience this as the app feeling cheap, even when they cannot name the cause.

Measure all three on a mid range device that is three or four years old, not on the newest phone in the office. Your median user is not holding your hardware.

Measure Real Devices, Not Simulators

Simulators run on desktop hardware and will happily tell you everything is fine. Field data from real installs is the only trustworthy source, so instrument launch time and key interactions in your analytics, and report the ninety fifth percentile rather than the median. The tail is where churn lives.

A Real World Example: The Onboarding That Never Finished

Consider a consumer app that has grown steadily and then plateaus. Installs are healthy but day one retention is weak. The team assumes the onboarding flow needs redesigning and prepares a redesign sprint.

Before building anything, they instrument launch. The data shows a cold start of over five seconds at the ninety fifth percentile on mid range Android devices, against roughly one and a half seconds on the flagship devices the team carries. They also find the download is large enough that a noticeable share of installs on slower connections never complete.

The causes turn out to be mundane. Three analytics and crash reporting SDKs all initialise synchronously on the main thread before the first screen renders. The app fetches remote configuration at launch and blocks the interface until it returns, with a generous timeout. Every image asset ships at three resolutions inside the binary, including ones only used in a rarely visited settings area. A font library adds several megabytes for two typefaces.

The fixes take about a week. SDK initialisation moves off the critical path and starts after the first screen appears. Remote configuration loads with cached defaults so the interface never waits for a network call. Images move to on demand delivery, and unused typeface weights are removed. Cold start on the test devices drops to well under two seconds, and the download shrinks by roughly half.

Day one retention improves without a single change to the onboarding design. The redesign sprint was going to solve a problem the team did not have, a pattern also visible when teams choose the wrong platform strategy, which is why the tradeoffs in our comparison of progressive web apps versus native apps for startups matter so much at the outset.

The Seven Step Performance Programme

• Instrument first. Add timing around launch phases, key screen loads and critical interactions, and send them to your analytics with device model and network type attached. Every later step is guesswork without this baseline.
• Audit what happens before first render. List every operation that runs at launch: SDK initialisation, database migrations, configuration fetches, authentication refresh, feature flag loading. For each one, ask whether the first screen genuinely needs it. Most do not, and can be deferred or run in the background.
• Never block the interface on the network. Cache the last known good configuration and render immediately with it, then update quietly when the fresh response arrives. An app that launches instantly with slightly stale data beats one that waits, in every user study and every retention chart.
• Cut the binary. Enable code shrinking and resource shrinking, remove unused assets and localisations, use vector assets where possible, move large media to on demand delivery, and audit dependencies for libraries pulled in to serve a single function. Store level tooling reports the size impact per component, which makes the biggest offenders obvious.
• Fix the list before you fix anything else. Most perceived slowness lives in scrolling. Recycle views properly, avoid layout work inside scroll callbacks, decode and resize images off the main thread at the size they will be displayed, and paginate rather than loading everything at once.
• Make offline the default assumption. Reads should come from a local store first and sync in the background, which makes the app feel instant on poor connections rather than merely tolerable. The patterns in our guide to offline first mobile app architecture apply directly, and they solve perceived performance as much as connectivity.
• Add a regression gate. Track launch time and binary size on every release and alert on a meaningful increase. Performance is not a project you complete, it is a budget you defend, and without a gate it will erode one convenient dependency at a time.

Where Cross Platform Frameworks Change the Calculus

Cross platform stacks add a runtime and, on some configurations, a startup penalty. That is often an acceptable trade for the delivery speed they buy, but it does mean the launch path deserves closer attention: defer bridge heavy work, keep the first screen simple, and use native splash handling so the transition is seamless. Verifying this across the device matrix is part of a broader cross platform mobile app testing strategy rather than a one off measurement.

Key Benefits

• Higher install completion. A smaller download converts more of the users you already paid to acquire, which improves the economics of every marketing channel at once.
• Better day one retention. First impressions of speed strongly shape whether a user opens an app a second time, before they have had any chance to value the features.
• Improved store visibility. App stores factor technical quality signals into ranking, so performance work compounds with the discovery gains covered in our app store optimisation guide.
• Longer device support. An app that runs well on a four year old mid range phone is available to a substantially larger market, which matters enormously in India and other mobile first regions.
• Lower support load. A meaningful share of tickets described as bugs are actually timeouts and slow screens on weak connections.

Perceived Speed Versus Measured Speed

Two apps with identical launch timings can feel completely different, because users judge responsiveness by whether the interface acknowledges them rather than by when the work finishes. That gap is worth exploiting deliberately.

Show real content as soon as any of it is available rather than waiting for a complete response, so a partially populated screen replaces an empty one. Render cached data immediately and refresh it quietly underneath. Respond to a tap within a hundred milliseconds even if the underlying action takes longer, using an optimistic state that reconciles when the server confirms. Reserve layout space for images so content does not jump as assets load, since visual shifting reads as instability even when nothing is slow.

None of these techniques make the underlying operation faster, and none of them substitute for the engineering work above. What they do is remove the dead time where a user sits looking at nothing, which is the part of the experience that actually drives abandonment. Measure both: instrumented timings tell you what to fix, and session recordings or usability sessions tell you where the app still feels slow despite good numbers.

Mistakes to Avoid

Optimising on flagship hardware. The office device fleet is unrepresentative. Keep two or three mid range test devices and treat their numbers as the real ones.

Adding a splash screen to hide the delay. Users are not measuring milliseconds, they are measuring how long until they can act. A longer branded screen does not help.

Letting SDK count grow unchecked. Each analytics, attribution, chat and crash tool adds startup work and binary weight. Review them quarterly and remove the ones nobody has queried in six months.

Treating performance as a one off project. Without a size and launch time budget enforced in the release process, every gain is temporary.

Conclusion

Mobile performance work has an unusually good return, because the fixes are mostly deferral and deletion rather than redesign. Moving initialisation off the launch path, caching configuration, shrinking assets and fixing list rendering will get most apps into a healthy range within one focused sprint.

The discipline is in keeping it there. Instrument the numbers, publish them where the team sees them, and gate releases on a budget. A fast app is not a feature you ship once, it is a standard you hold, and users reward it long before they can explain why. If you are planning a performance uplift or a rebuild, our mobile app development services team treats launch time and binary size as release criteria rather than afterthoughts.

Frequently Asked Questions

What counts as a good cold start time?

Under two seconds to an interactive first screen on a mid range device that is three or four years old is a reasonable target. Measure time to interactivity rather than time to first pixel, because a skeleton loader that appears instantly and then sits empty still feels slow to the person holding the phone.

Why does app download size matter so much?

Install abandonment rises with download size, particularly on constrained mobile networks and cheaper devices. Since you have usually already paid to acquire that user, size reduction improves the economics of every marketing channel at once, and it also widens the range of devices where the app runs comfortably.

What should we fix first?

Audit everything that runs before the first screen renders. Analytics and crash reporting SDKs initialising synchronously, blocking remote configuration fetches and eager database work are the usual offenders, and deferring them off the launch path is normally the fastest large win available.

Do cross platform frameworks make apps slower?

They can add a startup penalty because a runtime has to initialise, though this is often an acceptable trade for delivery speed. The mitigation is to keep the first screen simple, defer heavy work off the launch path and use native splash handling, then verify the result on real mid range devices rather than simulators.

How do we stop performance regressing later?

Track launch time and binary size on every release and alert when either crosses a threshold. Performance is a budget you defend rather than a project you finish, and without a gate in the release process it erodes one convenient dependency at a time.