Guide · updated 22 September 2026

Mobile app testing checklist: what a web-shaped plan misses

Phones interrupt, lose signal, deny permissions and update underneath you. These are the checks that a plan written for a website never contains, and the ones users hit first.

A mobile build fails in ways a website cannot. The app is suspended mid-task, the network disappears in a lift, a permission is denied once and never asked again, and an update lands on a phone that still holds the last version's data. None of that shows up in a plan copied from a web checklist.

Permissions: the first thing users break

Test all three states, not just the happy one: granted, denied, and granted later in system settings. The common bug is an app that asks once, gets refused, and then either nags on every screen or quietly does nothing. Also check that the prompt appears where the feature is used, rather than all at once on launch — reviewers and users both punish that.

Interruptions: what survives a phone call

A half-filled form is the test. Take a call, switch apps for half an hour, rotate the phone, let the battery saver kick in, then come back. The app should hold what was typed or say plainly that it did not. Silent loss of a user's typing is the bug people never report — they just leave.

Network: the lift test

Aeroplane mode for the obvious cases, but the one that finds real bugs is dropping the connection during a submit. Does the app claim success? Does retrying charge the card twice? Does queued work arrive when the signal returns, or vanish?

Devices: the two ends of the range

You do not need a device lab. Test the smallest screen you support and the largest system font size. Those two catch most layout bugs, including text under the notch and a submit button pushed under the keyboard. Then check dark mode on every screen, because it is usually applied to the main ones and forgotten on the rest.

Updates: the check almost nobody runs

Install the previous version, sign in, use it, then install the new build over the top. This catches migrations that wipe local data, sessions that don't survive, and an onboarding flow that runs again for people who have been using the app for a year. Testing only fresh installs hides all of it.

The checklist

Copy this and adapt the journeys to your app. It imports into qarunbook as a board with Android and iOS columns.

mobile-checks.md
# Mobile release checks

## First run and permissions (ONB)

| ID | Journey | Preconditions | Steps | Expected result | AND | IOS |
|---|---|---|---|---|---|---|
| ONB-01 | First launch after install | A fresh install, never signed in | 1. Open the app. | It opens without a crash, on the intro or sign-in screen. Nothing flashes and disappears. | | |
| ONB-02 | Permission asked in context | Fresh install | 1. Reach the screen that needs location. | The prompt appears only when the feature needs it, with a line saying why. | | |
| ONB-03 | Permission denied is survivable | Fresh install | 1. Deny location. 2. Use the app. | The app keeps working with a manual alternative. No loop of prompts, no crash. | | |
| ONB-04 | Permission granted later | Permission denied earlier | 1. Grant location in system settings. 2. Return to the app. | The app notices without a restart, or says clearly to restart. | | |
| ONB-05 | Notifications denied | Fresh install | 1. Deny notifications. 2. Do something that would notify. | The app continues, and never asks again on every screen. | | |

## Interruptions and state (INT)

| ID | Journey | Preconditions | Steps | Expected result | AND | IOS |
|---|---|---|---|---|---|---|
| INT-01 | Phone call mid-task | Half-filled form | 1. Receive a call. 2. End it and return. | The form still holds what was typed. | | |
| INT-02 | App backgrounded for 30 minutes | Signed in, mid-task | 1. Switch apps for 30 min. 2. Return. | The app restores where it was, or signs out deliberately with a message. It does not show a blank screen. | | |
| INT-03 | Rotation | Any form screen | 1. Rotate the device. | Nothing is lost and nothing is cut off. | | |
| INT-04 | Low battery mode | Battery saver on | 1. Use the main journey. | Animations may drop, but the journey completes. | | |
| INT-05 | Killed and reopened | Signed in | 1. Swipe the app away. 2. Reopen it. | Still signed in, and the last screen or the home screen opens. | | |

## Network (NET)

| ID | Journey | Preconditions | Steps | Expected result | AND | IOS |
|---|---|---|---|---|---|---|
| NET-01 | No connection | Aeroplane mode | 1. Open the main screen. | A clear "no connection" state with a retry, not an endless spinner. | | |
| NET-02 | Slow connection | Throttled network | 1. Submit the main action. | A progress state appears within a second, and the action is not sent twice. | | |
| NET-03 | Connection drops mid-submit | Network on, then off | 1. Submit. 2. Turn the network off mid-flight. | The app says the action may not have completed, and retrying does not create a duplicate. | | |
| NET-04 | Back online | Was offline | 1. Restore the network. | Queued work completes or is clearly discarded. Nothing is silently lost. | | |

## Devices and display (DEV)

| ID | Journey | Preconditions | Steps | Expected result | AND | IOS |
|---|---|---|---|---|---|---|
| DEV-01 | Small screen | A small phone (or the smallest simulator) | 1. Walk the main journey. | No text cut off, no button off-screen, nothing under the notch or home bar. | | |
| DEV-02 | Largest text size | System font size at maximum | 1. Open the main screens. | Text reflows and stays readable. Buttons still show their labels. | | |
| DEV-03 | Dark mode | System set to dark | 1. Open every main screen. | Every screen follows, with readable contrast. No white flash on launch. | | |
| DEV-04 | Keyboard covers the field | Any form near the bottom | 1. Tap the last field. | The field scrolls above the keyboard, and the submit button is reachable. | | |

## Updates and store (REL)

| ID | Journey | Preconditions | Steps | Expected result | AND | IOS |
|---|---|---|---|---|---|---|
| REL-01 | Upgrade over the old version | Previous version installed and signed in | 1. Install the new build over it. | Still signed in, local data intact, no forced re-onboarding. | | |
| REL-02 | Deep link from outside | App installed | 1. Open a share link from a message. | The right screen opens, signed in or with a sign-in that returns there afterwards. | | |
| REL-03 | Store listing matches the build | The build under test | 1. Compare screenshots and description. | Screens shown in the store exist in this build. | | |

Or take the file: Markdown·CSV·Excel·no email, no sign-up.

Run it on real devices, and record who did

Simulators cannot receive push notifications, and they lie about performance and battery. Anything involving push, camera, biometrics or real network conditions has to be checked on a physical phone.

Record each result against the platform it was checked on, with the tester's name. "It passed" is not useful three days later when the question is whether it passed on Android 14 or only on someone's iPhone.