Mobile app store rejection checklist (iOS + Android, 2026)

Apple rejects somewhere between 30 and 40% of first submissions. Google Play rejects fewer (~20%) but their rejections are slower to resolve because Play Console reviewers don't engage in dialog the way Apple's do. The good news: 90% of rejections fall into a small number of well-known categories. If you check this list before submission you cut your rejection probability roughly in half. The other 10% — review interpretation drift, regional differences, individual reviewer judgment — is irreducible and you just have to handle it gracefully.

We've shipped a lot of customer apps through both stores. This is the field manual.

Apple App Store — the top eight rejection reasons we see

Ranked by how often we hit each one in production.

1. Guideline 5.1.1 — privacy data without consent

By far the most common. The rejection text is some variant of "your app collects user data without obtaining consent." Concrete causes:

• Missing NSPhotoLibraryUsageDescription / NSCameraUsageDescription / NSLocationWhenInUseUsageDescription strings, or strings that say "we need this" without explaining why
• Tracking permission (NSUserTrackingUsageDescription) missing when you actually do track (Facebook SDK, AppsFlyer, etc.)
• Privacy nutrition label inconsistent with what the SDKs you bundle actually collect

Fix: be specific. "We use the camera so you can attach a photo to a support ticket" is fine. "Camera access required" is not.

2. Guideline 4.2 — minimum functionality

The "your app is a glorified website" rejection. Apple wants something that justifies being a native app. Typical triggers:

• App is mostly a web view of your marketing site
• App is just a contact form
• App is a single-feature utility that's not differentiated

Fix: ensure the app has at least one feature that materially benefits from being native — push notifications, offline mode, camera access, biometric auth, deep system integration. A "delivers a notification" app already clears this bar; a "shows our marketing pages" app doesn't.

3. Guideline 3.1.1 — IAP for digital goods

If you sell digital content or subscriptions accessible inside the app, you must use Apple's In-App Purchase. You cannot link to your website to subscribe and access the content in-app. Concrete fail patterns:

• "Sign up at our website" button that leads to a Stripe checkout
• A "subscription" plan that you fulfill outside IAP
• A "buy credits" flow that opens the browser

Fix: either ship IAP for in-app digital purchases or remove the in-app purchase surface entirely (Reader app exemption applies in some cases — check Guideline 3.1.3(a)).

The Stripe-as-fallback path (offering both Stripe and IAP, letting the user choose) is permitted under the 2024 settlement rulings but the UI rules are strict. Read the latest guideline carefully and don't improvise.

4. Guideline 4.0 — design quality

Vague but common. Reviewer says "the app's UI is not consistent with iOS." Typical triggers:

• Non-iOS-feeling nav patterns (hamburger menu on iOS, where tab bars are expected)
• Custom tap targets too small (below 44pt)
• Loading spinners with no progress indication for slow flows
• App crashes on first launch in airplane mode

Fix: use iOS HIG-aligned patterns. Reviewers will let you have a non-standard UI if it's clearly intentional and polished. They won't let you ship a slipshod port.

5. Guideline 2.3.10 — irrelevant content in metadata

The App Store metadata (name, subtitle, keywords, screenshots) must accurately represent the app. Triggers:

• Keywords stuffed with competitor names
• Screenshots showing features not in the app
• Promotional text claiming things the app doesn't do
• App name that's misleading

Fix: ship screenshots that match the actual app at the device sizes Apple wants. Keep keywords specific.

6. Guideline 5.1.5 — location services in background

If you use background location, Apple will scrutinize why. Acceptable: navigation app, fitness tracker, location-based reminders. Unacceptable: "we like to know where users are."

Fix: only enable always location when you have a justifiable use. Otherwise stick to whenInUse.

7. Guideline 5.4 — VPN entitlement

VPN apps need an explicit entitlement from Apple and many are rejected for unclear use cases. If you're building anything that uses Network Extension, expect extra scrutiny.

Fix: have a clear, defensible explanation of why your app needs the entitlement, and apply through Apple's process before submission.

8. Guideline 4.3 — spam / duplicate apps

Triggered for apps that look like clones, white-labels, or copies of other apps in the store. Affects template-built apps especially.

Fix: make sure your app's name, icon, and screenshots are visibly distinct. If you're building 30 clones for 30 customers, expect rejections. Apple actively de-duplicates.

Apple — the meta-rules nobody talks about

Three things that aren't "rejection reasons" per se but cause real friction:

• Reviewers vary. The same app submitted twice can get two different responses. Re-submitting after a rejection sometimes works. Not a strategy, but a fact.
• Sign in with Apple is mandatory if you offer third-party sign in. The Sign in with Apple button must be at least as prominent as the others.
• Test accounts. Apple requires functional test credentials for review. If your app gates content behind a paid sub, provide an active account in the review notes.

Google Play — the top reasons

Different system, different defaults. Top causes:

1. Policy 4.1 — health misrepresentation

The most common. If your app does anything health-adjacent (period tracker, fitness, meditation), reviewer combs the listing for unsupported claims. "Cure stress in 7 days" gets rejected. "Mindfulness exercises" doesn't.

2. Policy 4.5 — restricted content

Crypto, gambling, financial services, medical, contact tracing — all have specific requirements. Don't ship a crypto wallet without reading the Google Play crypto policy first; it changes annually.

3. Policy 8.1 — permissions justification

Like Apple, but more aggressive — Google wants the permission requested to be obviously necessary for the user-facing feature. "READ_CONTACTS" needs a clear in-app feature using it.

4. Policy 5 — privacy

Mirror of Apple's 5.1.1. Privacy policy URL must be live, must cover what the app actually collects, must include the SDKs you bundle. Privacy Sandbox compliance matters increasingly.

5. Policy 2.5 — ads

Apps with intrusive ads (full-screen on first open, hidden close buttons, click-bait) get rejected. AdMob misconfigured to show too aggressively is a common trigger.

6. Target API level

Google Play enforces a minimum targetSdkVersion. As of 2026, target SDK 34 is required for updates. Older apps can stay in the store but can't ship new versions. Update before the deadline.

The pre-submit checklist

Before you hit submit on either store:

• [ ] All permission strings are descriptive and explain why
• [ ] Privacy nutrition label (iOS) and Data Safety form (Play) match what your code actually collects
• [ ] Crash-free on first launch, in airplane mode, with no account
• [ ] Test account credentials provided in review notes
• [ ] Screenshots match the current app version (not the last one)
• [ ] App name + subtitle + description: no competitor names, no false claims
• [ ] Sign in with Apple included if any third-party sign-in exists (iOS)
• [ ] In-app purchase used for digital goods (iOS)
• [ ] Privacy policy URL works and matches the app
• [ ] No "coming soon" placeholders in the app
• [ ] Deep links functional
• [ ] Push notification permission asked at the right moment

When you get rejected anyway

Don't panic. The flow:

1. Read the rejection text twice. Apple's reviewers cite specific guidelines. Map their text to the relevant guideline.
2. Respond in Resolution Center. Polite, specific, fact-based. "We've fixed X by doing Y" works better than "we disagree."
3. If you genuinely disagree, request a call with App Review. This is a real option that not enough teams use. You can schedule a 15-minute call to walk a reviewer through your reasoning.
4. If the reviewer is wrong, escalate via Apple's App Review Board. Slow (3-7 days) but they can override individual reviewers.

For Play, the dialog is less interactive. Read the policy citation, fix the issue, resubmit, wait. If you genuinely think it's a misclassification, the App Quality Team can be contacted, but the response cycle is slow.

The cost of rejection

A rejection cycle costs ~3-7 days. Two rejections costs ~2 weeks. Apps that go through 4+ rejection cycles burn a month of momentum.

Get the first submission right.

FAQ

How long does App Store review take?

Median ~24 hours. P95 ~72 hours. Apps with complex entitlements or new categories take longer. Holiday weeks slow everything.

Can I expedite review?

Yes, for critical bug fixes. Apple grants expedited reviews liberally for genuine issues; abuse the privilege and they stop granting them.

Does TestFlight count as submission?

Internal TestFlight (your team) does not go through App Review. External TestFlight (public testers) goes through a lighter review. Production submission is the full review.

What about Play Store internal/closed testing?

Internal testing skips review. Closed testing has a lighter review. Production submission gets the full review treatment.

Can I get rejected for using React Native?

No. Both stores ship countless RN apps without issue. The "RN gets rejected" warning is from a brief 2018 era and is no longer accurate. See React Native vs native: the honest decision framework.

What if my app crashes during review?

Reviewer will reject with a crash log. Inspect the log, reproduce locally (their device is often a specific iOS version you weren't testing on), fix, resubmit.

Should I include a demo video?

Helpful for complex apps. Reviewer is faster when they understand the value prop quickly. Keep it under 30 seconds.

How do I handle a reviewer who's clearly wrong?

Be polite, cite specific guideline language, and explain why the rejection misreads your app. If still rejected, escalate to App Review Board. The escalation does work — we've had genuinely wrong rejections overturned.