A mobile app release checklist that prevents store rejections and bad launches

A web release can be reverted in minutes. A mobile release goes through review, reaches users on their own schedule, and old versions stay in the wild for months. That asymmetry is why mobile launches need more preparation than web ones.

Before you submit

Store requirements change. Both stores update their rules regularly — minimum operating system or API targets, screenshot sizes, privacy disclosures, permission justifications. Check the current requirements for the platform you are submitting to rather than relying on what worked last release.

Privacy.

• Describe accurately what data the app collects and why, in the store's privacy disclosure.
• Provide a working privacy policy link.
• Request permissions in context, at the moment a feature needs them, with a clear reason. Remove permissions you do not use.
• If the app offers account creation, make sure users can delete their account and data from within the app, as store policies expect.

Content and behaviour.

• Provide demo credentials if the app needs a login, and make sure the demo account has realistic data.
• Make sure every link and screen reviewers will reach works, including empty states and error states.
• Do not ship placeholder text, test banners or debug menus.
• Be careful with payments: digital goods generally have to use the store's billing system.

Build and signing

• Build releases from a clean, reproducible pipeline, not a developer's laptop.
• Keep signing keys and certificates in a secured store with more than one person able to recover them. Losing an Android upload key or an iOS certificate at the wrong moment is a classic launch-day crisis.
• Increment version and build numbers deliberately, and tag the commit that produced each release.
• Strip or protect secrets; assume anything inside the app binary can be extracted.

Test on real conditions

• Test on real devices across a few operating system versions and screen sizes, including an older, slower device.
• Test fresh install, upgrade from the previous version, and upgrade with existing local data. Migration bugs are common and painful.
• Test poor network, no network, interrupted sign-in, and returning from the background after a long time.
• Check accessibility basics: dynamic type, screen reader labels, contrast, touch target size.

Release gradually

Use staged rollout where the store allows it: start with a small percentage of users, watch crash and error rates, then widen. For major changes, consider a feature flag so a problematic feature can be disabled remotely without a new store release.

Plan a force-update path for the day a critical bug or API change requires old versions to upgrade. Add it before you need it, because you cannot add it to versions already installed.

Watch it after launch

• Crash reporting and performance monitoring, with alerts, from the first release.
• Track the crash-free sessions rate per version, and compare each release against the last.
• Monitor reviews and support channels for the first days; real users find things testers do not.
• Have a rollback plan: halt the staged rollout, disable the feature flag, or ship a fast fix. Know in advance who decides.

What to take away

Treat a mobile release as a process with a checklist: current store rules, honest privacy handling, a reproducible signed build, realistic testing, a gradual rollout and active monitoring. The goal is a launch week that is boring.