App store review: what to get right first

It comes up on almost every project, usually later than it should. If you only fix one thing about app store review this quarter, make it the first item below.

You do not control the device, the network, or the operating system version, and the design has to accept that. The version that survives contact with a real deadline is the simple one.

Start here

Build review time into the release plan, not around it. None of that requires a large budget, only a decision and someone to own it. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Then this

Rejections are usually about policy, not code quality. In practice this is a scheduling problem more than a technical one. Doing this properly once is usually cheaper than doing it approximately three times.

Eventually

Keep a build ready in case a hotfix is needed. Getting it slightly wrong is survivable. Ignoring it entirely is not. Assume whoever inherits this will have half your context and none of your patience.

The short version

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 any of that sounds like a description of your current setup, it is fixable.