Getting a rejection email from App Review feels personal. It usually isn't. Apple runs the same review process against every submission, and most rejections trace back to a small number of guidelines that come up again and again. Knowing which ones, and what they actually mean, turns a vague rejection into a fixable checklist.
How often this actually happens
Apple's own 2024 App Store Transparency Report puts real numbers on this. Out of 7.77 million app submissions reviewed that year, 1.93 million were rejected, roughly 25%. Of those, 295,109 were fixed and approved on resubmission. Separately, 82,509 already-live apps were removed after the fact, most commonly for guideline or design violations (42,252), followed by fraud (38,315).
Apple hasn't published a breakdown of rejections by specific guideline number, so treat any listicle claiming "62% of rejections are X" as unsourced. What Apple has said, in its own commentary alongside the report, is that the most common drivers, in order, are performance and bugs, legal issues, design problems, business-model (payment) violations, and safety risks. That ordering lines up with the specific guidelines below.
The guidelines that actually catch people
These are pulled directly from Apple's current App Store Review Guidelines, not paraphrased from a third party.
Guideline 2.1, App Completeness. Covers crashes, obvious bugs, placeholder content, broken demo accounts, and non-functional in-app purchases. If a reviewer can't get past your login screen or your app crashes on launch, this is the line it gets cited under. It's the single most avoidable category, because it's the one you can actually test yourself before submitting.
Guideline 4.2, Minimum Functionality. Your app has to be more than "a repackaged website." Apple wants "lasting entertainment value or adequate utility." A thin wrapper around a web view, with no native functionality added, gets flagged here. A sub-clause, 4.2.6, specifically targets apps built from commercialized app-generator templates unless the actual content provider is the one submitting.
Guideline 4.3, Spam. 4.3(a) bans duplicate submissions under different Bundle IDs, the classic example being the same app re-skinned per city. 4.3(b) targets near-clones in saturated categories (flashlights, simple timers, wallpaper apps, fortune-telling apps) unless yours is "meaningfully different" from what's already in the store.
Guideline 5.1.1, Data Collection and Storage. Requires a working privacy policy link, explicit consent before collecting any data (including "anonymous" analytics), no forcing or tricking users into granting permissions they don't need, and account deletion if your app lets people create an account in the first place.
Guideline 3.1.1, In-App Purchase. Any unlock of digital features or content inside your app has to go through Apple's own In-App Purchase system. License keys, QR codes, or crypto-based workarounds to unlock paid features get rejected here, and loot-box mechanics specifically require published odds.
What changed recently
Two real, dated changes worth knowing about if you haven't submitted in a while:
Privacy manifests, enforced since May 1, 2024. Newly added third-party SDKs on Apple's commonly-used-SDK list now require a privacy manifest and, in many cases, a valid signature. An app missing one for a flagged SDK gets rejected before a human reviewer even looks at it. Apple has signaled this requirement will keep expanding to cover more of the binary, not less.
Guideline 1.2 now explicitly covers random or anonymous chat, as of February 2026. If your app includes any kind of stranger-matching chat feature, Apple's guidelines were revised to state plainly that this falls under User-Generated Content rules, meaning you need real moderation in place, not just a report button as an afterthought.
What actually helps
None of this is exotic. Most of it is just discipline about what you check before you hit submit.
Read the actual rejection line, not just the guideline number. App Review's message usually tells you specifically what triggered it, a missing purpose string, a specific screen that crashed, a mismatched screenshot. The guideline number is the category, not the diagnosis.
Give reviewers a working demo account. If your app requires login, App Review needs a real account that actually works, with real data behind it, not a stub. A broken demo account is one of the most common and entirely self-inflicted 2.1 rejections.
Don't build a payment workaround. If a feature unlocks with money, it has to go through Apple's In-App Purchase system. This is 3.1.1 and Apple checks for it specifically, including license keys and external payment links for digital content.
Check your privacy manifest before you add a new SDK, not after a rejection. If you're pulling in a new third-party dependency, check whether it's on Apple's commonly-used-SDK list and whether it ships a manifest. Finding this out from a rejection costs you a review cycle you didn't need to spend.
The pattern underneath all five categories: Apple is checking whether your app does what it claims, respects the data it touches, and pays through the channel it's supposed to. Most rejections are one of those three things, stated in guideline language instead of plain English.
I built a free tool for this
I built Rejection Doctor (free) after seeing how often the same handful of guidelines come up. Paste in your actual rejection message and it matches it against 57 real rejection categories, tells you what's actually going on, and can draft an appeal letter if you think the rejection was a mistake. It's part of the same project as Macless, which handles the signing and CI side of shipping an iOS app without a Mac.
Top comments (0)