The App Store Rejections That Catch Teams Repeatedly

A rejection at submission is an expensive kind of late. The work is done, the launch is scheduled, and the fix plus re-review costs days. Most rejections are predictable, and the predictable ones are avoidable at design time.

The ones that catch teams repeatedly

Account deletion

If your app lets users create an account, it must let them delete it from inside the app — not by emailing support, not by visiting a website. The deletion must remove the account, not merely deactivate it. This is checked, and it rejects apps that have shipped for years without it.

Sign-in requirements

Requiring an account to use features that do not need one draws rejections. If most of the app works without identity, let people in without identity. Where you offer third-party social sign-in, the platform's own equivalent is generally expected alongside it.

Payments going around the store

Digital goods and subscriptions consumed inside the app must use the platform's purchase system. Linking out to your own checkout for those is the single most reliable way to be rejected. Physical goods and real-world services are the exception — and the boundary is narrower than most teams assume.

Permissions without a reason

Every permission request needs a usage description that explains the actual benefit to the user. "This app needs camera access" is not a reason. Requesting permissions the app does not visibly use is worse than not requesting them.

Incomplete review access

If the app needs credentials, provide a working demo account. If functionality is behind a region, a device capability or hardware, say so in the review notes and include a video. Reviewers reject what they cannot reach.

Placeholder content

Lorem ipsum, broken links, test entries, a privacy policy URL that 404s. Submission is not the time to find these.

The categories under extra scrutiny

Health, finance, children's apps, dating, and anything AI-generated. Expect to document data handling, content moderation and age-appropriateness in more detail. Build the documentation as you build the feature; assembling it retrospectively under launch pressure is miserable.

Practical process

• Read the guidelines before designing the monetisation model, not after building it.
• Submit a build to review a week before you need it approved, even if content is not final.
• Keep review notes accurate and specific. Vague notes invite questions, and questions cost a review cycle.
• When rejected, read the citation and respond to that clause specifically. Arguing generally extends the loop.

Treat it as a dependency

App review is a system you depend on and do not control, with a variable response time. Plan for it the way you plan for any such dependency: start earlier than feels necessary, and never couple a hard external date to a first submission.