Users experience a sequence, not a benchmark.
A download must complete, the application must launch, the first screen must become useful, and interaction must remain responsive under real memory, network, thermal, and device constraints. Optimizing an isolated number while delaying the user-visible milestone can produce a technically faster but experientially unchanged application.
Field data tells us where. Profiling tells us why.
Production distributions identify affected devices, versions, and journeys. Controlled traces reveal the work responsible for the delay.
Define milestones and populations.
Track distributions by application version, device class, operating system, and journey. Separate cold, warm, and resumed launch. For responsiveness, connect long frames or hangs to the user action and screen where they occur.
Download and installed size
What users receive and retain, segmented by architecture and delivery format.
Time to usable
Cold, warm, and resume paths to the first meaningful interactive state.
Frames, hangs, and ANRs
User-visible stalls and the main-thread work associated with them.
Footprint and pressure
Steady state, peaks, retention, terminations, and device-class sensitivity.
Crash-free experience
Regressions correlated with versions, features, and performance interventions.
Feature milestones
Time to content, first action, and completion for business-critical flows.
Binary size: remove bytes with a known owner.
Begin with the delivered artifact, not the repository. Attribute size to executables, frameworks, native libraries, resources, symbols, architectures, and duplicated content. Then rank removals by user impact and engineering risk.
Delivery and linkage
Use app thinning correctly, inspect embedded frameworks and symbols, audit resource variants, and understand the cost of static and dynamic dependencies.
Bundles and shrinking
Use Android App Bundles, resource shrinking, and R8 deliberately; audit native ABIs, large assets, and transitive libraries.
Dependency governance
Make size impact visible during review and require ownership for libraries, assets, generated code, and cross-platform runtimes.
Launch: defer work until its value is visible.
Break launch into platform and application phases, then mark the moment the first useful screen becomes interactive. Common problems include eager dependency initialization, synchronous disk or network access, broad dependency injection graphs, class loading, resource decoding, and work repeated on every launch.
Pre-main and application work
Inspect dynamic loading and static initialization, then profile main-thread work through the first rendered and interactive state.
Process and first frame
Trace application and provider initialization, class loading, layout, and first-frame work; apply baseline or startup profiles where evidence supports them.
Initialization policy
Remove, defer, parallelize, or lazily initialize work according to when the user journey actually needs it.
Responsiveness and memory are architecture signals.
Long main-thread tasks, repeated layout, image decoding, excessive recomposition, lock contention, and synchronous boundaries make interactions feel unreliable. Memory growth and peaks can trigger termination before they appear as a conventional crash.
We pair traces and memory graphs with a concrete journey, then make the responsible work smaller, asynchronous, reusable, or bounded. The fix may live in rendering, data flow, caching, concurrency, media handling, or feature architecture.
Performance needs a release budget.
Track agreed thresholds in CI where stable laboratory measurement is possible, and use production monitoring for device and journey distributions. Review changes against the baseline instead of rediscovering regressions after complaints.
What a mobile performance engagement produces.
We select one or more high-value journeys, establish field and laboratory baselines, capture platform traces, and attribute delay or resource use to specific work. The output includes implemented improvements where scoped, a ranked backlog, measurement fixtures, and budgets with clear owners.
Binary size, launch, memory, and responsiveness are connected, so we verify that improving one does not quietly regress another.
Platform references.
Apple documents techniques for reducing application size and reducing launch time. Android’s official guidance covers application size, startup analysis and optimization, and startup vitals.