App Store rejection reasons and how to fix them
The top App Store rejection reasons in 2026 are guideline 2.1 (app completeness — broken features, crashes, placeholder content), 2.3.3 (inaccurate metadata — screenshots showing features that don't exist), 4.3 (spam — duplicate or minimally differentiated submissions), and 5.1.1 (privacy — missing or inconsistent policy, mismatched App Privacy declaration). Each has a specific fix pattern that takes hours to days, which is why catching these before submission saves multiple App Review round-trips.
Step by step
Guideline 2.1 — App Completeness
Caused by crashes on launch, broken core flows, placeholder lorem-ipsum text, demo accounts without working credentials, or features that don't load. Fix: run through every flow on a fresh install before submitting, provide working login credentials in the review notes, remove any unfinished screens, and verify all network-dependent features work on Apple's review environment (which uses staging-like IPs).
Guideline 2.3.3 — Accurate Metadata
Caused by screenshots showing a feature the app doesn't actually have, app name containing marketing claims ('#1 best'), description advertising functionality that requires in-app purchase without disclosure. Fix: every screenshot must show real app UI, rename the app to remove rank claims, and note which features require IAP directly in the description.
Guideline 4.3 — Spam / Duplicate Apps
Triggered when the app is a minimally-differentiated clone of another app in your portfolio, a white-label template with thin customization, or is substantially similar to an existing app. Fix: consolidate multiple clones under one brand, add genuinely differentiated features (not just colours and names), and write a rationale in review notes if the submission is a legitimate multi-app strategy.
Guideline 5.1.1 — Privacy
The #1 subcategory is App Privacy nutrition label not matching the privacy policy text. Second is missing privacy policy URL. Third is collecting data without an opt-in or clear disclosure. Fix: reconcile the policy, App Privacy form, and any consent prompts so they say the same thing about every data type; ensure the policy URL resolves on HTTPS (not a PDF).
Guideline 3.1.2 — Subscription Disclosures
Auto-renewable subscription apps must display the duration, price per period, renewal terms, and a functional link to both the Privacy Policy and Terms of Use on the paywall. Fix: audit the paywall UI against Apple's guideline 3.1.2 checklist — many developers miss the Terms of Use link specifically.
Guideline 5.1.2 — Data Use and Sharing
Sharing user data with third parties (analytics, ads, attribution) without disclosing it in App Privacy or receiving consent. Fix: add every third party explicitly to App Privacy, implement consent flows where required, and make sure the list of third parties in your policy matches the SDKs actually shipping in the build.
Reply to the rejection via Resolution Center
For every rejection, Apple's Resolution Center gives you: the guideline cited, a specific explanation, and often a screenshot of the problem. You can reply with a clarifying message (e.g., 'The feature they flagged requires location permission; we've now added a pre-prompt') before resubmitting. Replies usually get a same-day follow-up from App Review.
How Forvibe does this
Forvibe's Review Simulation feature is trained on 400+ real App Store rejection cases — curated from public Reddit posts, r/iOSProgramming threads, Apple's own enforcement bulletins, and direct contributions from shipping developers. Before you submit, it scans your build (via the @forvibe/cli tool), your metadata, and your screenshots against each known rejection pattern and flags specific issues with the exact guideline number — most teams using it catch 1–3 avoidable rejections per submission, saving roughly 24 hours per round-trip.
See App Store Review Simulation →Frequently asked questions
What's the fastest way to get an App Store rejection overturned?
Reply in Resolution Center with a specific fix or clarification within 2 hours of the rejection. Short, factual replies ('We added the missing Terms of Use link to the paywall — new build uploaded') get faster response than long arguments. If you believe the rejection is in error, request an App Review Board appeal.
Can I resubmit the same build after a metadata rejection?
If Apple rejected only metadata (title, description, screenshots, privacy policy URL), you don't need a new build — update the metadata in App Store Connect, click 'Submit for Review' again, and the existing build stays attached. You only need a new build for binary-level rejections (guideline 2.1, 2.5.x).
How do I avoid guideline 4.3 if I legitimately have multiple similar apps?
Consolidate under one developer account with clear brand differentiation, differentiated features (not just palette and name), separate privacy policies if the apps handle data differently, and explain the portfolio rationale in review notes. Apple accepts multi-app strategies when there's a legitimate user-facing reason.
What happens if my app gets rejected three times for the same issue?
Apple may escalate to an App Review Board review, which takes longer (3–7 days) but gives you a chance to argue the case with a senior reviewer. In extreme cases repeated policy violations can result in account suspension; this is rare but documented. Always engage productively via Resolution Center instead of resubmitting without changes.
Are rejection rates higher for indie developers than big apps?
Apple's 2024 App Review transparency reports do not segment by developer size, but indie developers disproportionately get flagged on 4.3 (spam, when many small apps share a template), 5.1.1 (privacy, when SDK lists get out of sync with the policy), and 2.3.3 (screenshot accuracy). Enterprises have dedicated compliance teams that catch these pre-submission; indies get caught more often.