App store release QA is a different discipline from feature QA. The build changes, the audience changes, and the failure modes change — a bug that slips through here does not create a ticket, it creates a rejected submission or a rollback with your version number on it. This is the checklist I run before anything goes to review.
Release QA starts with the release build
Everything you tested during the sprint ran on a debug build. The release build is a different artifact: code shrinking and obfuscation (R8, ProGuard) can strip classes that reflection depended on, debug menus and verbose logging must be gone, and build-time configuration flips endpoints and keys. Install the actual release candidate — through TestFlight on iOS and an internal testing track on Google Play — and rerun the smoke suite against it. The scariest release-week bugs I have seen were ones that only reproduced with minification on, or a build quietly pointed at the staging API.
Metadata and screenshots are part of the product
Reviewers and users both read the store listing, so QA should read it too. Screenshots must match the current UI, the description must not claim features that are missing or region-locked, and the what's-new text should describe this version rather than three versions ago. If the app is localized, review the localized listings with the same care — as an Arabic speaker I have seen store screenshots with broken RTL layouts and machine-translated captions undercut an otherwise well-localized app before anyone even installed it.
Permission purpose strings
Both stores now judge why you collect what you collect. On iOS, every sensitive permission needs a purpose string, and vague ones — "This app needs camera access" — invite rejection; the string should say what the user gains. On Android, the Data safety form must match what the app and its bundled SDKs actually do, and analytics SDKs are the classic mismatch. Trigger every permission prompt on the release build and read each string the way a reviewer would.
Review guideline landmines
Most rejections are predictable: a demo account in the review notes that does not work, features hidden behind flags that look like concealed functionality, payment flows that route around in-app purchase where the rules say they must not, leftover placeholder content, or a dead link to the privacy policy. Before submitting, log in with the exact reviewer credentials yourself, on the release build, from a clean install. It takes ten minutes and it removes the single most common rejection.
Staged rollouts and monitoring
Never go from zero to one hundred percent. Google Play supports staged percentage rollouts and iOS offers phased release; use them, and decide the halt criteria before shipping — crash-free rate dropping below your baseline, or a spike in failures on the key funnel. Someone should own the dashboards for the first day or two after release, and that ownership should be written down, not assumed.
Have a hotfix playbook before you need it
When something breaks in production, you do not want to be inventing process under pressure. Write it down in advance: who can halt a staged rollout, which features can be disabled remotely by flag, how to request expedited review on iOS, and what the version bump convention for a hotfix is. In a real incident, a playbook turns a panic into a checklist.
Release QA is mostly running old tests on a new artifact under new rules. The smoke suite my team wired into GitHub Actions runs against the release candidate build as well — same flows, different binary — because "it passed on debug" has burned us before.
Rejections and rollbacks are rarely caused by exotic bugs. They come from the gap between the build you tested and the build you shipped. Close that gap, and release day gets boring — which is exactly what release day should be.