Rejection at app review is rarely bad luck. It falls into a handful of well-documented categories, and almost all of them are decided long before the build is finished - in scoping, in the data model, in how the product makes money. By the time you are filling in the submission form, most of the outcome is already fixed.
PixelForce holds a 98 percent first-time app store approval rate across 100+ shipped products. That figure is not the result of a better submission checklist. It is the result of treating review as a design constraint from the first week.
The rejection that is really a scoping failure
Apple's guideline 4.2, Minimum Functionality, asks that an app include features, content and interface that elevate it beyond a repackaged website. Guideline 4.2.2 goes further, ruling out apps that are primarily marketing material, advertisements, web clippings, content aggregators or collections of links.
This is the one that catches businesses who wanted an app because the competitor has one. If the product is your website in a shell, no amount of submission care will fix it, because the objection is to the concept rather than the execution.
It is worth knowing early for a second reason: guideline 4.2.6 rejects apps built from commercialised templates or app generation services unless submitted directly by the content provider. A cheap templated build can be unshippable on those grounds alone, which is a poor thing to discover after paying for it.
Payments, and the 30 percent question
Guideline 3.1.1 requires in-app purchase for unlocking features or functionality - subscriptions, in-game currencies, levels, premium content, the full version - and rules out your own mechanisms such as licence keys or QR codes. Credits bought through in-app purchase may not expire, and loot boxes must disclose odds before purchase.
The commercial consequence is that the platform fee is a business-model input, not a launch-week detail. We would rather have that conversation during scoping, when there is still room to change what is sold and how, than during review when the only options are to comply or to cut the feature.
Privacy and permissions
Guideline 5.1.1 is the densest part of the rulebook and it catches good teams. It requires a privacy policy linked both in App Store Connect and inside the app, stating what data is collected, how, every use of it, which third parties receive it - analytics, advertising and SDKs included - and how a user revokes consent or has data deleted.
Three specifics account for a large share of the trouble:
- Purpose strings. Consent is required even for anonymous data, and the purpose string must clearly describe the use. A generic string is a rejection.
- Data minimisation. Request only what the core functionality needs, and prefer a picker or share sheet over full library access.
- Account sign-in. If the app has no significant account-based features, it must be usable without a login. If it does support account creation, it must offer account deletion from inside the app.
That last point is an architecture decision, not a screen. Deleting an account cleanly across a backend that was not designed for it is a real piece of work, and finding out at review is the expensive version.
Metadata, which is nobody's job
Guideline 2.3 asks that metadata accurately reflect the core experience. In practice the recurring problems are small and avoidable: screenshots must show the app in use rather than title art or a login screen (2.3.3), previews may only use captured video of the app itself (2.3.4), and where in-app purchases exist the description and screenshots must make clear which items cost extra (2.3.2). App names are limited to 30 characters, and packing keywords with trademarked or irrelevant terms is explicitly called out (2.3.7).
Metadata rejections are frustrating precisely because they are cheap to avoid and they still cost a full review cycle. They happen when submission is treated as an administrative task handed to whoever is free.
What a rejection actually costs
The direct cost is a review cycle. The real cost is that launch dates are usually attached to something else - a campaign, a partnership, a funding milestone, a season - and those do not move because a build was resubmitted.
The counter-example is what a clean launch buys you. Revia reached number 3 in Apple's Health and Fitness category within 48 hours of launch, after a 4-month build. NKO Club drew more than 10,000 members within 24 hours of launch, on auto-scaling infrastructure that held without degrading. Neither of those windows survives a rejected submission.
How to make review a non-event
Decide the monetisation model and the account model during scoping, not during the build. Write the purpose strings when the permission is added rather than the week before submission. Treat account deletion as a backend requirement. Take the screenshots from the real product.
None of that is difficult. It is simply work that has to happen early, and it is the difference between review being a formality and review being a risk. Review sits at the end of a longer sequence, which how long it takes to build an app sets out in full, and the day after approval the clock starts on what it costs to run the app.
If you are approaching a submission and are not certain which of these apply to you, it is cheaper to check now than to find out from a reviewer.