Most release-day disasters I have seen were not exotic bugs. They were ordinary things nobody checked: a debug flag left on, an upgrade that wiped user sessions, a push certificate that expired quietly. This pre-release QA checklist for mobile apps is the list my team runs before every store submission. None of it is glamorous; all of it has caught something real at least once.
Smoke test the release build, not the debug build
The build you tested all sprint is almost never the build users get. Release builds differ in ways that matter: code shrinking and obfuscation, disabled logging, production API endpoints, real signing certificates. Run your smoke suite against the actual release candidate — the signed artifact — on real devices. In our case, Maestro smoke flows run in CI against every release build through GitHub Actions, so this step is automatic rather than heroic. If yours is manual, it still belongs at the top of the list.
Test the upgrade path, not just the fresh install
Fresh installs are a minority of your release audience; most users upgrade. Install the previous production version, log in, generate some data — then install the new build over it. Check that sessions survive, local data migrates, and nothing greets a loyal user with a login screen or an empty state. If a local database schema changed this release, the upgrade path is the single highest-risk item on this entire checklist.
Permissions, offline, and the unhappy paths
- Permissions: deny each one — camera, notifications, location — and confirm the app degrades gracefully instead of crashing or looping on a prompt. Then revoke a granted permission from system settings mid-session and reopen the app.
- Offline: enable airplane mode at launch, mid-flow, and mid-upload. Look for clear messaging and clean recovery when the connection returns — not a silent spinner.
- Push notifications: receive one in foreground, background, and killed states, and verify the tap lands on the right screen with the right content.
- Deep links: open every registered link both cold (app not running) and warm, including links to content that requires login.
The store listing is part of the release
Metadata is shippable surface. Verify screenshots match the current UI in every language you support — including RTL layouts if you ship Arabic — that the "what's new" text describes what actually shipped, and that the version number and minimum OS are correct. A store rejection over a stale screenshot delays a release exactly as effectively as a crash does.
Rollback plan: the QA checklist item everyone skips
Mobile has no instant rollback — you cannot un-ship a binary from a user's phone. So the plan matters more than on web. Use a staged rollout and start small; know which crash and analytics dashboards you will watch for the first 24–48 hours; agree in advance which numbers halt the rollout, so the decision is mechanical instead of a debate. If the fix for a bad release is a server-side flag rather than a new binary, you designed well. If it is an emergency store submission, know how long review takes and who approves the hotfix at 9 pm.
Takeaway: keep this as a literal checklist — a template you copy for each release, one checkbox per item, one name next to each checkbox. "We usually check that" is exactly how ordinary things get missed.
None of this replaces the testing you did during the sprint. It is the final pass that catches what only appears at the boundary between your build machine and a user's phone — and it takes an afternoon, which is cheaper than any hotfix you will ever ship.