About a quarter of all App Store submissions get rejected, and indie first-timers cluster into the same dozen guideline numbers every week. The good news: a reviewer spends roughly five minutes in your build, and almost everything that gets you rejected is visible to you before you ever hit Submit. This is the pre-flight checklist, organized by the exact rule the reviewer will cite.
TL;DR
- Apple processes about 90% of submissions within 48 hours (average ~1.5 days, as of June 2026), so a rejection-and-resubmit cycle usually costs you 2–3 days, not weeks. Avoiding the first rejection is the whole game.
- The repeat offenders for indie apps are 2.1 (broken/placeholder build), 2.3.x (screenshots and description don’t match the app), 3.1.1 (digital goods bypassing IAP), 4.2 (thin WebView wrapper), 5.1.1 (incomplete App Privacy form), and a missing or broken demo account.
- Most of these are self-inspectable. Walk the nine checks below on a freshly reinstalled build, the morning you submit.
| Guideline | What it covers | Most common indie trigger |
|---|---|---|
| 2.1 | App Completeness | Placeholder text, dead buttons, crash on cold launch |
| 2.3.3 | Accurate screenshots | Mockups / design renders instead of real build screens |
| 3.1.1 | In-App Purchase | ”Upgrade” opens Safari to Stripe |
| 4.2 | Minimum Functionality | Single-page WebView with no native features |
| 4.3 | Spam / duplicates | Same code reskinned and submitted N times |
| 5.1.1 | Data Collection disclosure | App Privacy form left incomplete; no privacy policy URL |
| 5.1.5 | Location | Vague Info.plist purpose string |
| — | Demo account | Missing, disabled, or untested credentials |
Why App Review is more predictable than it looks
App Review feels like a black box, but it isn’t. Apple publishes the full App Review Guidelines, reviewers cite a specific rule number when they reject, and the same handful of rules trip up indie developers over and over. The team processes more than 200,000 submissions a week, so reviewers move fast and lean on pattern-matching — which is exactly why a clean, self-checked build sails through and a sloppy one gets bounced on a single line.
The categories below cover the large majority of indie first-submission rejections in 2026. Knowing which rules to check before you submit is the difference between approval on day one and three round-trips through the Resolution Center.
Before you start
- You are preparing a first submission, or you were rejected once and want to fix everything before resubmitting.
- You have a working build and a draft listing in App Store Connect.
- You have read (or can read) the App Review Guidelines — they are not long.
- You have time to fix issues before submitting, not after.
The nine checks
Each item carries: rule number + how the reviewer will reject + what to check / fix before submit. Walk through all nine 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. Apple counts crashes and broken flows as the single biggest 2.1 bucket — a cold-launch crash is an instant reject.
-
Rule 2.3.3 (accurate screenshots) — must come from the current build. Metadata mismatches are one of the most common rejection categories, and roughly a fifth of successful appeals are about metadata, so it pays to get this right the first time.
- [ ] 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.9" / 6.7" / 6.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 — a generic note will be rejected.
-
Rule 4.2 (minimum functionality) — pure WebView shells get rejected. Apple’s own wording: if your app “is not particularly useful, unique, or ‘app-like,’ it doesn’t belong on the App Store.” A single-page
WKWebViewwith no native UI is the textbook 4.2 reject.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. Native bottom-tab navigation plus push notifications is usually enough to clear the “app-like” bar.
-
Rule 4.3 (spam / duplicate apps) — don’t ship reskinned clones. Apple explicitly asks developers to combine near-identical apps into one; submitting several near-duplicates ties up review and risks all of them.
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 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 on the App Information page — Apple requires one even if you “only store data locally.” Reviewers also check that a privacy policy link and an account-deletion path are reachable from inside the app. Minimum 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 name (a) the specific scenario and (b) the specific benefit. “Improves your experience” gets rejected almost every time.
-
Sign-in demo account — top-tier rejection. Never skip. If your app has any login screen, Apple requires working demo credentials (or a fully-featured demo mode) in the App Review Information section.
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: the morning you submit, log in with these exact credentials from a clean (or wiped) device, on at least two network environments. A disabled or typo’d account is a guaranteed round-trip.
-
Pre-populate demo content. The reviewer spends about five minutes in your app and will not seed data for you. Empty states read as “incomplete.”
- Notes apps: review account already has 5 sample notes
- Social apps: review account has 3 followers + 2 group memberships + 5 messages of history
- Tools: example projects / templates pre-created
- Content apps: home feed visibly populated (no empty state)
In review notes: write “log in as review@yourdomain.com to see samples X / Y / Z,” and attach one screenshot of the post-login home screen. Apple explicitly says generic review notes are rejected — be specific about what the reviewer should do and see.
Common pitfalls
- Treating the App Review Guidelines as “the thing I’ll read if I get rejected.” Read them once, front to back, before your first submission.
- Providing a demo account that doesn’t work or has been disabled. Test it from a logged-out browser on a fresh device the day of submission.
- Hiding features behind a paywall the reviewer cannot bypass. Either provide a review-only path, or expect a 2.1 rejection.
- Running your own subscription system in parallel with IAP. Even if it works, it’s a 3.1.1 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.
FAQ
- If I get rejected, can I appeal?: Yes — through the Resolution Center or the App Review Board. Appeals work best when the rejection looks like a misinterpretation rather than a clear rule break; in practice roughly one in five appeals is reversed, mostly on metadata calls. Reply in the Resolution Center with specifics before escalating.
- How long does review take in 2026?: Apple reports it processes about 90% of submissions within 48 hours, with an average around 1.5 days. So a rejection plus a clean resubmit typically costs you 2–3 days, not weeks.
- 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 Apple cited.
- Is there a way to get expedited review?: Yes — request expedited review through App Store Connect for genuine emergencies (crashing builds, critical bug fixes). Approval isn’t guaranteed and Apple notices abuse, so save it for real fires.
- What if reviewers seem inconsistent?: They sometimes are — different reviewers, different interpretations. If a previous version was approved, cite that approval in your Resolution Center reply.