What the App Store actually rejects.

Most teams treat App Review as the last step. You build the app, you submit it, and then you find out. That order is the problem, and it is the reason review is so often the part of shipping that runs weeks longer than the plan allowed for.

The guidelines are not a document, they are a moving target

Apple's review guidelines change most months. Rarely dramatically, and rarely with an announcement that anyone outside the process notices, but they change. Reading them once at the start of a project gets you a snapshot that is already out of date by the time you submit.

So we keep people on this whose job is the store rather than the product: what changed, what Apple is asking for now, what it started asking for last month. Across more than 100 App Store accounts and around 80 apps in review at a time, a new rejection reason shows up in three different places inside a week. That is how you find out early, and there is no substitute for the volume.

Rejection is rarely the worst outcome

An outright rejection is at least clear. The expensive one is the outcome that looks like progress. You submit, Apple asks for something, you change it and resubmit, Apple asks for something else. Weeks of messages, sometimes months, between a team that wants to launch and a reviewer working from a rulebook nobody on the team has read. The product is finished. The launch is not.

The fix happens in design, not in review

Nearly everything a store is going to ask for can be settled before anyone writes code:

• What the app does before a user signs in, and whether there is anything to see without an account at all.
• Every permission you ask for, and a reason for it the user can read.
• Subscription terms where the store expects them, at the size it expects, next to the price.
• A way to delete an account inside the app, not by emailing you.
• Screenshots that show the app rather than a marketing frame with the app inside it.

We build all of that into the design phase, on the strength of a few hundred previous rejections rather than a reading of the current guidelines. At that stage it costs nothing. At the other end it costs a launch date.

The newest reason, and the fastest growing

Apple has started rejecting apps for being generated rather than built. Something assembled from a prompt, with no real function behind it, is now one of the more common reasons to be turned away, and it has been climbing for months. It will climb further.

It is worth reading that correctly. AI-assisted development is not what is being penalised, and we use it about as heavily as a company can. What the store has started filtering for is whether an app is usable at all, because enough people can now produce something that installs and does nothing. The bar moved from whether you can make it to whether it is worth anyone's money, and review is where that gets enforced.

If you are shipping one app rather than eighty

You will not build the review knowledge that comes from doing this at volume, and you do not need to. What you need is to stop treating review as a formality at the end. Read the guidelines for your category before the design is signed off rather than after the build is done, assume the version you read is slightly out of date, and budget time for the exchange. It is a conversation, not a gate.