Launching an app on both stores at once is where good apps go to have a bad week. This iOS Android app release checklist is the one we run before any client app goes live: it covers testing, store paperwork, privacy, staged rollouts and launch-week monitoring, in the order that actually prevents launch-day panic. If you work through it honestly, the worst thing that happens on launch day is a quiet afternoon.
It is written for founders shipping a first version, and for teams shipping an update to an app people already depend on.
The iOS Android app release checklist, phase by phase
Think of a release as five gates, not one event: build quality, store readiness, privacy and compliance, rollout, and launch-week watch. A failure at any gate costs more than the gate before it. A crash found in testing costs an hour. The same crash found by ten thousand new users costs your rating, your ranking and a week of damage control. Work the gates in order and do not let launch marketing pressure you into skipping one.
Gate 1: Freeze the build and prove it works
Pick a release candidate and stop adding features to it. Every change after the freeze restarts your testing clock in spirit, even if no tool enforces it. Tag the build in version control, record the version number and build number, and make sure the build your testers install is byte-for-byte the build you submit. “It worked on the developer’s phone” is not evidence.
- Crash-free sessions above 99.5%. Watch Firebase Crashlytics or Sentry across at least the last few hundred sessions, not just the last ten. A crash that hits 1% of sessions will hit hundreds of users on launch day.
- Cold start under two seconds on the slowest supported device. Test on a cheap Android phone from three years ago, not just the latest iPhone. Your users’ devices are older than your team’s.
- Every screen reachable from a cold install. Tap through onboarding, settings, empty states, error states and the account-deletion flow. Placeholder text, dead buttons and lorem ipsum in production are rejection and review bait.
- Payments end to end, in both stores’ sandboxes. Test purchase, restore, refund and subscription cancellation. Payment bugs are the most expensive bugs an app can ship, because they take money wrongly or block it entirely.
- Offline and poor-network behaviour. Airplane mode, a throttled connection, and a connection that drops mid-upload. Apps that freeze or lose data here get deleted within minutes.
For iOS, run the release candidate through TestFlight with external testers — TestFlight supports up to 10,000 external testers per build, and builds stay valid for 90 days. For Android, use Play Console’s internal, closed and open testing tracks in that order. Do not treat your own team as the test group: your team knows how the app is supposed to work, so they unconsciously avoid the paths that break it. Our guide to the mobile app testing checklist covers device coverage and beta structure in more depth.
Gate 2: The store-specific traps that delay launches
The two stores reject apps for different reasons, and the traps are almost always paperwork, not code. Budget a full week for review and paperwork even though most reviews complete faster — Apple typically reviews within 24 to 48 hours and Google within one to three days for established apps, but a first submission, a new in-app purchase or an unusual permission can stretch that considerably.
Google Play: the 12-tester rule for new personal accounts
This is the single most common launch-date killer for first-time Android publishers. If your Google Play developer account is a personal account created after 13 November 2023, you cannot go straight to production: you must first run a closed test with at least 12 testers opted in continuously for at least 14 days, then apply for production access. Google lowered the minimum from 20 testers to 12 in December 2024, but the 14-day window stayed. Organisation accounts are exempt, which is one more reason to register as a company if you are building a business rather than a hobby project. Recruit 15 to 18 testers, not 12, so one dropout does not sink the count, and start the clock the day you open the account — not the day the app is finished. A clear explanation of how the 12-tester rule works in practice is worth reading before you plan a launch date around it.
Apple: review notes are half the submission
Write your App Store review notes as if the reviewer has never seen your app, because they have not. Give them a test account, explain exactly what to try first, and flag anything that needs location, Bluetooth, camera or a specific test card. A large share of “more information needed” rejections disappear with a thorough note. Complete the content rating questionnaires honestly on both stores — an incorrect rating triggers rejection and, worse, a rating correction after launch. And finish the privacy work before submission: Apple’s privacy nutrition labels and Google’s Data safety section must match what the app actually collects, including third-party SDKs. If an analytics SDK collects device identifiers, that is your disclosure to make, not the SDK vendor’s problem to hide.
Metadata is a launch asset, not an afterthought
Screenshots sell the app before anyone reads a word of description, so capture them from real devices at the required sizes for both stores, showing the app’s actual value in the first two frames — not a splash screen and a login wall. Write the description around the problem the app solves, not a feature list. Finally, decide your release timing deliberately: on Apple, choose manual release so an approved build waits in Pending Developer Release until you press the button, which lets you synchronise the iOS and Android go-live instead of one store leaking a day early.
Gate 3: Roll out in stages, not all at once
Never ship to 100% of users on day one. A staged rollout turns a potential catastrophe into a support ticket. On iOS, phased release for automatic updates spreads an update over seven days — 1%, 2%, 5%, 10%, 20%, 50%, then 100% of users with automatic updates on — and can be paused for up to 30 days in total. Note that it applies to updates, not to your very first version, and that users can still install the update manually at any time. On Android, Play Console’s staged rollout lets you choose your own percentages and pause between stages. The mechanics differ; the discipline is identical: advance only when telemetry at the current stage is clean. A detailed walkthrough of phased release and App Store Connect review covers the states and pause rules if you want the fine print.
Set halt criteria before you start, in writing, in the release ticket. Ours are: crash-free sessions below 99% at any stage, any payment failure above baseline, any new crash in the top three crash groups, or a support inbox pattern pointing at the same broken flow. If a criterion trips, pause the rollout, fix, and ship a new build — do not “wait and see” through a weekend. Also plan the rollback honestly: on mobile there is no true rollback to an old version for users who already updated, so your real rollback is a fast follow-up fix plus, on Android, halting the staged rollout before it reaches more users. That is why the staged percentages exist. Use them.
From our experience: the gotchas that do not appear in store docs
After shipping apps for clients across nine-plus years and hundreds of projects, the failures we see most are boring, which is exactly why teams miss them. First, the backend is part of the release: a launch that doubles traffic will find the missing database index, the unscaled push provider and the third-party API rate limit within an hour. Load-test the launch path and confirm your backend costs — push, auth, storage and AI features are where an app quote usually hides its real running costs, as we explain in our piece on mobile app backend costs. Second, feature flags beat hotfixes: ship risky features behind a remote flag so you can turn them off without a store review cycle. Third, someone must own the launch weekend — named, reachable, and not on holiday. Fourth, prepare the support answers before launch: the top ten questions, the refund wording, and the escalation path for a payment complaint. Launch-week support is a product feature, not an afterthought.
And one honest limitation: no checklist removes risk entirely. What it does is move failures earlier, where they are cheap, and shrink the blast radius of the ones that slip through. If your timeline cannot fit testing, staged rollout and a staffed launch week, move the launch date — users forgive a late app, not one that loses their data on day one.
Gate 4: Launch week — what to watch
- Crashes and hangs by version, daily. Compare the new version against the previous one, not against zero. A new crash group in the top five is a release blocker for the next stage.
- Store reviews and ratings trend. Reply to negative reviews within a day, with a fix or a workaround, not a template. Early reviews set the tone for months.
- Onboarding completion and first core action. If installs are healthy but activation drops, the problem is the first-run experience, not marketing.
- Payment success rate and refund requests. Any dip here outranks every other metric until explained.
- Support inbox themes. Three tickets about the same flow are a bug report, even if nobody uses the word bug.
Frequently asked questions
How long does an app store release take from submission to live?
For an established app with clean paperwork, typically one to three days: Apple usually reviews within 24 to 48 hours and Google within one to three days. For a first Android release on a new personal account, add at least three weeks: 14 days of closed testing plus up to seven days for the production-access review. Plan backwards from your marketing date, not forwards from your code-freeze date.
Do I need to release on iOS and Android on the same day?
No, and for a small team it is often wiser not to. Shipping Android first (or vice versa) lets you fix launch issues with half the audience exposed. If you do want a synchronised launch, use Apple’s manual release option so the approved iOS build waits until you release the Android build too.
What is a staged rollout and should every app use one?
A staged rollout releases a new version to a growing percentage of users — on iOS, 1% to 100% over seven days for updates; on Android, percentages you choose in Play Console — so problems surface with a small audience first. Every app with real users should use one for updates. The only exception is a critical security fix, where speed matters more than staging.
What causes most app store rejections?
In our experience, the top causes are incomplete review notes (the reviewer cannot test the app), privacy disclosures that do not match actual data collection, placeholder or broken content reachable from a cold install, and incorrect content ratings. All four are paperwork and polish, not deep engineering — which is why a checklist catches them.
Can I roll back an app update if it has a serious bug?
Not in the way websites roll back. Users who already updated cannot be forced back to the old version. Your real options are pausing the staged rollout so no more users get the bad build, and shipping a fix as fast as the stores allow — Apple offers expedited review for critical bugs. This is exactly why feature flags and staged rollouts matter more than any post-launch heroics.
If you are planning a launch and want a second pair of eyes on the release plan — or a team to run it for you — talk to us about our mobile app development services, or contact us with your launch date and we will tell you honestly whether it is realistic. A calm launch is not luck. It is a checklist, worked in order, with nobody skipping a gate.