The App Launch Checklist: What to Verify Before You Ship

The build is finished. That is roughly half the work.

Teams shipping their first app almost always underestimate the same stretch: the fortnight between "the build works" and "it is live and supportable". Very little of that stretch is engineering. It is store compliance, privacy declarations, support readiness, analytics that actually record something useful, and a plan for the moment something goes wrong at 2am.

This is the checklist we run before a release goes out, organised as six gates. Each gate has an owner and a pass condition. If a gate does not pass, the launch moves — which is far cheaper than a rejected submission or a bad first week of reviews.

The six gates

Gate 1 · Build integrity (T−14)

• The submitted build is the build you tested — verify the version and build number, not the branch name.
• No placeholder content anywhere: no lorem ipsum, no "coming soon" screens, no test images.
• Every screen reachable by a reviewer actually works. Reviewers explore; they will find the half-built settings page.
• Demo credentials supplied if any part is behind a login, and verified working the day you submit.
• Third-party sign-in, payments and push all tested against production credentials, not sandbox.
• Crash-free session rate measured on a real device fleet, not just a simulator.

Apple's App Store Review Guidelines open with app completeness for a reason: an unfinished-feeling build is the most common avoidable rejection, and the fix is almost always a checklist rather than engineering.

Gate 2 · Store compliance (T−10)

• Listing copy proofread by somebody who did not write it.
• Screenshots current, correctly sized for every required device class, with no stale UI.
• Age rating answered honestly, including user-generated content and external links.
• If you sell digital goods, they use the platform's in-app purchase where the rules require it.
• No mention of other platforms, prices or payment routes that the store forbids.
• Support URL and marketing URL both live — not a placeholder domain.

Read the Google Play Developer Policy and Apple's guidelines against your actual listing, not from memory. Both change, and both are enforced on submission.

Gate 3 · Privacy and data (T−7)

This is the gate that fails most often, because declarations drift from behaviour as the build changes. Both stores compare what you declare against what your app actually transmits.

• Privacy policy live at a stable URL, and genuinely describing this app.
• Apple's App Privacy details completed to match reality, including data collected by every SDK you embed.
• Google Play Data safety form completed on the same basis.
• Tracking consent requested properly where required, before any tracking begins.
• Every third-party SDK audited — analytics, crash reporting, ads and attribution all collect data on your behalf, and it is your declaration that is wrong if theirs is undisclosed.
• Account deletion available in-app if you offer account creation.
• Data retention and deletion decided and documented, not left implicit.

Gate 4 · Accessibility and quality (T−5)

• Every interactive element has an accessible label, and the screen reader order makes sense.
• Touch targets meet the platform minimum, and the layout survives the largest system font size.
• Contrast checked against WCAG 2.2 — the same standard applies to your marketing site, which reviewers and customers also visit.
• Dark mode, rotation and small screens all tested rather than assumed.
• Offline and slow-network states handled with something better than an infinite spinner.
• Empty states designed — a brand-new user sees them first, and they are usually the last thing built.

Gate 5 · Observability and rollback (T−2)

You cannot fix what you cannot see, and you cannot recover from what you cannot switch off.

• Crash reporting live in the production build, with alerting to a channel someone reads.
• Analytics events for the two or three moments that actually matter — activation, first key action, purchase. Not two hundred events nobody will ever query.
• Staged rollout configured where the platform supports it. Start at a small percentage; there is no prize for shipping to 100% on day one.
• A server-side kill switch for anything risky. Client releases take days to propagate; a remote flag takes seconds.
• Backend capacity checked against realistic launch-day traffic, including the spike if any press or campaign lands.
• The previous version's backend still works — users will not all update at once, and often never will.

Gate 6 · Support and the first week (T+7)

• Support inbox monitored by a named person with a response-time expectation.
• A short FAQ published before launch, covering the questions you already know are coming.
• Store reviews monitored and answered — early reviews shape the ranking that shapes everything else.
• A dated decision point for the first patch release, so fixes do not drift.
• Day-seven review of the metrics you instrumented at Gate 5, against a target written before launch.

Frequently asked questions