Mobile App Performance

Why it matters

Users judge an app in its first seconds and in every scroll. A slow start, a stuttering list or a phone that warms up and loses charge can lead to uninstalls and poor store reviews. The platforms measure it too: Android vitals in Google Play Console reports startup time, slow and frozen frames and battery-related behaviour from real devices, and the Xcode Organizer shows launch time, hangs, memory and battery use from users who share analytics.

For a tester, performance defects are easy to miss because they depend on conditions: a cheap device, a cold start, a long session, a weak signal. They also creep in a little with each release until the app is clearly slower than it was. Measuring the same scenarios the same way every release turns "it feels slow" into numbers a developer can act on.

The five measures and what each one means

Each measure has its own definition and its own way to fail. Learn the vocabulary first: a report that says "startup is slow" is far weaker than one that says "cold start to first frame went from 1.4 s to 2.6 s".

• Startup time. A cold start launches the app when its process is not running, so everything is created and loaded; a warm start reuses part of what exists but must recreate the screen; a hot start only brings a screen that is still in memory back to the front. Android names two moments: time to initial display (TTID), the first frame, and time to full display (TTFD), when the content the user came for is ready, which the app reports by calling reportFullyDrawn(). Android vitals measures startup to the first frame (TTID) and treats cold starts of 5 seconds or more, warm starts of 2 seconds or more and hot starts of 1.5 seconds or more as excessive.
• Frame rate. At 60 Hz the app has about 16.7 ms to produce each frame; at 120 Hz about 8.3 ms. Frames that miss the budget show as stutter, called jank (Apple speaks of hitches). Android vitals reports slow rendering and frozen frames; a frozen frame is one that takes longer than 700 ms to render. The usual cause is long work on the main thread, the same thread whose blocking produces the ANR from the lesson on Android and iOS.
• Memory. Watch the peak a flow needs and whether memory returns to its baseline when the flow ends; memory that grows with every repetition is a leak. High memory use gets the app ended: in the background the system ends it sooner, so the user may return to a restarted app that has lost their input; in the foreground, passing its limit ends it as an out-of-memory crash.
• Battery. Energy goes to the screen, processor, radios and sensors such as GPS. Typical defects are work that does not stop: location updates after the user leaves the map, wake locks that keep the processor awake, polling every few seconds, and background jobs that ignore Android’s Doze idle mode or iOS Low Power Mode. Each platform’s battery settings show every app’s share.
• Network conditions. Users move between Wi-Fi, fast and slow mobile data and no signal. Latency (the time of each round trip) punishes screens that make many requests one after another; low bandwidth punishes large images and responses; packet loss forces lost data to be sent again, which adds more delay.

Measuring reliably: conditions before numbers

A number means something only with its conditions. Debug builds carry extra checks and can be much slower than what users install, so measure a release build. Use real devices, starting with the lowest-end one you support; an emulator runs on your computer’s processor and says little about a budget phone. Keep the state identical between runs: same account and data, other apps closed, power saving off, and let a hot phone cool down, because heat slows the processor.

Repeat each measurement (ten runs is a common choice) and report the median, the middle value of the sorted runs, with its spread from the lowest to the highest run; one run proves nothing. Compare with the previous release measured the same way: that shows a regression even where nobody set a target. Your lab numbers reproduce problems and confirm fixes; the field data in Android vitals and the Xcode Organizer shows what real users experience across many devices.

# Android: release build on a real device, adb from the SDK platform tools
adb shell am force-stop com.example.shop          # the next launch is a cold start
adb shell am start -W -n com.example.shop/.MainActivity
#   TotalTime: 1873                                 # ms to the first frame, about TTID
adb logcat -d | grep "Fully drawn"                  # TTFD, if the app reports it
#   ... Fully drawn com.example.shop/.MainActivity: +2s105ms
adb shell dumpsys gfxinfo com.example.shop reset    # clear the frame statistics
#   ...scroll the list for 30 seconds...
adb shell dumpsys gfxinfo com.example.shop          # janky frames, frame percentiles
adb shell dumpsys meminfo com.example.shop          # memory used by the app process
adb shell dumpsys batterystats --reset              # start a battery session
#   ...unplug the phone, use the app for 30 minutes, plug it back in...
adb shell dumpsys batterystats com.example.shop     # the app's use since the reset

# iOS: Xcode > Product > Profile opens Instruments with templates such as
#   App Launch, Time Profiler, Animation Hitches, Allocations, Leaks, Network

Try it: Byte / KB / MB / GB Converter

Testing under real network conditions

The scenarios guide showed how to switch networks and force offline states. For performance the questions are how long the user waits and how much data the app spends on a weak connection. Use a fixed set of profiles so results stay comparable, for example good Wi-Fi, typical 4G and a poor 3G-like profile with high latency and some loss. The Android emulator sets speed and delay, iOS’s Network Link Conditioner offers profiles such as 3G, Edge and Very Bad Network, and a throttling proxy or a restricted test Wi-Fi covers real Android devices.

Latency adds up with sequential requests: six calls made one after another at 300 ms per round trip cost at least 1.8 s of network waiting alone. Bandwidth punishes size: a 2 MB response that nobody notices on office Wi-Fi takes seconds on a slow connection. Ask how many requests each key screen makes and how large they are, and check that responses are compressed and images arrive at the size the screen shows.

• Time from tap to usable screen on each profile, taken from a screen recording or the app’s own timing.
• Feedback while waiting: a loading state appears at once and the screen stays responsive.
• Timeouts and retries: a hanging request ends in a clear message, and retries do not multiply the traffic.
• API time measured separately, so you know whether the delay is the server, the network or the app.

Try it: Response Size Analyzer Try it: API Status Code Simulator Try it: Response Time Analyzer

Worked example: a restaurant list that stutters

A food delivery app is preparing version 3.2, and colleagues trying the release candidate say the restaurant list "feels heavy" on cheaper phones. The tester installs the release candidate and, for comparison, the current version 3.1.4 on the lowest-end supported Android phone (60 Hz display), signs in with the standard test account, scrolls the list to the end and back for 30 seconds, and collects frame and memory statistics. Three runs per version give the medians below.

The frame statistics confirm the complaint: the new version renders fewer frames in the same 30 seconds, and far more of them miss the budget (a 90th percentile of 38 ms means one frame in ten took 38 ms or longer). The network traffic shows a likely cause: each restaurant card now downloads a 600 KB photo that the phone scales down to a small thumbnail, and decoding and scaling large images costs processor time and memory, which delays frames.

• Verdict: a performance regression against 3.1.4 on every frame measure and on memory; janky frames went from 4.1 % to 27.8 %.
• Bug report title: "Restaurant list scroll: 27.8 % janky frames on low-end Android vs 4.1 % in 3.1.4", with device, build, steps, the table, a screen recording and an image URL with its size.
• The likely cause is for the developer to confirm; the expected fix is thumbnails delivered at display size.
• Confirmation testing repeats the same scenario on the same device and compares every row; then the scenario joins the performance checklist of every release.

Device:   lowest-end supported Android phone, 60 Hz display, release builds
Scenario: restaurant list, scroll to the end and back for 30 s, median of 3 runs

                              3.1.4 (current)    3.2.0-rc1
Total frames rendered              1,710            1,240
Janky frames                       4.1 %            27.8 %
90th percentile frame time         14 ms            38 ms
99th percentile frame time         31 ms            160 ms
Memory after scroll (meminfo)      160 MB           410 MB
Photo per restaurant card          45 KB            600 KB

Try it: Response Size Analyzer

Frequently asked questions

References

• Android vitalsAndroid Developers (Google)The app-quality metrics Google Play collects from users' devices — user-perceived crash and ANR rates among the core vitals — and the bad-behaviour thresholds that affect an app's visibility.
• Certified Tester Mobile Application Testing (CT-MAT)ISTQB · 2019ISTQB's specialist syllabus on mobile testing: app types, device and platform challenges, test types and tools.
• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023The product quality model: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability and flexibility.
• XCTestAppleApple's framework for unit, performance and UI tests of Xcode projects on iOS and other Apple platforms.