App store review: the questions we get asked most

Every audit we run turns up some version of this. The questions about app store review that come up most often on our calls.

Mobile releases are slower to correct than web ones, so the cost of shipping a mistake is higher. It rarely shows up as a line item, which is exactly why it slips.

Do we need to care about this?

Build review time into the release plan, not around it. The reasoning matters more than the rule, because the rule has exceptions. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. Small and consistent beats large and occasional here.

How do we know it is working?

Keep a build ready in case a hotfix is needed. Where this goes wrong is almost never a lack of knowledge. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

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

If any of that sounds like a description of your current setup, it is fixable.