App store review for small teams

It comes up on almost every project, usually later than it should. Most advice about app store review assumes a team that does not exist at your size. Here is the version that does not.

Mobile releases are slower to correct than web ones, so the cost of shipping a mistake is higher. Budget a little time for it every quarter and it never becomes a project of its own.

What to keep

Build review time into the release plan, not around it. In practice this is a scheduling problem more than a technical one. Assume whoever inherits this will have half your context and none of your patience.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. The cost of getting this wrong is rarely visible on the day it happens.

The practical version

Keep a build ready in case a hotfix is needed. The cost of getting this wrong is rarely visible on the day it happens. It rarely shows up as a line item, which is exactly why it slips.

In practice

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
• Rejections are usually about policy, not code quality — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.