the short version
- The four-week plan is the work. The run sheet is the day. This list is the boring stuff that moves the date if you skip it.
- Submit at least a week early and set the version to release manually, so approval doesn’t mean surprise.
- Review needs a way in: a demo account, a privacy policy, a support link, and an age rating that matches the app.
- The night before is for checking the store link on someone else’s phone, not for new screenshots.
In this post6 sections
Launch dates slip for glamorous reasons in the retelling, and for dull ones in the group chat. Review asked for a demo login. The privacy policy 404’d. The screenshots were the wrong size. The build went live at 3am because nobody set it to wait.
The four-week plan is how the creative work gets done. The launch-day run sheet is the day itself, hour by hour. This is the list between them: working back from the date, the things that have to be true so the date survives contact with App Review and with a real phone.
None of it is a guarantee about how fast review will be. “Often quick” is not a plan. A week of slack is.
Count back from the date
Put the launch date in the calendar first. Then put these next to it, working backwards. If a box can’t be ticked by its day, the date moves on purpose, once, and everyone hears the same day. That’s the same rule as the four-week plan, applied to paperwork.
| When | What has to be true |
|---|---|
| Two weeks out | The version you intend to ship exists, and someone besides you has installed it. Android closed testing, if it applies to your Play account, has already started. Confirm the current rule in Play Console; it can be longer than a week, which is why it isn’t a launch-week task |
| One week out | The build is submitted. Release is set to manual. The listing fields that travel with the version are filled in |
| Three days out | Review has the demo account, the policy links work, and you’ve answered anything they asked |
| The night before | The binary is approved and waiting. Store links work on a phone that isn’t yours. No new creative |
| Launch morning | You press release. Then the run sheet takes over |
If you’re only on the App Store, ignore the Play line. If you’re on both, don’t let the slower store silently become your launch date without deciding that it is.
One week out: submit the build you mean
Submit the release build, not a cousin of it. The screenshots, the preview, the description, the subtitle and the “what’s new” text go through review with that version. Promotional text is the exception: you can change it later, which is why the listing-copy post treats it as a weekly line rather than a vow.
Set the release to manually release this version. Approved should mean “waiting”, not “live while you were asleep”. You can still launch in the morning by pressing a button. You can’t un-launch a surprise.
Before you press submit, on a device that isn’t the one you develop on:
What you hand review, besides the binary
App Review is a person with a queue, not a puzzle for you to win. Give them a front door.
A demo account, in the review notes, if the app needs a login. Username, password, and one sentence on how to reach the good bit (“tap the sample fridge on the home screen”). If the account expires, it isn’t a demo account. If two-factor texts your personal phone, say so and make sure you’ll see it, or turn it off for that user.
A privacy policy URL that loads, on the domain you actually use, and an App Privacy section (the nutrition labels) that matches what the app does. If you aren’t sure whether you collect something, read your own SDK list before you tick “no”. A wrong “no” is a worse week than a slow “yes”.
A support URL that reaches a human. An inbox you check counts. A link to a landing page with no contact doesn’t.
An age rating you’ve actually clicked through. Don’t accept the default and hope. If the app has user-generated content, payments, or nothing of the sort, the answers differ, and they’re yours to get right.
Sign-in. If you offer Google or another third-party login, check Apple’s current rule on whether Sign in with Apple is required too, and sort it before review does.
Notes, short. What the app does, in the one sentence. Anything weird (“the map is empty until you add a meal; the sample account already has three”). What you don’t need to write: a pitch.
Three days out: the listing is finished
By now the creative arguments should be over. This pass is clerical.
If review has written back, answer in the notes, plainly, and attach a new build only if you actually changed the build. A new binary restarts the wait. A clear reply often doesn’t.
The night before
No new screenshots. No new headline. No “quick” refactor.
Then sleep. Launch morning is a button and a lot of replying. It is a bad time to discover that the privacy policy was a draft on someone’s laptop.
If this list feels like the whole job
It isn’t. It’s the railing. The work is still the sentence, the screenshots, the page, the film and the day, which is what the other posts are for, and what an Ignite launch is: four weeks, from £16,000, on the pricing page. The launch-day package on its own (the plan, then we run the day with you) is one week plus the day, from £2,000.
We haven’t run a client’s launch day yet. We’re a new studio, and we’d rather say that than hand you a checklist full of war stories we don’t have. The list above is the one we’d run with you, and the one you can run without us.
If your date is already in the calendar and you want someone to walk this list against it, book a free 15-minute call. Bring the date. We’ll tell you which box is the one that will slip.
