Mobile App Testing: The Device Matrix and What Really Breaks

An emulator on a developer machine has perfect network, unlimited battery, no incoming calls, no notifications, and infinite patience. It is a reasonable place to check that a screen renders. It is a poor place to decide whether an app works.

Everything that actually breaks a mobile app happens in conditions an emulator does not have. Testing a cross-platform chauffeur booking app — live location, in-app payment, two platforms — taught me which of those conditions are worth deliberate effort.

Choosing a device matrix you can afford

You cannot test every device, and the goal is not coverage of the market. It is coverage of the differences that break things.

The dimensions that actually matter:

• OS version. The current version, the previous major version, and the oldest you claim to support. Most platform-specific defects are version defects.
• Screen size and density. One small phone, one standard, one large or a tablet if supported. Layout breaks at the extremes — small screens truncate and overlap, large ones leave controls stranded.
• Manufacturer, on Android. Aggressive battery management differs by manufacturer and will kill your background work on some devices and not others. This is real and it is not reproducible on a stock emulator.
• A genuinely low-end device. Not for performance benchmarking — to expose race conditions. Slow devices lose races that fast devices win, and a surprising number of bugs only appear when a screen takes two seconds to load.

Four to six physical devices chosen along those lines beat twenty chosen at random. Emulators are still useful for layout iteration and for OS versions you do not own; they are not sufficient for sign-off on anything involving hardware, network, or lifecycle.

Interruptions are the real test

This is the category most likely to be skipped and most likely to contain a serious defect, because it tests the app's lifecycle rather than its logic.

For each critical flow — login, booking, payment, anything with a form — interrupt it partway and come back:

• Take an incoming call mid-flow
• Background the app, wait a minute, return
• Background it long enough to be evicted from memory, then return
• Lock the screen and unlock
• Rotate the device, if rotation is supported
• Open the notification shade and pull down a notification
• Switch to another app and back through the app switcher

What you are looking for is state loss and state corruption. Does a half-filled form survive? Does a payment in progress resume, complete, or duplicate? Does live location tracking recover, or silently stop while showing a stale position? Does the user come back to the screen they left, or to a blank one that requires starting again?

Backgrounding during payment deserves its own explicit test on every release. It is common in real use — people switch apps to check a bank code — and the failure mode is a charge with no record of what it bought.

The network is not binary

Offline is the easy case, because it is obvious. The expensive failures happen in between.

Test these deliberately:

• Slow but working. Throttle to a poor connection and watch for missing loading states, requests that time out with no message, and double submissions from users who assume nothing happened.
• Dropping mid-request. Turn on airplane mode after tapping submit but before the response. Did the request commit on the server? Does the client retry? Does retrying create a second record?
• Recovery. Restore the connection. Does the app notice, or does it need a manual restart?
• Switching networks. Move from mobile data to a wireless network mid-session. Long-lived connections and uploads are where this bites.
• Offline reads. If the app caches, does it say the data is stale, or present it as current?

The retry question is the one worth pushing hardest on, because it crosses into the server. A mobile client that retries a booking or a payment must not create two of them — and that is an idempotency property of the API, not of the app. Which is why I test the endpoint directly as well as the screen.

Permissions can be revoked at any time

Location, camera, notifications, storage: the user can grant, deny, or revoke each one at any point, including while the app is running.

The cases:

• Deny on first request. Does the app explain why it needs the permission and continue in a degraded mode, or does it break?
• Grant, then revoke in system settings while the app is backgrounded, then return. This one crashes apps.
• Grant "while using the app" rather than "always", where the platform offers it. Background location work will behave differently.
• Location services disabled at the device level rather than for the app.

For a booking app with live tracking, revoked location mid-journey is not an edge case, it is a Tuesday. Handle it visibly or the driver and passenger see a frozen map with no explanation.

State after an update

Users do not install your app fresh. They update it, carrying whatever local data the previous version stored.

So: install the previous released version, use it enough to create local state — log in, start something, save a draft, cache some data — then install the new build over the top. Does the session survive? Do stored records migrate? Does a schema change to the local database wipe data or crash on first launch?

A failed migration on update is one of the worst defects a mobile app can ship, because it hits every existing user at once and no rollback reaches devices that already updated. Testing it costs ten minutes per release.

Platform differences that are not cosmetic

Android and iOS differ in ways that change behaviour, not just appearance:

• The Android hardware or gesture back action, which can leave a flow in a state the designed navigation never produces
• Keyboard behaviour — fields hidden behind the keyboard, "next" versus "done", numeric keypads that permit a minus sign
• Safe areas, notches, and dynamic islands overlapping controls at the top and bottom
• Notification permission and delivery differences
• Deep links, and whether one opens the right screen when the app is closed, backgrounded, or already open on another screen
• Date, time, and currency formatting under a different device locale — worth pairing with the time zone cases from booking flows

The back-action case is worth listing explicitly for every flow, because designers specify forward navigation and users press back.

Battery, memory, and the long session

Short test sessions hide a class of defect. Leave the app open for an extended period with tracking or a live feed running, and watch for memory growth, rising battery drain, and a session that expires without telling the user.

Then check the platform's own battery optimisation. On Android, a device with aggressive power management may suspend your background work entirely — and if the app depends on background location or a background upload, that is a functional defect that only appears on some manufacturers' devices after some minutes.

What I check before every mobile release

The short list, on at least two physical devices per platform:

1. Install fresh, and install over the previous version
2. Login, logout, and session expiry
3. The two or three flows that move money or make commitments, each interrupted at least once
4. Each flow again on a throttled connection, and once with the network dropped mid-request
5. Permission denied and permission revoked, for every permission used
6. Rotation and keyboard behaviour on every form
7. Backgrounding during payment, specifically
8. The database check afterwards, to confirm what the app said matches what was stored

That last step is not optional. A mobile client is a client like any other, and the screen is a rendering of the truth rather than the truth itself. Two of the products I have tested were mobile-first, and in both the defects that mattered were found in this list rather than on a happy path.