A mobile checklist weighted to what only breaks on a phone

Device matrix, lifecycle interruptions, unreliable networks, permission states, performance on low-end hardware and store readiness for iOS and Android. Functional coverage is assumed, so this focuses on the conditions the web never has to handle.

32checks/6sections/9blocking items/FreeCSV download

All 32 checks, grouped by when they apply

Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.

Last updated 20 August 2026

0 of 32 complete

Ticking is local to your browser and is not saved or sent anywhere.

Devices and coverage

Choose the matrix from your analytics rather than from the newest hardware available.

Device matrix chosen from actual user analytics, not from what the team ownsTeams test on flagship devices while a large share of users are two generations behind on slower hardware.
Oldest supported OS version tested, not only the newestDefects cluster on the oldest supported version, and that is where the least testing usually happens.
Smallest and largest supported screen sizes verified, including notches and rounded cornersControls hidden behind a notch or below the safe area are invisible on the devices used to build the app.
Tested on at least one genuinely low-end device, not only emulatorsBlockingEmulators hide the memory, thermal and CPU behaviour that low-end hardware exposes.
Tablet layout verified if supported, including split screenA phone layout stretched to tablet width is the most common giveaway of untested tablet support.
Both portrait and landscape verified, including rotation mid-taskRotation destroys and recreates the view. Unsaved state and in-flight requests are lost if this is unhandled.

Lifecycle and interruptions

The conditions that do not exist on the web and cause most mobile-specific defects.

App backgrounded and resumed mid-task, with state preservedBlockingA form losing its input when the user checks a message is one of the most common mobile complaints.
App killed by the OS while backgrounded, then relaunchedLow-memory devices kill background apps aggressively. Relaunch must restore or fail gracefully, not crash.
Incoming call, alarm and notification received during a critical flow such as paymentBlockingInterruptions during payment are where money-related state corruption happens.
Behaviour on low battery and in battery saver modeBattery saver throttles background work and network activity, which changes sync and timeout behaviour.
Deep links open the correct screen from cold start, warm start and when logged outDeep links usually work from a warm app and fail from cold start or when authentication is required first.
Back button and gesture navigation behave predictably throughoutAndroid back and iOS swipe-back regularly exit a flow or skip a step when navigation is hand-rolled.

Network conditions

Offline behaviour verified: clear messaging, no crash, queued actions where promisedBlockingMobile networks drop constantly. Silent failure is the default unless offline is handled deliberately.
Slow and unstable network simulated, including 2G and high packet lossEverything works on office wifi. Timeouts, duplicate submissions and race conditions appear at 200 kbps.
Transition between wifi and mobile data mid-requestThe connection changes, in-flight requests fail, and apps that do not retry cleanly lose the user action.
Airplane mode toggled during a transaction, then restoredThis is the fastest way to test whether a partially completed transaction reconciles correctly.
Large uploads and downloads on a constrained connection, including resume after interruptionUploads that cannot resume force the user to start again, which is where abandonment happens.

Permissions and platform

Every permission tested in all states: granted, denied, denied permanently, revoked while runningBlockingRevoking a permission from settings while the app is open crashes apps that only check at launch.
App degrades gracefully when an optional permission is refusedRefusing camera access should disable one feature, not block the whole app behind a dead end.
Permission rationale shown before the system prompt where the platform expects itPrompting with no context produces refusals that are then very hard to recover.
Push notifications tested in foreground, background and killed states, including deep link payloadsBehaviour differs in all three states and the killed state is the one usually left untested.
Biometric authentication tested including fallback, failure and no biometric enrolledThe fallback path is used by every user whose fingerprint fails twice, and it is often unfinished.

Performance and resources

Cold start time measured on a low-end device against an agreed targetCold start on a flagship tells you nothing about the experience most users get.
Memory usage watched over an extended session for leaksLeaks show as a crash after twenty minutes of use, which short test sessions never reach.
Battery drain and device heat checked during sustained useAn app that heats the device gets uninstalled regardless of how well it works.
App size and update size reviewed against store limits and user expectationsSize directly affects install conversion on constrained connections and cheaper devices.
Scrolling and animation smoothness checked on the oldest supported hardwareJank is invisible on modern devices and immediately obvious on the ones many users own.

Store readiness and release

Store metadata, screenshots and privacy declarations match the actual buildBlockingMismatched privacy declarations are one of the most common causes of store rejection.
Upgrade path tested from the previous public version, not just a clean installBlockingMigration of locally stored data and schema changes only fail on upgrade, never on fresh install.
Accessibility verified with the platform screen reader and at large text sizesDynamic Type and TalkBack expose layouts that break the moment text scales.
Crash reporting and analytics verified as working in the release buildBlockingCrash reporting that only works in debug means the first production crash is invisible.
Forced update and minimum supported version behaviour testedThe mechanism you rely on to retire a broken version has to work before you need it.

How To Use This

Test the interruptions, not just the flows

Functional defects get caught by anyone tapping through the app. These four categories are what get missed and reach the store.

Get a low-end device

One cheap Android handset finds more real defects than three flagship phones and an emulator farm combined.

Interrupt every critical flow

Background, kill, call, rotate. Payment and form flows are where interrupted state corruption actually costs something.

Throttle the network

Everything passes on office wifi. Timeouts, duplicate submissions and race conditions appear at 2G speeds.

Always test the upgrade

Local data migration only fails on upgrade from the previous public build, never on a clean install.

Why This Emphasis

Mobile defects come from conditions, not features

A mobile app has to survive a hostile environment the web mostly does not: the operating system can kill it at any moment, the network disappears in a lift, permissions can be revoked while it runs, the device rotates mid-task, and a phone call arrives during checkout. Almost all mobile-specific defects come from those conditions rather than from the feature logic, which is why this checklist spends most of its length there.

The device matrix decision is where teams most often go wrong, by testing on the newest hardware in the office. Pull the matrix from your own analytics instead, and make sure at least one genuinely low-end device is in it, because memory pressure, thermal throttling and slow storage produce defects that no emulator reproduces.

The upgrade path is the single most skipped check on this list. Clean installs pass because there is no legacy local data to migrate. Real users upgrade, so schema changes to local storage, cached credentials and pending queued actions all get exercised in a way a fresh install never touches.

Store readiness earns its own section because rejection costs days rather than hours. Privacy declarations that do not match what the build actually collects, and crash reporting that works in debug but not in the release configuration, are both routine and both entirely avoidable.

Suggest an improvement

Shipping to the app stores?

QAble tests mobile releases on real devices across iOS and Android, including interrupted-flow, network and upgrade-path coverage.

Mobile app testing services

More templates and checklists

View all

Sources

OWASP MASVS mobile application security verification standard.
WCAG 2.2 the success criteria behind the accessibility cases.
Apple Push Notification service authorisation states and delivery behaviour on iOS.
Firebase Cloud Messaging token lifecycle and delivery behaviour on Android.