Errors will happen. What matters is whether the user knows what happened and can get out. For each screen that loads or sends data, trigger these failures on purpose. Turn on airplane mode, use a flaky connection, or block the backend in a test build.
The checklist
- No connection on open. - Why: many apps are first opened on bad networks. - How to check: airplane mode, cold start. A clear "no connection" state shows, not a blank screen or endless spinner.
- Connection lost mid-action. - Why: half-sent actions can lose or duplicate data. - How to check: start a save or send, switch to airplane mode. The app says it failed and keeps the input.
- Server error (5xx). - Why: the backend will fail sometimes, and it is not the user's fault. - How to check: point a test build at a failing endpoint. The message says it is on your side and to try again.
- Not found or removed content. - Why: items get deleted while a link or screen is still open. - How to check: open an item, delete it from another device, then act on it. The app shows a clear message and a way back.
- Expired session. - Why: silent logouts and cryptic errors lose users. - How to check: invalidate the token or wait for expiry. The app asks to sign in again and returns to where the user was.
- Permission denied. - Why: users decline camera, location or notification prompts. - How to check: deny the permission, then use the feature. The app explains what is needed and links to settings.
- Message wording. - Why: codes and stack traces mean nothing to users. - How to check: read every message. It says what happened, in plain language, without internal codes.
- Tone and blame. - Why: "You entered wrong data" feels hostile when the server is at fault. - How to check: for each message ask who is at fault and whether the text reflects it.
- A way out on every error. - Why: dead ends force a force-quit. - How to check: each error has a button (retry, back, contact) that works. Use the hardware back button and swipe-back too.
- Retry actually retries.
- Why: a retry button that does nothing is worse than none.
- How to check: fail, restore the connection, tap retry. The action completes once, with no duplicate.
- Errors are not shown twice or stacked.
- Why: three dialogs for one failure overwhelm.
- How to check: cause one failure on a screen with several requests. One clear message appears.
- Errors are announced to assistive tech.
- Why: toast-only messages vanish for screen reader users.
- How to check: with the screen reader on, trigger an error; it is read out and reachable. See screen reader test in 10 minutes.
- Offline behavior is deliberate.
- Why: some actions should queue, some should block.
- How to check: follow testing offline behavior and note what each screen does.
- Crash recovery.
- Why: after a crash, users should land somewhere sane.
- How to check: force-quit mid-action and reopen. No corrupt state, no repeated crash loop.
- Errors leave a trace for you.
- Why: you cannot fix what you cannot see.
- How to check: after triggering errors, confirm your logging or crash tool received them without personal data.
Related
Back to all checklists · Empty states checklist · Loading states checklist
When an error confuses a tester, you want to hear it before the store review does. Get started on AppReviewX: private, structured feedback, 1 feedback = 1 credit.