App Store Rejection Recovery Guide (2026)

Every indie dev has been rejected. Most have been rejected multiple times. The good news: rejection isn't usually fatal — almost all rejections are recoverable in 1-3 review cycles if you respond correctly.

This is the working playbook for what to do when you open App Store Connect or Play Console and see "Rejected."

The first 30 minutes

1. Read the full rejection. Don't skim. Apple's reasons are specific; Google's are usually broader.
2. Identify the guideline reference. Apple cites a specific section ("Guideline 4.3 — Design — Spam"). Google references policy categories.
3. Don't reply yet. Resist the urge to defend immediately. Take 30 minutes.
4. Read the guideline yourself. Most rejections become clear once you read the cited rule.

The 10 most common rejections (2026)

1. Guideline 5.1 — Privacy (Apple) / Privacy Policy Issues (Google)

Most common rejection. Causes:

• Missing privacy policy URL.
• Privacy nutrition labels (Apple) don't match actual app behavior.
• Collecting data not disclosed.
• Third-party SDK collecting data you didn't declare.

Fix:

• Audit every SDK in your app and what it collects.
• Update privacy nutrition labels to match reality.
• Update privacy policy with specific data types.

2. Guideline 4.3 — Spam / Duplicate (Apple)

Causes:

• Your app looks too similar to others you (or others) have published.
• Reskinned template app.
• Generic content with thin differentiation.

Fix:

• Differentiate strongly. New screenshots, unique copy, distinct features.
• If it's truly a derivative, explain why this version is uniquely valuable in the review notes.

3. Guideline 3.1.1 — In-App Purchase (Apple) / Payments Outside Play (Google)

Causes:

• Using web payments instead of IAP for digital goods.
• Linking to external payment methods.
• "Cancel anytime" pages routing to web.

Fix:

• Move digital-good purchases inside IAP.
• Remove external payment links.
• If you have a legitimate reader-app exception, document it.

4. Guideline 2.3 — Accurate Metadata

Causes:

• Screenshots don't match what the app does.
• Description claims features that don't exist.
• Keywords field has competitor names.
• Title or subtitle has spammy claims.

Fix:

• Update screenshots to reflect actual app.
• Strip competitor brand names from keywords.
• Soften hyperbolic language ("the best", "guaranteed").

5. Guideline 2.1 — App Completeness

Causes:

• Demo account doesn't work or credentials wrong.
• Required feature crashes.
• "Coming soon" placeholders in production.

Fix:

• Test the demo credentials yourself before resubmission.
• Add a screen recording in review notes if onboarding is unusual.

6. Guideline 4.0 — Design

Causes:

• App doesn't look like an iOS / Android app.
• Web-view-only apps without native features.
• Severely outdated design patterns.

Fix:

• Add native UI elements.
• Address platform conventions (Material Design / Human Interface Guidelines).

7. Health / Medical Claims (both stores)

Causes:

• Unsubstantiated claims about diseases.
• Medical-grade language without certification.
• Mental health claims without disclaimers.

Fix:

• Hedge every claim: "Track" not "Treat", "Monitor" not "Diagnose."
• Add "not medical advice" disclaimers.

8. Subscription / Pricing Issues

Causes:

• Subscription terms not clearly disclosed before purchase.
• Trial → paid conversion not clearly stated.
• Refund policy missing.

Fix:

• Add clear disclosure: "$X.XX/month, cancel anytime, auto-renews unless turned off 24 hours before period end."
• Show price clearly before purchase action.

9. Restricted / Regulated Content (gambling, crypto, finance)

Causes:

• Crypto/financial features without proper regional licensing.
• Gambling without correct ratings.
• Wallet apps without disclosure of risks.

Fix:

• Region-restrict to where you have licensing.
• Add risk disclaimers.
• For crypto/wallet: be very specific in metadata.

10. Generative AI / Sensitive Content

New in 2024-2026:

• AI image generators without safety filters.
• Chatbot apps without abuse-prevention.
• AI tools that can produce inappropriate output.

Fix:

• Show your moderation pipeline in review notes.
• Add age-gating where appropriate.
• Demonstrate input/output filtering.

How to respond

Three rules:

Rule 1: Match the rejection's specificity

If Apple cites a specific screenshot, your response addresses that specific screenshot. Don't paraphrase the rejection and address something vaguer.

Rule 2: Show, don't tell

If you've fixed something, include evidence:

• Screenshot of the change.
• Screen recording of the fixed flow.
• Direct URL to the new privacy policy.

Rule 3: Be polite. Always.

Reviewers are humans. Tone matters. Even if the rejection feels wrong, polite responses get faster turnarounds.

When to escalate

Escalation paths:

Apple

1. Reply through Resolution Center with the fix or argument.
2. If still rejected after 2-3 cycles → request a call with Apple Review. Available through Resolution Center.
3. Last resort → Appeals process (formal). Long timeline, but real.

Google

1. Appeal through Play Console.
2. If first appeal fails → request human review via the developer help center.
3. For complex cases → reach out to your Account Manager (if you have one) or post in the Play Console Help community.

Prevention: pre-submission audit

Before submission, walk through:

• Privacy policy URL is reachable and matches data practices.
• Privacy nutrition labels (iOS) reflect every SDK.
• Demo account credentials work (test yourself).
• Screenshots match current app (not from 6 months ago).
• No competitor brand names in keywords / metadata.
• No "coming soon" placeholders.
• Subscription terms clearly disclosed.
• Medical / health claims are hedged.
• If regulated category (finance, crypto, gambling, health): region-restricted appropriately.
• Review notes explain anything non-obvious about the app.

Run a free ASO audit before submission — it'll flag claim language and listing issues that often correlate with rejections.

What to do if you can't get unstuck

Some apps get stuck in rejection loops despite reasonable fixes. Options:

1. Phone call with App Review. Available, underused. Often resolves in one call.
2. Apple Developer Relations. If you have a partner manager, escalate.
3. Re-architect the contested feature. Sometimes the cheapest path.
4. Withdraw and resubmit fresh. Sometimes clears a reviewer-specific block.

Common mistakes during rejection

• Replying defensively. Tone tanks the response.
• Resubmitting without fixing. Auto-rejection.
• Ignoring the cited guideline. They cited it for a reason.
• Multiple submissions during a review. Restarts the queue.
• Updating other metadata simultaneously. Confuses what was reviewed.
• Panicking. Rejection is normal. Almost all are recoverable.

Related reading

• The Indie ASO Audit Checklist 2026
• The Complete ASO Guide for Indie Developers
• Mobile App Soft Launch Playbook
• Best Free ASO Tools in 2026

Try the tools

• Free ASO audit — flags listing issues before submission.
• Listing Analyzer