The App Store review queue doesn't care that you spent six weeks polishing your app. It cares whether your privacy nutrition label matches your code, whether your demo account actually logs in, and whether your subscription terms show up where Apple's reviewers expect to find them. Miss any of those, and a review that should take 24-48 hours turns into a resubmission loop that eats a week or more.
Here's the part that stings: most rejections aren't about app quality. Your app can be fast, well-designed, and bug-free, and still get bounced because a screenshot shows a UI state that doesn't exist anymore, or your IAP restore button is missing, or you forgot to explain why you need camera access in the permission string. These are process gaps, not product problems — and process gaps are fixable before you ever hit submit.
That's the point of this checklist. It's built around the five areas where indie developers actually lose review cycles: metadata that doesn't match the binary, privacy disclosures that don't match your SDKs, in-app purchase configuration that's incomplete at submission time, screenshots that misrepresent the current build, and core functionality that breaks for a reviewer who doesn't have your test data.
None of this is exotic. Every item below maps to a specific App Review Guideline section, because "make it better" isn't actionable and "Guideline 2.3.1 — screenshot doesn't match app behavior" is. If you've been rejected before, you'll recognize some of these. If this is your first submission, this checklist is what stands between you and finding out the hard way.
Why Most App Store Rejections Are Avoidable
App Review isn't one person quietly opening your build. It's a mix of automated triage — binary scanning, metadata checks, privacy manifest validation — and a human reviewer who spends a few minutes actually using your app. Apple's own numbers put median review time around 24-48 hours for most submissions, but that clock only matters if you pass on the first attempt. Every rejection resets it, and a resubmission cycle typically adds 1-3 days minimum, more if the fix requires a build change and another wait in the queue.
The rejections aren't random. They cluster hard around a handful of guideline sections: 2.1 (App Completeness — crashes, placeholder content, broken flows), 2.3 (Accurate Metadata — screenshots and descriptions that don't match the actual app), 5.1 (Privacy — data collection disclosures, permission strings, account deletion requirements), and 3.1 (Payments — IAP configuration, restore purchases, subscription terms). If you've shipped more than one app, you've probably been rejected under at least one of these.
What App Review Actually Checks
Reviewers work from a checklist too, just Apple's internal version of one. They install your build, click through your core user flow with a test account, check that permission prompts explain themselves, and cross-reference your listed data collection against what the app actually does. Automated tooling catches the objective stuff — missing Info.plist keys, privacy manifest gaps, encryption export compliance. The human catches the subjective stuff: does this app do what the screenshots say it does.
The Cost of a Resubmission Cycle
A rejection doesn't just cost the 1-3 days for re-review. It costs the time to reproduce the reviewer's exact scenario, patch the issue, regenerate a build, and wait in queue again — often 3-5 days end to end for something that a five-minute check would have caught pre-submission. That's the entire case for running a systematic preflight pass before you hit submit, which is what SubmitPreflight is built around: catching the 2.1, 2.3, 5.1, and 3.1 failure points while you still control the timeline.
Metadata and App Store Listing Checklist
Most metadata rejections come down to a handful of fields Apple checks in the first ten minutes of review. Run through this before you hit submit.
App Name, Subtitle, and Keywords
- App name: 30 characters max. Don't stuff keywords into it — Apple flags names that read as keyword spam under Guideline 2.3.7.
- Subtitle: 30 characters max, shown directly under your app name in search results. This is prime real estate reviewers also read for accuracy — if it promises a feature the app doesn't have, that's a 2.3.1 flag before anyone even opens the binary.
- Keyword field: 100 characters total, comma-separated, no spaces needed after commas (they waste characters). Don't repeat words already in your app name or subtitle — App Store Connect indexes those separately, so duplicating them is wasted space, not extra weight.
- Don't include competitor app names or trademarked terms in keywords. This is a common reason for a quiet keyword-field rejection that doesn't even show up as a binary rejection.
Description Accuracy Under Guideline 2.3.1
Guideline 2.3.1 exists because reviewers test what your description claims, not what your code does. Every feature you describe has to be reachable in the build you submitted.
- If your description mentions a feature gated behind a subscription, say so — don't let the reviewer discover a paywall you didn't disclose.
- Remove references to platforms, integrations, or features that shipped in a previous version but were cut from this one. Stale descriptions are the single most common 2.3.1 trigger we see in rejection reports.
- Support URL and marketing URL must resolve to a live, working page — not a placeholder, not a 404, not a bare GitHub README. Reviewers click both. Test them in a private browser window right before submission, since a broken staging redirect is invisible until you check with fresh eyes.
- Age rating must reflect actual content, including third-party ads, user-generated content, and any web view that can reach unmoderated content. An age rating that undersells mature content is a fast rejection and, if caught post-launch, a app-removal risk.
- Cross-check your screenshots against your description. If a screenshot shows a feature the text doesn't mention (or vice versa), reviewers read that as inconsistency, not marketing flourish.
Our sample report shows exactly what a full metadata pass looks like against a real submission, line by line.
Privacy Nutrition Labels and Permission Descriptions
Privacy issues are the second-biggest rejection category we see, and almost all of them trace back to one thing: what you declared doesn't match what your app actually does.
Guideline 5.1.1 and Data Collection Disclosures
Your Privacy Nutrition Label has to match your SDKs' actual behavior, not your intended behavior. Reviewers — and increasingly, automated tooling — diff your declared data types against what your binary's network calls and third-party SDKs actually collect.
- Audit every third-party SDK for what it collects by default. Analytics, crash reporting, and ad SDKs often collect device identifiers or usage data you didn't explicitly turn on. If it's in the SDK, it's your disclosure obligation, not the vendor's.
- If you use RevenueCat, Firebase, or a similar SDK for purchases or analytics, check their current data collection docs before filling out the label — a common gap is declaring "no data collected" when the SDK is quietly sending device identifiers. Our Revenuecat missing metadata breakdown covers the exact fields reviewers check against this SDK.
- Under Guideline 5.1.1(v), any account creation flow needs a matching in-app account deletion path — not just a "contact support to delete" email link. If you're on Expo/React Native, our App Store account deletion for Expo page walks through a compliant flow that passes review without a custom native module.
Writing Permission Strings Reviewers Won't Flag
Generic NSUsageDescription strings get flagged because they don't explain why the app needs the permission in context — "We need your location" tells the reviewer nothing about what breaks without it.
- Write permission strings tied to the specific feature: "Your location is used to show nearby stores in the map view," not "We need your location to improve your experience."
- Every permission string should be verifiable in the build. If your camera permission string mentions scanning receipts, the reviewer needs to be able to find that flow within a couple of taps.
- Expo apps generate permission strings from
app.jsonconfig plugins, and the defaults are often too generic to survive review — see our Expo App Store permission description guide for wording that maps directly toNSCameraUsageDescription,NSLocationWhenInUseUsageDescription, and the other common flagged strings. - Don't request a permission your app doesn't use yet. Unused permission entries are one of the easiest things for a reviewer to catch and one of the easiest things for you to remove before submission.
In-App Purchase and Subscription Configuration
Guideline 3.1.1 Payment Requirements
Guideline 3.1.1 is where IAP submissions die. Every in-app purchase product — consumable, non-consumable, auto-renewable subscription — must be created in App Store Connect, filled out completely, and attached to the build you're submitting. A product that exists but isn't attached to the current build version is invisible to the reviewer. They'll try to buy it, hit nothing, and reject.
Subscription terms have to be visible before the purchase sheet appears, not buried after checkout. That means price, duration, and auto-renewal terms shown on the paywall screen itself, not just in the system purchase confirmation. Apple checks for this explicitly — it's not optional disclosure, it's a rejection trigger if missing.
Restore purchases needs its own button, needs to actually work, and needs to work without requiring the user to re-enter credentials Apple already has. Reviewers test restore on a fresh install with an already-purchased account. If it silently fails or the button doesn't exist, that's an automatic rejection regardless of how good the rest of your app is.
Common RevenueCat and StoreKit Metadata Gaps
If you're using RevenueCat (most indie apps building subscriptions are), the most common failure mode isn't a broken paywall — it's "unable to test in-app purchase" because the offering RevenueCat serves doesn't match a product that's actually configured and approved in App Store Connect. RevenueCat can only surface what StoreKit gives it. If a product is missing localization, missing a price tier, or stuck in "Missing Metadata" status in ASC, RevenueCat will either fail silently or serve nothing, and the reviewer sees a blank paywall.
We've written up this exact failure mode in detail, including the ASC fields reviewers check first, at RevenueCat missing metadata on App Store. Before you submit, walk every product in your RevenueCat dashboard against its counterpart in ASC — status, price, localized display name, and localized description all have to be present, not just the SKU.
Screenshots, App Previews, and Visual Assets
Required Sizes and Device Coverage
Apple requires screenshots sized for each display class you support — 6.9" and 6.5" iPhone, plus 13" iPad if your app runs on iPad. Skip a required size and App Store Connect blocks submission outright before a human reviewer ever sees your build. If your app is iPhone-only, mark it explicitly in ASC so iPad sizes aren't requested; leaving it ambiguous is a common source of last-minute upload failures the night before a deadline.
What Reviewers Flag in Screenshots
Placeholder content is an instant flag. Lorem ipsum text, default Xcode asset icons, or obviously fake data in a screenshot tells the reviewer you rushed the listing, and it invites closer scrutiny of everything else. Reviewers assume a sloppy screenshot means a sloppy app.
Stale screenshots are just as common and just as damaging. If your UI shipped a redesign three versions ago and your screenshots still show the old nav bar or an old onboarding flow, that's a mismatch between what's advertised and what's built — the review team will open the build to check, and now you've spent review-cycle goodwill on a fixable asset problem instead of real functionality.
Guideline 2.3.3 covers the sharpest version of this: any claim or feature shown in your screenshots or App Preview video has to actually exist in the submitted build. A screenshot showing "AI-powered insights" or a premium feature that's stubbed out, gated behind a waitlist, or simply not implemented yet is a metadata-accuracy rejection, not a bug report — and it's one of the faster ones to trigger since it doesn't even require deep testing, just a side-by-side comparison. Regenerate screenshots every time your UI changes meaningfully, and never show a feature you haven't shipped. For a sense of what a clean, fully-matched submission package looks like end to end, see the sample report.
Testing Your Build Before You Hit Submit
A build that works in Simulator can still crash on a physical device. Different memory pressure, real camera and sensor hardware, and actual network conditions expose bugs Simulator never triggers. Test on at least one physical device before you submit — ideally the oldest iOS version your app still supports, since that's where low-memory crashes and deprecated API calls tend to surface first.
Missing or broken demo credentials in your App Review notes are one of the most common triggers for a Guideline 2.1 rejection. The reviewer can't guess a login. If your app requires an account, provide a working test username and password in the review notes every time you submit — not just on the first submission. Credentials expire, test accounts get deleted, and reviewers hit dead ends more often than developers expect.
If your app depends on a backend — your own API, a third-party service, or a staging environment — that backend must be live and reachable when Apple reviews the build, not just when you tested it. A backend that's asleep, rate-limited, or pointed at a dev environment reads as a broken app to the reviewer, even though your code is fine. Confirm your production endpoints are up and your app isn't quietly still pointed at localhost or a staging URL.
TestFlight as a Pre-Submission Gate
Run every build through TestFlight before submitting to App Review. TestFlight installs the same compiled binary reviewers will see, so it catches crash-on-launch bugs, missing entitlements, and provisioning issues before they cost you a review cycle. Install the TestFlight build on a real device covering your minimum supported OS version, not just your latest one — a crash on an older OS is invisible if you only test on this year's iPhone.
Providing Reviewer Access and Demo Accounts
In App Store Connect, use the App Review Information section to give reviewers exactly what they need: a demo account, any required PIN or verification code, and plain-language notes on non-obvious flows (paywalls, invite-only features, server-side toggles). If your app uses RevenueCat or another subscription backend, note which entitlements the demo account has active — a reviewer who can't reach paid content will assume it's broken.
Common Rejection Reasons and How to Avoid Them
Beyond metadata and privacy issues, a handful of recurring problems account for a large share of rejections. Each has a quick, specific fix.
Guideline 4.3 Spam and Minimum Functionality
Apps that look like a rebranded template, a thin wrapper around a single WebView, or a near-duplicate of another app on your account get flagged under Guideline 4.3 (spam) or 4.2 (minimum functionality). Fix: ship something with a distinct core feature, real content, and enough native functionality that it reads as a standalone product — not a reskin.
Incomplete account deletion flows are a frequent rejection since Apple made in-app deletion mandatory. If your app lets users create an account, it must let them delete it from within the app — a "contact support to delete" link isn't sufficient. Fix: implement in-app, self-service deletion that actually removes the account (see our Expo account deletion guide if you're on that stack).
Mismatched age ratings — a rating that doesn't reflect actual content, like user-generated content or web browsing marked as 4+ — get bounced. Fix: answer the App Store Connect age rating questionnaire based on what the app actually does, not what you hope the rating will be.
Permission requests without a clear in-app justification (camera, location, contacts) get rejected because reviewers can't tell why the app needs them. Fix: write a specific, honest usage description string for each permission, tied to a feature the reviewer can actually find (our Expo permission description guide covers common wording that passes).
Broken Links and Placeholder Content
A dead support URL, marketing link, or privacy policy link in your metadata is an easy rejection — reviewers click these. Fix: test every URL in App Store Connect before submitting. Placeholder text, lorem ipsum, or "coming soon" screens anywhere in the app read as an unfinished submission. Fix: replace all placeholder content with final copy, or remove the screen entirely until it's ready. Want to see what a full pre-submission pass looks like before you rely on your own read-through? Check the sample report.
Run Your Own Preflight Check Before You Submit
The best time to catch a rejection risk is 24 hours before you submit, not 24 hours after Apple emails you back. Once your build is uploaded and your metadata is locked in, treat it like a pre-flight checklist a pilot runs before takeoff: work through metadata, privacy labels, IAP configuration, screenshots, and build stability in one pass, on a clean copy of what you're about to submit — not what you remember submitting last time.
A structured audit looks different from a mental once-over. You're not skimming for typos; you're checking each item against a specific Apple guideline, the same way a reviewer will. Permission strings match actual usage. Subscription metadata is complete in App Store Connect, not just configured in RevenueCat. Screenshots reflect the current build, not last quarter's UI. Account deletion is reachable without contacting support. Each of these has sunk a submission before, and each takes seconds to check when you know exactly where to look.
If you want to see what that output actually looks like before you commit to the process, the Sample Report shows a full audit against a real app — flagged items, guideline references, and the fix for each one, not just a pass/fail score.
Doing this manually every release works until you're shipping updates weekly and the checklist starts getting skipped under deadline pressure. That's what the App Store Preflight Kit is for: a Markdown-first skill pack you run against your app before every submission, so the checks above happen automatically instead of from memory. Check out SubmitPreflight to get the kit and stop finding out about metadata gaps from a rejection email.
FAQ section for the App Store submission checklist article.
Frequently asked questions
How long does App Store review actually take?
Most builds clear review in 24–48 hours, per Apple's own published median. Budget for 1–3 days end to end, and don't submit day-of if you have a launch deadline — build in slack for at least one rejection-and-resubmit cycle. Review times spike around major iOS releases (WWDC week, September launches) when submission volume is high. If you're past 48 hours with no movement, check App Store Connect for a status change before contacting Apple — most "stuck" reviews are just in a normal queue, not flagged.
What's the single most common reason apps get rejected?
Guideline 2.1, Performance — App Completeness. This covers crashes, broken links, placeholder content, and features that don't work as described, and it consistently tops Apple's rejection data. In practice this means: test your build on a clean device (not just simulator), remove TestFlight-only debug menus, and verify every button and link actually does something before you submit. Second most common: incomplete metadata, like a support URL that 404s or screenshots that don't match the current build.
Do I need to provide a demo account for App Review?
Yes, if your app has a login wall. Guideline 2.1 requires reviewers to access all app functionality, and a broken or missing demo account is one of the fastest ways to get bounced back regardless of how solid your code is. Add credentials in the App Review Information field in App Store Connect, not buried in your description. If your login uses 2FA or magic links, either disable it for the review account or provide a way around it — reviewers won't chase a code sent to an email they can't access.
How do privacy nutrition labels affect approval odds?
A mismatch between your declared privacy labels and your app's actual data collection is a Guideline 5.1.1 violation, and reviewers do check this — especially for apps using ad SDKs, analytics, or third-party auth. Audit every SDK in your build for what it actually collects, not just what you intended to add. If your app uses IDFA, App Tracking Transparency also needs a live prompt, not just a label entry. Getting this wrong doesn't just risk rejection — it risks account-level strikes if it looks intentional.
Can I fix a rejection and resubmit the same day?
Usually yes. Most rejections are metadata or minor functional issues you can patch fast, and resubmitted builds typically re-enter the standard review queue rather than starting over from scratch. Use the Resolution Center to reply directly to the reviewer if the rejection reason is unclear — sometimes a clarifying message avoids a full rebuild. For binary-level fixes (crashes, missing functionality), you'll need a new build number, which resets TestFlight beta review too if you're running both in parallel.