The app launch checklist: two weeks before, and the day after
Everything on this list is cheap to do beforehand and expensive to discover afterwards. Most of it takes minutes and gets skipped because launch week is busy.
Key takeaways
- Verify privacy declarations against every third-party SDK; it is the most common late rejection.
- Create the demo account already in the state a reviewer needs, with non-expiring credentials.
- Test the production build against production infrastructure on a device that has never had a build installed.
- Ship a small update in the first week to prove the release process works before you need it urgently.
Launch problems are rarely surprises. They are known items that nobody completed because the fortnight before release is when everything competes for attention. This is the list, split by when it needs to happen, so that nothing on it depends on remembering during the busiest week.
Two weeks before
- Store listing complete in every language you serve, with screenshots taken from the current build rather than an older one.
- Privacy declarations verified against actual behaviour, including every third-party SDK. This is the most common late rejection.
- Demo account created, populated with the state a reviewer needs, credentials that do not expire, and review notes written for someone who knows nothing about your business.
- Support and privacy policy URLs live and resolving. Both are checked and both break embarrassingly often.
- Crash reporting and analytics verified in a production build, not just in debug.
- Backend load tested at a multiple of expected launch traffic, and a plan for what to scale if you are wrong.
The week before
Submit for review with the assumption of one rejection. Test the production build against production infrastructure on real devices, both platforms, both languages, and a throttled network. Confirm that every debug endpoint and test account is removed, and that the build points at production rather than staging. Verify push notification certificates work in production, which is a different configuration from development and fails silently.
Launch day
Release to a percentage of users if the platform allows it rather than everyone at once. Watch crash-free session rate hourly for the first day. Have someone available who can actually ship a fix, not just triage one. And confirm the app installs and opens on a device that has never had a build on it, since developer devices carry state that hides first-run problems.
The day after
Read the reviews, including the one-star ones, which are where the real problems are described. Check the funnel from install to first completed core action, which is where you find out whether onboarding works. Look at crash reports by device model and operating system version, because a crash confined to one class of device is common and quick to fix. And respond to reviews; it is visible to future users and it costs nothing.
The week after
Ship a small update. Not because there is necessarily something urgent, but because it proves the release process works end to end while the team still remembers how, and because the first genuine emergency is a bad time to discover that nobody can produce a build.
Ship a small update in week one. The first real emergency is a bad time to discover nobody can build a release.
Sources