How to improve app performance: metrics, targets and 8 fixes

Improving app performance means faster starts, smooth scrolling, fewer crashes and ANRs, and graceful behavior on slow networks, measured on real devices. This guide lists the metrics and their targets, eight concrete steps, and a startup trace where deferring SDKs and decoding images at view size cut the median cold start from 3.4 to 1.6 seconds.

What does it mean to improve app performance?

Improving app performance means making a mobile app start faster, respond to touches without delay, scroll smoothly, use less memory and battery, and handle slow networks gracefully, measured on the devices your users actually have. It is a narrower job than general app optimization: the goal is not more sign-ups directly, but removing the technical reasons people give up before they get there.

Performance work starts with measurement. Without a baseline from real devices you cannot tell whether a change helped, and you will optimize what is easy to see on a developer's phone instead of what hurts users on a three-year-old mid-range device.

The mobile app performance metrics that matter

How to improve app performance in eight steps

1. Measure in the field, not only in the lab

Lab tools (Android Studio Profiler, Xcode Instruments, Macrobenchmark) find causes; field data from real users tells you where the problem is and how big it is. Collect cold start, crashes, ANRs and memory from production builds, split by device model, OS version and app version.

2. Cut cold start work

List everything that runs before the first frame: SDK initialization, database migrations, config fetches, dependency injection graphs. Defer anything not needed for the first screen to after the first frame or to first use. On Android, Baseline Profiles let the runtime precompile hot code paths.

3. Keep the main thread free

Move disk access, JSON parsing, image decoding and network calls off the main thread. On Android enable StrictMode in debug builds to catch accidental main-thread I/O; on iOS use the Main Thread Checker and hang reporting.

4. Fix rendering jank

Flatten deep view hierarchies, avoid layout passes inside scroll callbacks, use recycled lists, and size images to the view instead of decoding full-resolution files. Profile the screens with the highest share of slow frames first.

5. Control memory

Release large bitmaps when screens disappear, cap in-memory caches, and look for leaks in long sessions. Out-of-memory kills often appear as crashes on low-RAM devices only.

6. Make the network forgiving

Cache responses, request only the fields a screen needs, compress payloads, set timeouts and retries with backoff, and show cached content while refreshing. Test every critical flow on a throttled connection.

7. Shrink the app

Remove unused resources and libraries, use Android App Bundles and asset catalogs so devices download only what they need, and compress images.

8. Guard against regressions

Add startup and frame benchmarks to CI, and compare field metrics for every release in its first days. Performance regresses one dependency at a time.

Find the slow screen with field data first, then reproduce it with a profiler.

Worked example: halving a cold start

A shopping app (sample data) had a median cold start of 3.4 s on Android, and 7.8 s at the 90th percentile on devices with 3 GB of RAM. A startup trace showed:

Median cold start fell from 3.4 s to 1.6 s, and the 90th percentile on 3 GB devices from 7.8 s to 3.9 s. Next-day retention for new Android users in the two weeks after the release rose from 22% to 25%; other changes shipped in the same release, so the startup fix is a likely but not proven cause.

Common mistakes

• Testing on a flagship phone over office Wi-Fi. The slowest 10% of your users are on very different hardware and networks.
• Looking at averages. Use the median and the 90th percentile; averages hide the long tail that drives uninstalls.
• Initializing every SDK on launch. Third-party SDKs are a frequent cause of slow cold starts.
• Fixing performance once. Without per-release tracking, new code brings the problem back.
• Ignoring crash and ANR clusters by device. One device family can account for most problems.

Tracking app performance in TapCub

TapCub's mobile SDKs report app starts and, where the platform supports it, crashes and performance samples:

• App analytics › Quality & attribution › Stability shows crash-free users, crashes, ANRs and UI freezes, plus the median cold start, hot start and memory, with error groups you can mark resolved.
• Devices splits active users by model, OS version, resolution and network, so you can see whether a problem sits on a device family.
• Versions & channels shows crashes per version to catch release regressions. See track app versions and crash-free rate.

Two notes from the documentation: cold start time comes from the duration on the start event, so it stays empty if the SDK adapter does not set it; and the frame-rate chart needs performance sampling turned on. TapCub is an analytics tool, not a profiler: use Android Studio or Xcode to find the code that causes a slowdown.

FAQ

What is a good cold start time for a mobile app? Aim for under two seconds at the median on mid-range devices. Android vitals considers cold starts of five seconds or longer excessive.

What is the difference between a cold, warm and hot start? A cold start launches the app process from scratch. A warm start reuses the process but recreates the activity or screen. A hot start brings an app that is still in memory back to the foreground.

How do I find what slows down my app? Use field data to find which screen, version or device is slow, then reproduce it with a profiler (Android Studio Profiler, Xcode Instruments) to find the code responsible.

Do analytics SDKs slow down apps? Any SDK initialized on launch adds work before the first frame. Initialize analytics asynchronously and defer non-essential SDKs until after the first screen.

Sources

• Android Developers. App startup time.
• Android Developers. Android vitals.
• Apple Developer. Reducing your app's launch time.
• Android Developers. Baseline Profiles overview.