A mobile app performs beautifully on the development team's latest phones.
Startup is quick, scrolling is smooth and important screens respond almost immediately. The release passes QA and goes to production.
A week later, the picture looks very different.
Users with older Android devices report that the app sometimes freezes after login. Customers on weaker mobile networks wait several seconds for an important screen to populate. One iPhone model shows unusually high memory use, while another segment experiences slow startup after upgrading the operating system.
Nothing in the development environment clearly predicted those problems.
That is one of the fundamental challenges of mobile performance: the application does not run in one environment.
It runs across different processors, memory limits, operating-system versions, screen refresh rates, battery conditions, storage states and network qualities. Optimizing performance therefore requires monitoring what happens on real devices, not relying only on laboratory testing or one headline metric.
Android's current performance guidance explicitly emphasizes monitoring performance where it matters most—in production—and covers startup, rendering, memory, battery and application stability among the major areas teams should inspect. Apple's MetricKit similarly exposes production metrics for launch time, hangs, animation hitching, CPU, memory, disk and network activity from real devices.
For Levelworks, this is primarily the Performant dimension of App Health, strengthened by Observable. A mobile app is much easier to optimize when the team can identify which users, devices and workflows are actually experiencing degraded performance.
Performance is multidimensional.
An app can launch quickly but freeze during interaction. Another may scroll smoothly while consuming excessive memory and eventually being terminated by the operating system. A third can perform perfectly on Wi-Fi but become painfully slow on cellular networks because it transfers too much data.
A useful mobile performance monitoring model therefore separates at least:
The objective is not to collect every available metric.
It is to know which part of the mobile experience becomes unhealthy when users say the app feels slow.
Startup is one of the first performance signals a mobile user experiences.
Measure different startup conditions where the platform makes the distinction.
On Android, these commonly include:
Android vitals currently uses Time to Initial Display (TTID) for startup monitoring. Google Play considers startup excessive at 5 seconds or more for cold starts, 2 seconds or more for warm starts, and 1.5 seconds or more for hot starts. These are excessive-behaviour thresholds rather than recommended performance targets; teams should generally aim well below them where the application experience permits. Android Developers: App Startup Time
On Apple platforms, MetricKit exposes measures including Time to First Draw, optimized time to first draw, app-resume time and extended-launch activity. Apple: MetricKit
Watch distributions rather than only average launch time.
If most users start the app in one second but a particular device family regularly takes four seconds, the average may hide the group that needs attention.
Segment startup by:
A regression immediately following a release is particularly useful because it gives engineering a smaller search area.
An app that launches quickly can still feel slow every time the user touches it.
On mobile, responsiveness means the UI thread or main thread remains available to process interaction and rendering rather than being occupied by excessive computation, blocking I/O or another long task.
Apple's responsiveness guidance suggests keeping synchronous main-thread work following a discrete user interaction below roughly 100 milliseconds and keeping continuous-interaction work within the display refresh interval where possible. It also distinguishes hangs, where interaction stops responding, from hitches, where animation or scrolling becomes visually uneven. Apple: Improving App Responsiveness
MetricKit provides hang and hitch metrics for production monitoring, while Android provides tools and production signals for slow rendering and Application Not Responding events.
Useful signals include:
Do not treat scrolling smoothness as merely cosmetic.
If scrolling, typing or tapping repeatedly stalls, users experience the application as slow even when every backend API response is fast.
Crashes and poor performance overlap, but they tell different stories.
A crash ends the application process unexpectedly.
An Android Application Not Responding (ANR) event occurs when the app remains alive but cannot respond appropriately because, for example, the main thread is blocked.
Android documents several ANR conditions; one important example is input dispatch timing out when the app does not respond to user input within five seconds. Android Developers: ANRs
Both matter because users often describe them similarly:
The app froze.
It stopped working.
I had to close it.
Current Android vitals treats user-perceived crash rate and user-perceived ANR rate as core stability metrics.
Track them separately by:
A release may improve overall performance while creating ANRs on one lower-memory device family. Aggregated metrics alone can miss that.
Crashes and ANRs are not purely performance metrics, but they are important boundaries: optimization has little value if the app becomes unstable under the same conditions.
Memory behaviour matters much more on mobile than teams accustomed to large server environments sometimes expect.
Users run your app alongside the operating system and many other applications on devices with widely varying RAM.
On Android, excessive allocation can increase garbage collection, create rendering contention and ultimately contribute to out-of-memory termination. Android's performance documentation recommends profiling allocation behaviour, garbage collection and possible leaks rather than looking at only a single memory snapshot. Android Developers: Performance Measurement
Apple's MetricKit exposes memory-related information and diagnostics for situations in which an app or extension terminates after exceeding memory limits.
Useful memory monitoring includes:
Pay particular attention to growth that does not reverse.
If opening and closing the same image-heavy screen repeatedly causes memory usage to climb every time, you may have a leak or retained resources rather than simply a memory-intensive feature.
[Internal Link: “Why Is My App Slow? 10 Common Causes of Poor Application Performance”]
High CPU is not automatically bad.
An app performing image processing, encryption or another legitimate compute-heavy task may briefly need substantial processing capacity.
What matters is whether CPU work creates user-facing consequences.
Watch for:
Apple's MetricKit reports CPU time and instruction counts as part of its production performance metrics, allowing teams to track resource consumption alongside launch, responsiveness and other app-health signals.
CPU should therefore be interpreted alongside what the app was doing.
A five-second CPU spike while exporting a complex video means something very different from the same spike every time a user opens a simple settings screen.
Performance optimization on mobile cannot ignore energy use.
An app may feel responsive while quietly consuming excessive battery through background network requests, location updates, repeated wake-ups or unnecessary computation.
That eventually becomes a user-experience problem.
Android's current guidance notes that repeated background mobile-network activity wakes the CPU and activates the cellular radio, increasing battery consumption. Google recommends tools such as system tracing, Macrobenchmark power metrics and the Power Profiler for investigating battery behaviour. Android Developers: Excessive Background Network Usage
Useful things to monitor include:
Do not optimize battery by simply disabling useful background functionality.
The purpose is to identify unnecessary activity and reduce work that does not provide corresponding user value.
A mobile application is only as fast as the network path behind many of its screens.
Monitor:
Firebase Performance Monitoring, for example, automatically captures HTTP/S network traces including response time and request and response payload sizes for supported mobile apps. It also supports custom network traces for requests not automatically captured. Firebase: Network Request Performance
This helps distinguish different problems.
If an API is slow for every platform, the backend may be responsible.
If it is fast from the server environment but slow primarily for mobile users on cellular connections, payload size or request patterns may matter more.
Also look at how many requests a screen makes.
Twenty fast requests can still create a slow mobile workflow because each one has network overhead and may behave very differently on weak connectivity.
Platform metrics tell you whether the app launches, hangs or consumes memory.
They may not tell you that submitting an insurance claim now takes eight seconds.
Add application-specific monitoring around the actions that matter most.
Examples include:
Firebase Performance Monitoring supports custom traces that measure application-specific code or workflows in addition to its automatically collected lifecycle traces. Its built-in app-start trace, for example, measures from application opening until the app becomes responsive. Firebase: App Lifecycle Performance
This distinction is essential.
A mobile app can have acceptable generic system metrics while one commercially important workflow is performing badly.
[Internal Link: “Application Performance Optimization: A Practical Guide”]
Device diversity is one of the defining characteristics of mobile performance.
The same application may run on:
Android's guidance specifically recommends testing memory-constrained devices because users on those devices are more likely to encounter startup latency, ANRs and crashes.
Segment production data by:
Do not immediately optimize for the absolute slowest obscure device in the fleet.
Look for meaningful clusters.
If 18% of your users share a device tier with significantly worse startup and ANR behaviour, that is a much stronger optimization signal than one unusual outlier.
Averages can also hide release-specific regressions.
Suppose overall startup time changes very little because only 20% of users have installed the newest release.
Among those users, startup may have become 35% slower.
Segment metrics by app version so the effect appears before the entire install base updates.
OS versions deserve similar attention.
An operating-system update can alter scheduling, background execution, memory behaviour, permissions or rendering characteristics. A release that performs normally on the previous OS may behave differently after users upgrade.
This makes version segmentation essential to mobile maintenance, particularly after:
You want to know not only whether the app is slower, but when that change began and which software combination experiences it.
App size is not the first metric to investigate when a button feels slow, but it belongs in a broader mobile-performance view.
Large binaries and data footprints can affect download, installation, storage pressure and, indirectly, memory and runtime behaviour.
Apple's current MetricKit includes measures for total file size, cache folders, app data and disk writes. Android's performance guidance likewise treats app size as one of the common areas affecting mobile app quality.
Watch for unexpected growth across releases.
If the app increases significantly in size, identify whether the change comes from:
The point is not to chase the smallest possible binary. It is to prevent application footprint from growing invisibly.
A useful mobile performance baseline can be surprisingly compact.
Area
What to monitor
Startup
cold/warm startup or platform equivalent; launch percentiles
Responsiveness
hangs, ANRs, hitching/jank, interaction latency
Stability
crash rate, ANR rate, memory terminations
Memory
typical and peak memory, growth/leaks, device-tier differences
CPU
expensive foreground/background operations
Battery
background work, wakeups, network activity
Network
endpoint latency, failures, request/response size
Critical journeys
login, search, checkout or other business-specific timings
Segmentation
app version, OS version, device model/tier, network
Footprint
application size and significant disk growth
Do not treat every row as equally important.
A media app may care deeply about frame smoothness and network throughput. A banking app may prioritize startup, login responsiveness and transaction latency.
Choose the metrics according to what users actually do.
Collecting metrics without defining what requires attention produces dashboards nobody acts on.
For important metrics, establish a normal range and decide when engineering should investigate.
Those thresholds can come from:
Be cautious with universal targets.
The Android startup thresholds mentioned earlier are useful indicators of excessive behaviour, but they should not become your performance ambition.
Likewise, an acceptable duration for generating a complex video cannot be copied from the expectation for opening a messaging conversation.
A useful threshold answers:
At what point does this behaviour become unacceptable for this particular workflow and user?
Mobile performance optimization should form a feedback loop.
Suppose engineering reduces work performed during app launch.
Compare:
That final step matters because performance improvements can move cost rather than remove it.
Moving startup work to the first user interaction might make the launch metric look better while creating a sluggish first screen.
Optimization succeeds when the user experience improves, not when one graph does.
Production monitoring and development profiling solve different problems.
Production tells you:
Where is the application unhealthy, and who is affected?
Profiling tells you:
What is the application doing internally when that problem occurs?
Android provides system traces, CPU and heap profiling, memory tools and benchmarks for investigating problems identified in the field. Apple similarly combines MetricKit's field metrics with diagnostics that can identify code paths associated with hangs, crashes, launch problems and other performance conditions.
A useful workflow is therefore:
Observe production → isolate affected segment → reproduce representative conditions → profile → change → release → confirm production improvement.
That is considerably stronger than optimizing whatever happens to look slow on a developer's phone.
[Internal Link: “Application Monitoring: What Should You Monitor in a Production App?”]
The biggest mistake in mobile app performance monitoring is assuming that the development team's experience represents the user's experience.
It does not.
Users have different phones, memory limits, operating systems, networks and usage histories. Their devices may be warm, low on storage, switching between cellular and Wi-Fi, or running several other applications while yours is active.
For Levelworks, maintaining Performant App Health therefore requires production visibility alongside laboratory testing. Observable matters because optimization begins with knowing where degradation occurs, while Tested helps prevent improvements on one device or workflow from creating regressions somewhere else.
A useful mobile performance program does not ask only:
“Is the app fast?”
It asks:
“How quickly does it start, how smoothly does it respond, how much device resource does it consume, how fast do its network-dependent workflows complete—and which users are having a materially worse experience than everyone else?”
Once those answers are visible, mobile performance optimization stops being guesswork.
