ReferenceIntermediate4-6 min reference
App Store / Play Store Release
Shipping a mobile app has gates a web release doesn't: store review, staged rollout, and the fact that a bad build can't be hot-fixed — users must update. This sheet is QA's pre-submission checklist and the review pitfalls; for the general release process see the Release readiness and sign-off resources linked below.
Pre-submission QA gates
- Version + build number bumped correctly (and higher than the live build).
- Tested on the device matrix, including minimum supported OS.
- Release (not debug) build tested — signed, minified, no debug flags/logs.
- Permissions match what's declared in the store listing.
- Deep links / push work on the production build & config.
- Crash-free on a smoke pass; analytics/crash reporting wired up.
- Store metadata: screenshots, description, privacy labels accurate.
Store-specific notes
| App Store (iOS) | Play Store (Android) | |
|---|---|---|
| Review | Human review, hours–days | Mostly automated, faster |
| Rollout | Phased release (%) optional | Staged rollout (%) standard |
| Testing track | TestFlight | Internal / Closed / Open testing |
| Privacy | Privacy "nutrition labels" | Data safety form |
| Rollback | No true rollback — submit a new build | Halt rollout; new build to fix |
Common review rejections
- Crashes / broken core flow on review.
- Permissions requested without justification (esp. iOS).
- Privacy labels / data-safety form not matching actual data use.
- Placeholder content, broken links, or login required with no demo account.
- Payment flows bypassing the store's billing where required.
Common mistakes
- Submitting a debug build, or one with the wrong environment/config.
- Testing the debug build, not the signed release artifact.
- Forgetting you can't hot-fix — a bad release means a new submission + user updates.
- Not providing reviewers a demo account for gated features.
- Skipping staged rollout, so a regression hits 100% of users at once.
// Related resources