How to get app store review right
It is rarely the thing that gets a project approved, and often the thing that decides how it goes. The short answer to app store review is that it is mostly a sequence of small decisions, not one big one.
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.
The reason this keeps coming up
Build review time into the release plan, not around it. There is a version of this that is over-engineered, and it is worth avoiding. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
The steps
- Establish what you have today before changing anything
- Rejections are usually about policy, not code quality
- Keep a build ready in case a hotfix is needed
- Write down the decision so the next person does not re-litigate it
Keep a build ready in case a hotfix is needed. Small and consistent beats large and occasional here. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.
What to do next
What this looks like day to day
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
- Keep a build ready in case a hotfix is needed — 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.