Why Apps Get Rejected: The Nine Reasons We See Most

A rejection is rarely a surprise to anyone who has read the guidelines. It is a surprise to the business, because the decision that caused it was made months earlier by someone who had not.

These are the nine we encounter most, roughly in order of how often they catch teams out.

1. Sign-in you did not need

If your app has any account system, Apple requires that you also offer Sign in with Apple wherever you offer other third-party logins such as Google or Facebook. Miss it and you are rejected.

The better question is whether you need accounts at all before the user has seen anything. Apps that demand registration on the first screen, for content that does not require it, get rejected under a separate guideline — and they lose users regardless of what the reviewer thinks.

Avoid it by: letting people use the app first, and adding Sign in with Apple at the same time as any other social login rather than as an afterthought.

2. Payments routed around the store

If you sell digital content, subscriptions or features used inside the app, that transaction goes through the platform's billing. Linking out to your own payment page is the single most reliable way to be rejected.

Physical goods and services consumed outside the app — a delivery, a hotel room, a consultation — use ordinary payment processing and must not use in-app purchase. Teams get this backwards in both directions.

Avoid it by: deciding which category you are in during the brief, not during submission. It changes your revenue model, so it is a commercial decision.

3. A privacy policy that does not match the app

Both stores require a reachable privacy policy and an accurate declaration of what you collect. Play's Data Safety form and Apple's privacy labels are checked against actual behaviour, including what your analytics and advertising SDKs do without you noticing.

A third-party SDK collecting an advertising identifier you did not declare is your problem, not the SDK vendor's.

Avoid it by: listing every SDK, checking what each collects, and writing the policy from that list rather than from a template.

4. Permissions requested without explanation

Asking for location, camera, contacts or microphone at launch, with no context, is rejected on both platforms. On iOS, the purpose string must say specifically why — a generic sentence gets bounced.

Avoid it by: requesting each permission at the moment it is needed, with a short in-app explanation before the system dialog appears. This also markedly improves acceptance rates, so it is worth doing for its own sake.

5. Demo credentials that do not work

If any part of your app is behind a login, you must supply working credentials. Accounts that have expired, are rate-limited, or lead to an empty state that looks broken are a common cause of rejection — and it is an infuriating one, because the app is fine.

Avoid it by: creating a dedicated review account with realistic seeded data, testing it the morning of submission, and adding notes explaining anything unusual. Include a screen recording for complex flows.

6. Crashes on the reviewer's device

Reviewers test on current OS versions and often on iPad even when you did not intend to support it. A crash on launch is an immediate rejection.

Avoid it by: testing on the newest OS, the oldest you claim to support, and a tablet. If you do not support tablets, say so properly in the configuration rather than letting the app run badly.

7. Not enough to be an app

"Minimum functionality" is a real and frequently applied rule. A wrapper around your website, a simple feed with no interaction, or something that could plainly be a web page gets rejected as not offering enough.

Avoid it by: being honest early about whether you need an app at all. Our post on choosing between a mobile app and a web app covers the decision — and if the answer is that you do not need an app, the store will eventually agree with you.

8. Placeholder content

Lorem ipsum, empty sections, features that say "coming soon", broken links in the footer, a support URL that 404s. Reviewers open these.

Avoid it by: shipping fewer features that are finished rather than more that are half-built.

9. Metadata that oversells

Screenshots showing functionality that does not exist, a description mentioning platforms you do not support, keyword stuffing in the title, or claiming a partnership you cannot evidence. Medical, financial and health claims attract particular scrutiny and often require documentation.

Avoid it by: writing store listings from what the app does today.

The submission routine we use

The build is frozen and tested on the newest OS, the oldest supported, and a tablet. A fresh review account is created and tested that morning. Reviewer notes explain anything non-obvious, with a screen recording for complex flows. Privacy declarations are rebuilt from the SDK list rather than copied from the last release. Every URL in the listing is opened and checked. And submission happens at the start of the week, never the Thursday before a launch.

If you are rejected

Read the guideline they cite, not just the message. Fix the actual cause. If the reviewer has misunderstood, reply in the review system with a plain explanation and a recording — appeals succeed more often than people assume.

What does not work is resubmitting an almost identical build hoping for a different reviewer. That pattern gets noticed.

If you have an app heading for submission and want the review-readiness pass done before you burn a week, get in touch.