A short guide to app store review

We end up explaining this on discovery calls often enough that it deserved writing down. Everything we would tell a client about app store review in the time it takes to drink a coffee.

Mobile releases are slower to correct than web ones, so the cost of shipping a mistake is higher. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

What is actually at stake

Build review time into the release plan, not around it. In practice this is a scheduling problem more than a technical one. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

What good looks like

Rejections are usually about policy, not code quality. In practice this is a scheduling problem more than a technical one. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

What to watch for

Keep a build ready in case a hotfix is needed. The teams that handle this well are rarely the ones with the biggest budgets. Assume whoever inherits this will have half your context and none of your patience.

How to tell if yours is fine

The version of the app your customers are running is rarely the one you just shipped. Three things worth confirming about app store review before you move on:

• Someone can say what the current setup is without going to look
• Build review time into the release plan, not around it — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.