Most App Store rejections have nothing to do with your idea. They come from completeness problems: the app crashed on the reviewer's device, the reviewer could not log in, a link was broken, or something was still placeholder. Apple says over 40% of unresolved issues fall under guideline 2.1, App Completeness. Fix the specific thing named in the message, reply in App Store Connect, and resubmit.
A rejection feels personal the first time. It is not. It is a checklist item you missed, and nearly every developer who ships to iOS collects a few. This post covers how common it is, the reasons that come up again and again, how to reply, and when an appeal is worth it.
Rejection is routine
Apple publishes its numbers. In its 2025 App Store Transparency Report, checked in October 2026:
| 2025 | |
|---|---|
| App submissions reviewed | 9,100,620 |
| Submissions rejected | 2,093,244 |
| Approved after a rejection | 387,087 |
Roughly one submission in four was rejected. By section of the guidelines, Performance led with 1,354,418 rejections, then Legal with 495,673 and Design with 415,532. (A submission can be rejected under more than one section, so those add up to more than the total.) Apple's own summary of the same year mentions more than 443,000 submissions rejected for privacy violations alone.
So the question is never whether you will get rejected at some point. It is how quickly you can turn it round.
The common reasons, and the fix for each
Apple lists its common rejection issues on the App Review page, and the guideline numbers below are from the current App Review Guidelines.
| What went wrong | Guideline | The fix |
|---|---|---|
| The app crashed or a feature did not work | 2.1 | Test on a real device on the latest iOS, not only the simulator |
| The reviewer could not sign in | 2.1(a) | Put a working demo account in App Review Information, and keep the back end running |
| Placeholder text or images | 2.1 | Ship only finished screens. "Coming soon" tabs count as placeholder |
| Broken support or privacy link | 2.1, 5.1.1 | Both links are required. Open them yourself before submitting |
| Privacy policy too vague | 5.1.1(i) | Say what you collect, how, why, who it is shared with, and how to delete it |
| A permission prompt with no clear reason | 5.1.1 | Write a purpose string that says what the access is for, in plain words |
| No way to delete an account | 5.1.1(v) | If users can create an account in the app, they must be able to delete it in the app |
| Google or Facebook login with no alternative | 4.8 | Also offer an equivalent login that limits data to name and email and lets users hide their email |
| Digital features unlocked outside in-app purchase | 3.1.1 | Use in-app purchase for subscriptions and unlocks (see the US exception below) |
| Paywall does not say what you get | 3.1.2(c) | State what the subscription includes and what it costs, before the purchase |
| Screenshots of the splash screen or login | 2.3.3 | Show the app in use |
| New features not described | 2.3.1(a) | Describe changes specifically in Notes for Review. Apple says generic descriptions get rejected |
The two that catch web developers
If you come to iOS from the web, two guidelines account for a lot of surprise.
4.2: a website in an app is not an app
Guideline 4.2 says your app should include "features, content, and UI that elevate it beyond a repackaged website." A web view wrapping your existing site, with no native navigation and nothing that uses the device, is exactly what it describes. Apple's common-issues page puts it bluntly: websites served in an iOS app "do not make a quality app."
The fix is not a cosmetic one. Give the app something that only makes sense on a phone: offline access, notifications that matter, the camera, native screens for the core task. If the honest answer is that your product works fine in Safari, it may be a web product, and that is allowed.
3.1.1: digital unlocks go through in-app purchase
If the app unlocks features, content or a subscription, guideline 3.1.1 says you must use in-app purchase. License keys, QR codes and your own checkout do not count.
There is one significant exception, checked in October 2026: on the United States storefront, apps may include buttons and external links to other ways of buying. Outside the US, the old prohibition still applies apart from specific entitlements. If you sell outside the US, which most apps do, plan for in-app purchase. RevenueCat and Superwall: what each one actually does covers the tools most indie apps use on top of it.
How to reply to a rejection
The rejection message names a guideline and usually describes what the reviewer saw. Read it twice. Then do one of two things.
If they are right, fix it and resubmit. Say what you changed in your reply, briefly. A reviewer reading "fixed" learns nothing.
If they misunderstood, reply with specifics. Explain exactly where the feature is, how to reach it, and attach a screen recording if it is more than two taps deep.
Thanks for the review. Account deletion is under Settings, Account, Delete account (the last row on that screen). It deletes the account and all associated data immediately. I have attached a 20-second recording showing the flow from launch, and added these steps to the Notes for Review.
That reply is short, specific, and gives the reviewer nothing to guess. Most misunderstandings end there.
When to appeal
If you believe the reviewer got it wrong and a reply did not resolve it, you can appeal to the App Review Board. Apple asks for specific reasons why the app complies, one appeal per rejected submission, and answers to any outstanding questions first.
Appeal when you have a real argument tied to the wording of a guideline. Do not appeal because the rejection is inconvenient: fixing the issue is almost always faster.
Before you press submit
Apple says it typically reviews at least 50% of submissions within 24 hours and 90% within 48. A rejection and a resubmission can easily cost you two of those cycles, so this list is worth five minutes:
- Install the exact build on a real device running the current iOS and use every main flow once.
- Log in with the demo account you are giving Apple.
- Open the support link and the privacy policy link.
- Search the app for "lorem", "TODO" and "coming soon".
- Trigger every permission prompt and read the text it shows.
- Create an account, then delete it.
- Write Notes for Review that describe what is new, specifically.
If launch timing matters, add a buffer for at least one round of rejection. In December that buffer needs to be bigger: shipping an app before the holidays covers why. And if you are hiring someone to do the iOS work, "how many apps have you taken through review, and what got rejected?" is one of the most useful questions in how to hire an iOS developer.