Most App Store rejections fall into about a dozen categories. If you check every one of them before you submit, you can usually pass on the first try. Here is the list, with the actual rule numbers and what to do.
Background
App Review feels mysterious, but it is not. Apple publishes the App Review Guidelines, reviewers cite specific rule numbers when they reject, and the same rules trip up indie devs over and over. Knowing which rules to check before you submit cuts review cycles dramatically. The most common rejection categories below cover roughly 80% of indie rejections in 2026.
How to tell
- You are preparing your first submission, or you have been rejected once and want to fix everything before resubmitting.
- You have at least a working build and a draft listing in App Store Connect.
- You can read the App Review Guidelines (they are not long).
- You have time to fix issues before submitting, not after.
Step by step
Each item carries: rule number + how the reviewer will reject + what to check / fix before submit. Walk through all 9 before hitting “Submit for Review”.
-
Rule 2.1 (App Completeness) — no placeholders, no half-built features. The reviewer will click every button and every tab.
Pre-submit check:
- [ ] Full-text search for "TODO" / "Lorem ipsum" / "Coming soon" — clear or hide the entries - [ ] Search for "test@example.com" / "12345" placeholder data - [ ] Cold-launch run: delete app → reinstall → walk every tab and button. No crash, no white screen, no "feature in development" - [ ] Every feature mentioned in App Store Connect → App Description must be reachable in the buildFix: hide the “Coming soon” button entirely (not disabled, not gray) until the next version.
-
Rule 2.3.3 (accurate screenshots) — must come from the current build.
- [ ] Run the actual submitted build, screenshot the real UI - [ ] Forbidden: PSD-composited mockups, design renders, competitor screenshots - [ ] In-screenshot content (usernames, items, messages) must be real app data, not "Apple Sample Content" - [ ] iPhone 6.7" / 6.5" / 5.5" sizes — capture on real device or simulator, never upscaleAutomate with Fastlane snapshot:
gem install fastlane fastlane snapshot init # Write SnapfileUITests/SnapshotHelper.swift, then: fastlane snapshot -
Rule 3.1.1 (IAP required) — digital goods must use Apple IAP. No external web checkout.
Auto-reject patterns:
- "Unlock Pro" opens Safari to Stripe Checkout → instant reject - "Upgrade" button links to your website → instant reject - Any "buy on our website" prompt → instant rejectLegitimate “Reader” exceptions (rule 3.1.3): physical e-commerce, ride-hailing, food delivery, medical appointments, qualifying online learning. If you fall into an exception, state the category explicitly in the App Store Connect review notes.
-
Rule 4.2 (minimum functionality) — pure WebView shells get rejected.
Pre-submit check:
- [ ] At least 2-3 native screens (not WKWebView wrappers)? - [ ] At least 1 iOS-only capability used (Push / HealthKit / Camera / Core Location / Widgets)? - [ ] At least one "only works because you installed the app" feature (offline, push, biometrics)? - [ ] Could you do exactly the same on the website without the app? If yes → danger.Cheapest fixes: add Widgets, Lock Screen Live Activities, or a Share Extension.
-
Rule 4.3 (spam / duplicate apps) — don’t ship reskinned clones.
Auto-reject patterns:
- Same codebase reskinned, submitted as 10 niche apps → 4.3 reject - Template-generated apps, only the brand differs → 4.3 reject - White-label bulk submissions → 4.3 + 5.2 double rejectDetails: App Store rule 4.3(b).
-
Rule 5.1.1 (data collection disclosure) — App Privacy form must be complete.
App Store Connect → App Privacy → “Edit”:
Walk all 32 Apple data categories (Contact Info / Health / Financial Info / Identifiers / Usage Data / ...): - [ ] Each marked Collected / Not Collected - [ ] If Collected, mark Linked to User / Not Linked - [ ] Purpose (Analytics / App Functionality / Personalization / Advertising / ...) - [ ] Third-party SDKs (Firebase Analytics, Crashlytics, Adjust, AppsFlyer, Sentry, etc.) count as "you collect" — must be declaredAdd the Privacy Policy URL (App Information page). Minimum 7 sections: see App privacy policy checklist.
-
Rule 5.1.5 (location) — must actually use location + describe purpose in Info.plist.
Required
Info.plistkeys (missing = compile error; vague = rejection):<key>NSLocationWhenInUseUsageDescription</key> <string>Used to show coffee shops within 5 km of you, only when you open the search</string> <key>NSLocationAlwaysAndWhenInUseUsageDescription</key> <string>Only when you enable "Live commute reminders" — used to notify you 10 minutes before you should leave</string>Rule: every permission string must include (a) the specific scenario (b) the specific benefit. “Improves your experience” gets rejected 100% of the time.
-
Sign-in demo account — top-5 rejection. Never skip.
App Store Connect → App Review → Sign-In Information:
Username: review@yourdomain.com Password: AppleReview2026! Notes: - Account pre-populated with sample data: 3 projects, 5 messages, order history - Primary features accessible without paywall - Payment flow testable via sandbox account, already signed in - If reviewer hits a blocker, contact dev@yourdomain.com — replies within 24hVerify: before submit, use a clean (or wiped) device + this account + try on at least two network environments.
-
Pre-populate demo content: the reviewer spends ~5 minutes; they will not seed data for you.
- Notes apps: review account already has 5 sample notes
- Social apps: review account has 3 followers + 2 group memberships + 5 message history
- Tools: example projects / templates pre-created
- Content apps: home feed visibly populated (no empty state)
In review notes: state “log in as review@yourdomain.com to see samples X / Y / Z”, and attach 1 screenshot of the post-login home screen.
Common pitfalls
- Treating App Review Guidelines as “guidelines I will look at if rejected.” Read them once front to back before your first submission.
- Providing a demo account that does not work, or that has been disabled. Test it from a logged-out browser on a fresh device.
- Hiding features behind a paywall the reviewer cannot bypass. Either provide a review-only path, or expect a 2.1 rejection.
- Implementing your own subscription system in parallel with IAP. Even if it works, this is a rejection waiting to happen.
- Using the words “beta,” “test,” “trial,” or “preview” in your app name or description — these trigger rejection under 2.2.
- Misclassifying your app category to game search rankings. Apple’s reviewers do recategorize and sometimes reject.
Who this is for
Indie developers preparing a first submission, or anyone who has been rejected and wants a systematic re-check before resubmit.
When to skip this
Apps that have already passed review and are only iterating on existing features — focus on Update guidelines instead.
FAQ
- If I get rejected, can I appeal?: Yes, through the Resolution Center or App Review Board. Appeals work best when the rejection feels like a misinterpretation, not when you clearly broke a rule.
- Do rejections affect future submissions?: Not directly, but repeated similar rejections on the same app can flag it for stricter review. Fix the root cause, not just the symptom.
- Is there a way to get expedited review?: Yes — request expedited review through App Store Connect for genuine emergencies (crashes, critical bug fixes). Do not abuse it; Apple notices.
- What if reviewers seem inconsistent?: They are sometimes inconsistent — different reviewers, different interpretations. If you were approved before, cite the previous approval in your appeal.