App Store Rejection: the 12 Most Common Reasons and How to Fix Each

App Store review rejects roughly 35% of submitted apps on first review. Most rejections are for the same handful of reasons, repeated across apps. After 12 apps shipped (and more than a few rejections debugged), the patterns are clear. This guide walks through the 12 most common rejection reasons, with a concrete fix for each.

The headline rule: read the rejection email carefully. Apple cites a specific guideline number (e.g. 2.1, 4.0, 5.1.1) - that number tells you which family of fix applies. Treat the email as a structured diagnosis, not a vague hint.

Reasons 1-6: technical and design

1. Guideline 2.1 - Crashes on launch or in core flow. The reviewer launched your app, did the obvious thing, and it crashed. Fix: test on the exact device model Apple Reviewer mentioned (usually an iPhone XR or iPad mini). Run Instruments with allocations tracking. Submit a TestFlight build to internal testers first.

2. Guideline 2.1 - In-app purchase unresponsive. The paywall appeared but tapping "Subscribe" did nothing. Almost always because the app uses bare RevenueCatUI.PaywallView() without passing an explicit offering, and the RevenueCat fetch silently hangs in the sandbox network environment. Fix: pass the offering explicitly, add an 8-second timeout, show a fallback UI.

3. Guideline 4.0 - Design unsuitable for App Store. Usually means: too plain, looks unfinished, copies another app, or uses placeholder content. Fix: take design seriously - proper icon, proper screenshots with framing, proper onboarding. Open the app from a stranger's perspective and look for "this is a demo" cues.

4. Guideline 4.3 - Spam / duplicate of existing app. Hits apps that look like cookie-cutter copies of competitors. Fix: differentiate clearly - different feature set, different content, different value proposition. Submit a clear written explanation if your app legitimately competes with a similar app.

5. Guideline 5.1.1 - Data collection without privacy policy. You collect data (any data: name, email, analytics events) without a privacy policy URL in App Store Connect, or your privacy policy doesn't disclose what's collected. Fix: add a privacy policy URL, list every data point collected, list every third-party SDK that receives data.

6. Privacy manifest missing or incomplete. Since spring 2024, apps must include a PrivacyInfo.xcprivacy file declaring required-reason API usage. Most rejections cite NSPrivacyAccessedAPICategoryUserDefaults because every app uses UserDefaults.standard but few apps declare it. Fix: add the manifest with reason code CA92.1 for UserDefaults.

Reasons 7-12: content and metadata

7. Guideline 2.3.7 - Inaccurate metadata. Your app description claims features that don't exist, your screenshots show UI not present in the build, or your title contains keywords unrelated to actual functionality. Fix: every metadata claim must match what the reviewer sees when running the app.

8. Guideline 2.3.10 - Reference to other platforms. Your description mentions "Android version" or your screenshots include an "Available on Google Play" badge. Fix: scrub all references to non-Apple platforms from description, screenshots, and in-app text.

9. Guideline 4.1 - Copying intellectual property. Your app uses a celebrity name, brand logo, copyrighted character, or licensed font without authorisation. Fix: remove all unlicensed content. If you have a licence agreement, attach it via App Review notes.

10. Guideline 5.1.2 - Sharing data with third parties without disclosure. You ship analytics SDK, crash reporting, ads - and don't disclose this in the privacy nutrition labels. Fix: complete the App Store Connect privacy questionnaire honestly. Every SDK that receives user data must be declared.

11. Subscription terms unclear. Your paywall doesn't clearly state: subscription price, billing period, that subscription auto-renews, where to cancel, link to Terms of Use, link to Privacy Policy. Fix: every subscription paywall must include all five. Apple has a clear checklist - follow it line by line.

12. App Store description missing required boilerplate. For subscription apps, the App Store description (en-US) must end with: "Privacy Policy: [URL]" and "Terms of Use: https://www.apple.com/legal/internet-services/itunes/dev/stdeula/" (or your own EULA URL). Missing this is a common metadata rejection.

Quick comparison

Common pitfalls and how to avoid them

Across every domain this article touches, the same shape of mistake recurs. Practitioners new to the field overweight the most visible piece of the system — the screenshot, the paywall, the exam question, the headline price — and underweight the underlying constraint that actually determines outcomes.

The five most common failure modes:

1. Optimising for the demo, not the durability. A working demo in a controlled environment proves nothing about reliability under real conditions. In iOS development, an in-app purchase flow that works in the Xcode Simulator says nothing about how it behaves in App Store sandbox with network latency and Ask to Buy approvals. In an exam, a 100% score on an untimed quiz tells you nothing about whether you can do 49/50 in 45 minutes with no second guesses. Build for the hardest realistic case from the start.
2. Skipping the first-principles documentation. Every system has a canonical specification. App Review Guidelines for iOS, the official EU regulations for tax deductibility, the CITB question bank for CSCS, the OMIE market rules for Spanish electricity. Reading them takes a few hours but saves weeks of wrong-direction work. Secondary sources (blogs, tutorials, this article included) are useful as orientation but never authoritative.
3. Ignoring the rate limit. Every external system has rate limits — explicit (APNs silent push throttling, RevenueCat API quotas, exam retake fees) or implicit (App Review patience, customer attention spans, your own working memory). Plan around them. A workflow that requires more rate-limited operations than the system allows will fail in production, not on day one but during the first stress event.
4. Underweighting localisation and regional variation. What is true for Germany is not always true for Italy. What is true for English-speaking users is not always true for Japanese ones. What is true for the UK CSCS test is not always true for the Irish equivalent. Always check the local rule before applying a general one.
5. Treating the documentation as static. Apple updates App Review Guidelines. The Bundeslaender change Schonzeiten. OMIE adjusts market clearing algorithms. Set up a periodic review (quarterly is enough for most things) and re-read the canonical sources. Workflows that worked perfectly a year ago can be silently broken today.

None of these are dramatic. The dramatic mistakes (catastrophic bugs, audit findings, exam failures) are the visible tip of a longer-running iceberg of small misses. Catching the small misses is what separates routine outcomes from problematic ones.

Key takeaways

• 2.1 crashes — Most common. TestFlight before submit.
• 2.1 unresponsive IAP — RevenueCat hang. +8s timeout.
• 4.0 design — Looks unfinished. Icon, screenshots, onboarding.
• 5.1.1 privacy — Missing policy. Add URL, list SDKs.

The pattern that runs through every section above: start with the constraint, not the wishlist. In an exam, the constraint is the question bank and the pass mark. In an electricity market, it is the auction clearing rule. In a tax workflow, it is the receipt-retention requirement. In a code architecture, it is the platform's design decision (StoreKit's transaction lifecycle, App Review's guideline, APNs's authentication model). Get the constraint right and the rest follows.

The opposite failure mode — designing for an aesthetic ideal, then trying to retro-fit the constraint — is the most common cause of wasted work in every domain covered here. A beautiful paywall that hangs in sandbox is rejected at App Review. A polished freelancer expense report that lacks receipts is disallowed by the tax office. A study plan that ignores the actual question distribution leaves the candidate stuck below the pass mark.

The practical recommendation: read the official rules of whatever system you are operating in, extract the binding constraints, and treat them as inputs to the design — not afterthoughts. Every section of this article is the application of that principle to a specific domain.

FAQ

How long does an App Store review take?
Median time is currently around 24-48 hours for most apps. Some categories (kids, gambling, medical) take longer. Holidays and major iOS releases push averages up to 5-7 days.

Can I appeal a rejection?
Yes. The Resolution Center in App Store Connect lets you respond to the reviewer or escalate to App Review Board. Appeals are reviewed by a different team. Time to resolution typically 3-7 days.

Does rejection affect future submissions?
No. Each submission is reviewed on its own merits. A rejected version doesn't penalise future submissions, but persistent quality issues across many submissions can attract more scrutiny.

Should I use TestFlight before submitting to App Review?
Yes. Internal TestFlight catches crashes and obvious bugs before they hit App Review. External TestFlight (with 10-100 real users) catches edge cases the internal team misses.

Further reading and references

The references below cover the official sources for the rules cited in this article. Where applicable, they include the canonical documentation, regulatory text, or vendor-provided guides. For each one, prefer the official source over secondary commentary — secondary sources go stale fast and frequently misquote the binding rule.

• Official documentation of the system in question (linked from each app or service's own help centre).
• Apple Developer Documentation for any iOS/macOS reference — the WWDC session videos and the corresponding Human Interface Guidelines pages are the authoritative source.
• For EU regulatory questions (taxation, data protection, energy market structure), consult the relevant national authority — most publish their guidance in English.
• For Spain and Italy energy market data, OMIE and GME both publish full historical price series in CSV format from their public websites — no API key required.
• For UK CSCS prep, the CITB publishes the official question bank book each year — buy a current copy if you want the authoritative source.

If you find a contradiction between this article and an official source, the official source wins. Article rules of thumb are summaries — they have edge cases, exceptions, and regional variations that the source documents specify exactly.