Mobile App Performance Audit
Performance audit is not "see what's slow." It's systematic measurement of specific metrics on specific devices with concrete results. Without measurements any optimizations are guesses. With measurements — a prioritized list of problems with clear impact from each fix.
What We Measure
Launch Time
iOS: XCTest with measure(metrics:) + XCTApplicationLaunchMetric. Separate cold launch (first run after reboot) and warm launch (repeat run). Apple recommends cold launch < 400 ms to first rendered frame. Typical problem: static initialization in AppDelegate (SDK, databases, analytics) — all synchronous on main thread.
Android: adb shell am start -W com.package/.MainActivity — shows TotalTime and WaitTime. Firebase Performance Monitoring automatically collects app_start metrics from real devices. Common slow startup cause: too early Room/Realm initialization in Application.onCreate(), synchronous SharedPreferences read.
Memory Size and Consumption
iOS: Xcode Memory Graph + leaks utility. Look for retain cycles (common: closure captures self, self holds closure). os_signpost for timestamp markers in profiler.
Android: Memory Profiler in Android Studio → Heap Dump. Check for Leaked Activities (Activity not destroyed due to static reference), large Bitmap objects (incorrect inSampleSize when loading images).
Render Performance
iOS: Instruments → Core Animation. Offscreen-rendered content (red highlight) — unnecessary CALayer ops. Color blended layers — overdraw of transparent layers.
Android: adb shell dumpsys gfxinfo com.package framestats — frame statistics. Slow frames > 5% — problem. Also: systrace or Perfetto for detailed trace.
Network Requests
Charles Proxy or mitmproxy — intercept all app requests. Check:
- Duplicate requests for same data
- Missing caching where appropriate
- Too large payloads (JSON without pagination, uncompressed images)
- Missing HTTP/2 (especially noticeable with many small requests)
Battery Consumption
iOS: Xcode Energy Impact gauge + MetricKit in production. Android: Battery Historian (adb bugreport → analyze in Battery Historian web tool).
Audit Methodology
Audit done in three stages:
1. Automated basic metrics collection. Firebase Performance, Sentry Performance, or custom instrumentation. Check P50/P75/P95 for launch time, screen render time, HTTP latency on real users. Shows where problem is at scale.
2. Device reproduction. Two to three devices: flagship (latest iPhone/Pixel), mid-range (like Samsung A54 / iPhone 12), low-end (4-year-old mid-range Android). Flagship problems often unreproducible, but 30–40% of audience is mid-range and older.
3. Static code analysis. Manual review of key paths: onCreate/viewDidLoad, rendering methods, network layer, database work. Look for sync operations in UI thread, unoptimized queries, missing debounce on user input.
Results Format
After audit — document with problem table:
| Problem | Metric | Device | Priority |
|---|---|---|---|
Sync DB read in onCreate |
+340 ms to cold start | Samsung A54 | High |
| 8 parallel requests on startup | 600 ms TTFR | All | High |
| Retain cycle in ProfileViewController | +12 MB leak per session | iOS | Medium |
| Overdraw in FeedCell | 15% slow frames | Pixel 6a | Medium |
Each problem — with reproducible steps, profiler screenshots, and concrete fix recommendation.
Timeline: three to five business days for medium-scale app (10–30 screens). Large app with multiple modules — seven to ten days.