The App Store Rejection Reasons That Actually Show Up in Review
App Store rejections feel random when you're staring at a form-letter email from Apple. They aren't. Apple's App Review team works from a published rulebook — the App Store Review Guidelines — and the overwhelming majority of rejections indie developers hit trace back to a small set of guideline numbers, checked the same way every time. If you know which ones, you can catch the problem before you submit instead of after.
This article walks through nine of the most common rejection triggers, each mapped to its guideline. Four families cover most of what you'll run into: 2.1 (App Completeness — crashes, broken flows, placeholder content), 5.1 (Privacy — data collection disclosure, permission strings, account deletion), 3.1 (Payments — in-app purchase implementation and metadata accuracy), and 2.3 (Accurate Metadata — screenshots, descriptions, and keywords that don't match what the app actually does). For every reason below, you'll get the fix, not just the diagnosis.
The rest of this article is written for the moment right before you hit submit — or the moment right after a rejection lands and you're trying to figure out what to actually change. If you want to see what a fully mapped pre-submission risk report looks like before we get into individual reasons, the sample report shows the format the App Store Preflight Kit produces for a real app.
The App Store Rejection Reasons That Actually Show Up in Review
Apple reviews roughly 90% of submissions within 24 hours, and most first-time rejections for indie apps cluster around a handful of predictable failure points. Here's the ranked list, from most to least common, with the guideline each one falls under so you can jump straight to what applies to you.
- Guideline 2.1 — App Completeness. Crashes on launch, broken buttons, dead links, placeholder text ("Lorem ipsum" left in a screen), or features that don't work as described. This is the single largest rejection category because reviewers only need to hit one broken path to bounce your build.
- Guideline 5.1.1 — Data Collection and Storage. Missing or vague permission request strings (
NSCameraUsageDescription,NSLocationWhenInUseUsageDescription, and similar) that don't explain why the app needs the access. This shows up constantly in Expo-based apps where the managed workflow generates a generic string instead of an app-specific one — see our breakdown of Expo App Store permission descriptions for the exact wording Apple expects. - Guideline 5.1.1(v) — Account Deletion. If your app supports account creation, it must support in-app account deletion, not just a "contact support to delete your account" workaround. This is a frequent miss for Expo/React Native apps built quickly on top of Firebase or Supabase auth — covered in detail in App Store account deletion for Expo apps.
- Guideline 3.1.1 — In-App Purchase. Broken purchase flows, restore-purchase buttons that don't work, or — increasingly common with RevenueCat integrations — App Store Connect metadata that doesn't match what's configured in your paywall. See RevenueCat missing metadata on the App Store if you're using RevenueCat and got flagged here.
- Guideline 2.3 — Accurate Metadata. Screenshots showing features that don't exist yet, descriptions that oversell functionality, or keyword stuffing in the app name/subtitle field.
- Guideline 4.2 — Minimum Functionality. Apps that are too thin — a wrapped website, a single static screen, or a feature set that doesn't justify a standalone app.
- Guideline 3.1.3 — External Purchase Links. Directing users to pay outside the app for digital content or unlocks that should go through IAP.
- Guideline 2.3.1 — Inaccurate Screenshots. A narrower cousin of #5: screenshots that show a different UI, language, or device frame than what ships.
- Guideline 5.1.2 — Data Use and Sharing. Third-party SDKs (analytics, ads, crash reporting) collecting data the app's own privacy disclosures don't account for.
Notice the pattern: five of these nine trace back to privacy and metadata accuracy, not app quality in the traditional sense. Apple isn't grading whether your app is good — it's checking whether what you submitted matches what you built and what you disclosed. That distinction is what the next sections dig into, guideline by guideline.
Guideline 2.1: Incomplete or Broken Functionality
Reviewers spend most of their time here, and it's the section where indie apps lose the most days to resubmission cycles. Apple's testers install your build on a real device, tap through your core flow, and stop being charitable the moment something breaks. If they can't get past your first screen, they reject — they don't dig for context.
Crashes and unhandled errors during review
A crash on launch is the fastest rejection in the book. It usually isn't a logic bug — it's an environment mismatch: a missing API key in the production scheme, a force-unwrapped optional that's nil in a fresh install, or a background permission prompt that fires before the view it belongs to has loaded. Before you submit, do a clean install on a physical device (not the simulator, not a device with your dev build already on it) using the exact build you're uploading. Watch the first 60 seconds closely — that's the window most crash reports point to.
Placeholder content and dead links
Reviewers treat "Lorem ipsum" text, example.com links, greyed-out unfinished features, and broken "Learn More" buttons as functionality failures, not cosmetic ones. Tap every link in your app — support URL, privacy policy, terms, any social or web links in settings — before you submit. If a feature is genuinely still in progress, hide it from the build rather than shipping a dead button; a smaller finished app clears review faster than a bigger half-finished one.
Sign-in and demo account failures
If your app requires login, App Review needs a way in. Missing or wrong demo credentials in App Review Information is one of the most common 2.1 rejections, and it's entirely self-inflicted. Create a dedicated reviewer account that won't expire, get rate-limited, or get swept up in a database reset, and double-check the credentials work the day you submit — not the day you wrote them down. If your sign-in flow depends on SMS OTP, magic links, or third-party OAuth, provide a fallback path reviewers can actually complete without a real phone number or email inbox. Test the full flow yourself, start to finish, on the build you're about to upload — not an earlier one.
Guideline 5.1: Privacy, Permissions, and Account Deletion
5.1 rejections are almost always avoidable — they come from mismatches between what your app declares and what it actually does, not from Apple objecting to the feature itself.
Permission strings that don't match actual usage
Every permission prompt needs a purpose string (NSCameraUsageDescription, NSLocationWhenInUseUsageDescription, etc.) that explains, specifically, why your app needs that access. Reviewers reject generic or copy-pasted strings — "This app needs your location" tells them nothing about what the feature does. This shows up constantly in Expo apps that ship with the framework's default permission string still in app.json, unedited. If you're on Expo, check Expo App Store Permission Description for exactly which config plugin fields map to which strings, and rewrite each one to describe the real feature.
Privacy manifest and tracking disclosures
Since Apple's privacy manifest requirement rolled out, missing or incomplete PrivacyInfo.xcprivacy files are a routine rejection trigger — especially for apps built on RevenueCat, Expo, or other SDKs that access "required reason" APIs (like UserDefaults or disk space) under the hood. Your manifest has to declare every API your app and its dependencies use, plus accurate data-collection and tracking entries that match your App Privacy nutrition label in App Store Connect. If you use RevenueCat for subscriptions, see Revenuecat Missing Metadata App Store — mismatched or absent metadata there is a frequent, easy-to-miss cause.
The account deletion requirement (5.1.1(v))
If users can create an account in your app, they must be able to delete it from inside the app — not just via a support email or a web form. This is guideline 5.1.1(v), and it's a hard requirement, not a suggestion. The account deletion flow has to actually delete the account (or clearly initiate deletion), not just log the user out or deactivate the profile. Expo apps miss this constantly because auth is often wired up fast with Supabase or Firebase and account deletion gets left for "later." If you're building on Expo, App Store Account Deletion Expo walks through implementing the flow correctly the first time.
Guideline 3.1: In-App Purchase and Subscription Problems
Guideline 3.1 rejections happen almost every review cycle, and they're almost always avoidable. Review isn't judging whether your pricing is fair — it's checking whether what you disclose in the app matches what's configured in App Store Connect, and whether users can manage a purchase without leaving your app. Miss any of the required pieces and you'll get a 3.1.2 rejection with a note about "subscription terms not clearly presented."
Missing or mismatched subscription metadata
Apple requires every subscription screen to show, before purchase: the subscription length, the price, and what the price is per (weekly, monthly, annually). This has to appear in the app itself — a link to your website's pricing page doesn't count. A common failure mode: the paywall shows "$9.99" but doesn't say whether that's monthly or annual, or the trial length shown in the UI doesn't match what's actually configured in the product. Reviewers compare your paywall copy against the actual StoreKit product metadata, and any mismatch — even a rounding difference on price — gets flagged. If you're using RevenueCat or a similar wrapper, check that the localized price and duration your app renders come from the live product object, not a hardcoded string left over from an earlier pricing test.
Restore purchases and free trial disclosure
Every app with a paid subscription needs a visible, working "Restore Purchases" button — not buried in settings three taps deep, and not silently handled on app launch. Reviewers test this explicitly: they buy, delete the app, reinstall, and tap restore. If nothing happens or the button is missing, that's an automatic rejection. Separately, if you offer a free trial, the trial length and what happens when it ends (auto-converts to paid, charges immediately unless canceled) must be stated next to the purchase button, not just in your terms of service. This is also a good moment to make sure your Terms and Privacy pages are actually reachable from the paywall, since reviewers will click through if the disclosure looks thin.
RevenueCat configuration gaps reviewers catch
RevenueCat handles the receipt validation and entitlement logic well, but it doesn't stop you from submitting a build where the underlying App Store Connect products aren't fully set up. The most common gap: a product exists in RevenueCat's dashboard and renders fine in sandbox testing, but the matching In-App Purchase in App Store Connect is still in "Waiting for Review" or "Missing Metadata" status — no localized display name, no review screenshot attached to the IAP itself. Reviewers can't approve an app tied to an incomplete IAP, so the whole submission stalls. We wrote up the exact fields Apple checks in RevenueCat's missing metadata problem — worth a read before you submit if you're on RevenueCat, since the fix takes ten minutes but the rejection costs you a full review cycle.
Guideline 2.3: Misleading Metadata, Screenshots, and Descriptions
Guideline 2.3 covers rejections that have nothing to do with your binary and everything to do with what you claimed about it. Reviewers install your build and check it against your listing — the screenshots, the description, the app name and subtitle — and any gap between what's promised and what's shipped gets flagged as misleading.
The most frequent trigger is screenshots showing features that aren't in the submitted build. Indie teams often generate App Store screenshots early, during design, then keep shipping incremental builds without updating them. If your screenshots show a dark mode toggle, social sharing, or a premium tier that got cut or delayed, reviewers will notice the mismatch during the functional pass and reject under 2.3.1 ("Inaccurate metadata"), separately from any functionality issue in the build itself. Treat screenshots as tied to a specific build, not a general marketing asset — regenerate them whenever the feature set changes, and diff them against the current binary before you submit. If you want a sense of how granular this check gets, our sample report walks through a real screenshot-to-build comparison.
The second trigger is description copy that oversells. Phrases like "works completely offline" when the app requires a network call for core features, or "no ads" when you show interstitials after a grace period, are the kind of claims reviewers test directly — they'll put the device in airplane mode or use the app long enough to hit the ad. Write the description from what the current build actually does, not the roadmap. If a feature is planned but not shipped, leave it out entirely rather than hedging with "coming soon," which reviewers still read as a present-tense claim in some contexts.
The third trigger is keyword stuffing in the app name or subtitle field — cramming in terms like "best," "free," or a string of unrelated keywords to game search ranking. Apple's guidelines cap this indirectly: an app name or subtitle that reads as a keyword list rather than a real name gets rejected under 2.3.7, and repeat offenders get their app name field locked for future edits. Keep the name to your actual product name plus one short descriptor, and put keyword variants in the dedicated keywords field where they belong — that's what it's for, and it's invisible to reviewers doing a metadata pass. For teams building on Expo, this is also where a mismatched permission description tends to surface, since permission strings are metadata reviewers check under the same pass.
Guideline 4: Spam, Minimum Functionality, and Design Copies
Guideline 4.2 doesn't get talked about as much as privacy or IAP rejections, but it catches a steady stream of indie apps. Apple's minimum functionality bar isn't about how many features you shipped — it's about whether your app does something a website or a generic template couldn't already do. A webview wrapped in a native shell, with no offline behavior, no native APIs, and no reason to exist outside Safari, gets flagged here.
The review team has seen thousands of Bubble, Adalo, Glide, and Expo-template apps by now. If your app's layout, flow, and feature set match a known template almost exactly — same tab structure, same placeholder icons, same generic onboarding — reviewers will recognize it and reject under 4.3 (Spam) or 4.2 (Minimum Functionality) even if your code is technically original. This isn't personal. It's pattern matching at scale, and template-based indie apps are the most common false-positive-prone category.
What actually reads as "real" to a reviewer: native platform integration (push notifications tied to real events, not marketing blasts), data that persists and syncs, and a core loop that isn't just CRUD over a form. If your app is a thin wrapper around a website you already run, add something the wrapper couldn't do without native code — camera access with on-device processing, offline mode, widgets, share extensions. If you can't name one thing your app does that the mobile web version of your product doesn't, that's the gap a reviewer will find too.
Multiple near-identical apps from the same developer account are a second trigger. If you're shipping a portfolio of city guides, habit trackers, or niche calculators from one account, differentiate them substantively — different data sources, different core mechanics — or expect 4.3 rejections as your catalog grows. Apple doesn't publish a hard threshold for "too similar," which makes this category frustrating to preflight against. The safest approach is asking, honestly, whether a stranger scrolling the App Store would describe your app as a copy of something else they've seen. If the honest answer is yes, that's the fix, not the appeal letter.
How to Preflight Your Build Before You Hit Submit
Most rejections in the sections above are preventable with a fixed routine, not more talent. Here's the sequence worth running every time, in order, before you touch the Submit for Review button in App Store Connect.
1. Install the actual build on a clean device. Not the simulator, not a device with six months of cached login state. Offload the app or use a spare device, then install the exact IPA (or TestFlight build) you're about to submit. Walk through onboarding as a brand-new user. This is where broken empty states, missing seed data, and crash-on-first-launch bugs — the core of Guideline 2.1 rejections — show up.
2. Trigger every permission prompt and read the string verbatim. Camera, photo library, location, microphone, notifications, tracking — each one needs a purpose string that says what you do with the data, not a placeholder like "This app needs your location." If you're on Expo, generic auto-filled permission strings are a recurring failure point; see Expo App Store permission description for what reviewers expect instead. If your app collects accounts, confirm deletion is reachable from inside the app — not just via a support email — per the account deletion requirement covered in App Store account deletion for Expo apps.
3. Check IAP and subscription config against what App Store Connect actually has live. Every SKU referenced in your build needs a matching product in ASC, in the correct state, with pricing set. This is also where App Privacy "Data Not Collected" answers get contradicted by the SDKs you actually ship — RevenueCat and other analytics SDKs are common culprits; see RevenueCat and missing metadata on the App Store for the specific mismatch reviewers flag.
4. Re-screenshot from the real build, not the design file. Every screenshot in your listing should reflect a screen that exists, in a state a real user can reach, in the current build. Mismatched screenshots are a fast 2.3.3 rejection.
Run these four checks as a fixed checklist, not from memory — that's the difference between catching an issue yourself and getting a rejection email. If you want to see what a structured version of this check looks like output-to-output, the sample report shows exactly what gets flagged and how it's written up before a real submission.
Run Your Next Submission Through a Real Preflight Check
Knowing the nine reasons doesn't fix your build. Checking it against them does.
Before you hit submit again, run your app through a structured pass — not a vibe check the night before the deadline. Pull up each guideline above and go screen by screen: does every button do something, does the privacy manifest match what the app actually collects, does the account deletion flow work without a support ticket, do your subscription screens show price and duration in the format Apple wants. Write down what you find. A rejection is expensive in review-queue days; a checklist is free.
If you want to see what a thorough version of that check looks like before you build your own, look at a sample report — it shows the kind of line-by-line findings a real preflight pass surfaces, from metadata mismatches to missing permission strings.
That's also the gap the App Store Preflight Kit is built to close. It's a Markdown-first skill pack you run against your own repo — it checks your Info.plist, your IAP configuration, your screenshots, and your privacy disclosures against current Apple review guidelines, and hands you a report before you spend a submission cycle finding out the hard way. If you're shipping with Expo or RevenueCat, the same review surface shows up in patterns like missing permission descriptions and incomplete metadata — worth checking even if today's rejection wasn't about either.
Review rejections cost you a queue slot, not just a fix. Catch the issue on your machine, and your next submission is the one that clears.
## Frequently asked questions
### What is the most common reason apps get rejected from the App Store?
Guideline 2.1, Performance — App Completeness. Apple flags crashes, broken links, placeholder content, and login screens with no working demo credentials more than anything else. Metadata mismatches (screenshots or descriptions that don't match the actual app) run a close second under Guideline 2.3. Both are avoidable with a pre-submission pass: launch every screen fresh, test with no account, and check that App Review's demo login actually works before you hit submit.
### How long does Apple's App Store review take after a rejection?
A resubmission typically re-enters the same review queue as a first submission — usually 24 to 48 hours, per Apple's published averages. It's not fast-tracked just because it's a fix. If your rejection involves Guideline 5.1 (privacy) or In-App Purchase configuration, expect the review to take longer, since those trigger closer manual inspection. Build resubmission time into your launch schedule rather than assuming a same-day turnaround.
### Can I resubmit my app immediately after a rejection?
Yes, as soon as you've fixed the specific issue cited in the rejection. Don't resubmit the same build hoping the reviewer missed something — App Review keeps notes, and a second rejection for an unaddressed issue slows you down more than waiting a few hours to fix it properly. If the rejection is unclear, use the Resolution Center to ask the reviewer directly before resubmitting; that's faster than guessing wrong twice.
### Do App Store rejections affect my developer account standing?
No. A rejection is a normal part of review, not a strike against your account. Apple explicitly separates rejections from account-level enforcement. Account standing is only affected by repeated Guideline violations tied to fraud, spam, or policy abuse (Guideline 5.6), or by legal/agreement violations — not by ordinary back-and-forth over metadata, screenshots, or a missed guideline on a single build.
### What's the difference between an App Review rejection and an app removal after it's already live?
A rejection happens before your app goes live — App Review catches the issue during the submission review and the app never reaches users. A removal happens after your app is already on the Store, usually triggered by a user complaint, a policy change, a legal request, or an automated compliance sweep. Removals are more serious: they can affect existing users mid-session and sometimes come with a shorter deadline to fix and resubmit than a standard rejection would.