App Store rejection decoder
Apple sent you a guideline number and three sentences. Paste them here and get the sub-reason it actually maps to, what causes it, how to fix it, and a reply you can adapt for the Resolution Center. Works on Google Play rejections too.
Rules last reviewed 2026-07-16 · 15 sub-reasons, Apple + Google Play · free, runs in your browser
Nothing is uploaded. The decoder runs in this browser tab — your rejection text, your app name and any credentials in it never reach our server.
Why 2.1 is the rejection nobody can read
In Apple's guidelines, 2.1 is a single short paragraph headed «Performance — App Completeness». It asks for final builds with working URLs and no placeholder content. In the Resolution Center, it means something much wider: Apple staples the 2.1 label onto anything that stopped the review from finishing.
So two developers both get «Guideline 2.1 — Performance — App Completeness», and one has a null-pointer crash while the other has a staging password that expired on Friday. Same number, unrelated work. The useful information is in the sentence under the heading, never in the number — and that sentence is what the table below, and the decoder above, are built around.
Apple App Store Review Guidelines — 2.1 App Completeness
The 2.1 sub-reasons, and which ones a build scan can catch
We build a static analyzer, so we'll be blunt about its limits. A binary scan reads what's baked into your bundle: entitlements, ATS exception domains, purpose strings, version strings, launch assets. It cannot run your app, cannot reach your backend, and cannot open App Store Connect. That splits the 2.1 family cleanly in two, and the third column is where the split falls.
| Sub-reason | Probable cause | Detectable in the build? |
|---|---|---|
| Crash on launch or during review | The reviewer's device hit a fatal error your test devices didn't. | Partly |
| Reviewer could not sign in (demo account missing or dead) | The reviewer hit your login wall and couldn't get past it. | No |
| Content wouldn't load — backend unreachable from review | Your app talked to a server and got nothing back. | Partly |
| Placeholder or incomplete content | Apple's 2.1 text is explicit: submissions «should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission». | Partly |
| Bugs found during review (no crash) | The reviewer found something that doesn't work but didn't crash — a dead button, a broken flow, a screen that renders wrong on their device size. | Partly |
| Reviewer couldn't get past the paywall or unlock the content | Everything interesting in your app sits behind a purchase the reviewer couldn't make. | Partly |
Notice how much of the column says «no» or «partly». The two biggest 2.1 causes — a dead demo account and a backend the reviewer can't reach — live entirely outside the binary. That's why the tool asks you 33 questions after the scan instead of pretending the scan is the whole answer, and why this decoder exists as a separate free door: if you're already rejected, uploading a 500 MB build is the wrong first move.
Reply, or resubmit?
The order matters more than most people realise. Uploading a new binary is a new submission — it goes back to the end of the queue. Replying in the Resolution Center doesn't; it reaches the same reviewer in the same thread.
So: if the reviewer asked for something (credentials, steps, a clarification), reply and send nothing else. If the app is broken, fix it, upload, and reply in the same breath to say what changed. A build uploaded in a panic before you understood the rejection costs you a full cycle and usually earns the same rejection twice.
Apple — App Review: preparing your app
Apple 2.1 ↔ Google Play, side by side
If you ship both stores, the same underlying failure gets two very different rejections. Apple names a guideline and describes what the reviewer saw. Google names a policy and gives you one line.
| Underlying failure | Apple says | Google says |
|---|---|---|
| App crashes for the reviewer | Guideline 2.1 — App Completeness, with a crash log | Broken Functionality — «App crashes», no log |
| Reviewer can't sign in | Guideline 2.1 — Information Needed | Broken Functionality — «App installs, but doesn't load» |
| App is a website in a shell | Guideline 4.2 — Minimum Functionality | Spam — minimum functionality / webview |
| Listing overpromises | Guideline 2.3 — Accurate Metadata | Broken Functionality — «doesn't provide the described functionality» |
The practical difference: Apple tells you the device and OS, so you can reproduce. Google doesn't, so your first stop is the Pre-launch report — Google already ran your build on real hardware. The full Broken Functionality guide walks each issue line.
Frequently asked
What does Guideline 2.1 mean?
Guideline 2.1 is Apple's «Performance — App Completeness» rule, and it's the least specific rejection Apple sends. Apple reuses that one number for a crash on launch, a demo account that doesn't work, a backend the reviewer couldn't reach, placeholder content, a bug found during review, and content locked behind a paywall the reviewer couldn't open. The number tells you almost nothing — the sentence underneath it tells you everything, which is what this decoder reads.
Should I fix and resubmit, or reply in the Resolution Center?
Reply first if the reviewer needs information: a working demo account, steps to reach a feature, or a clarification about what your app does. That doesn't need a new build and it's the fastest path. Upload a new build when something in the app is genuinely broken. Uploading a build resets your place in the review queue, so a build you didn't need to send costs you the wait.
Does replying to a rejection restart the review?
Replying in the Resolution Center goes back to the same review team without resetting your queue position — it's a conversation, not a resubmission. Uploading a new binary is a new submission and starts the review over. That's why «reply first, build second» is usually the cheaper order when the reviewer only asked a question.
Can I appeal an App Store rejection?
Yes. Apple's App Review Board handles appeals, and it's the right channel when you believe the guideline was misapplied — not when your app is genuinely broken. Appeal a judgement call (4.2 minimum functionality, 4.3 spam, a 3.1.1 read of a physical-goods purchase). Don't appeal a crash. For a factual disagreement, answer in the Resolution Center first: most misreads resolve there in one message.
Is my rejection text sent to your server?
No. The decoder is a lookup table shipped with the page and it runs entirely in your browser tab — there's no request to decode. That matters because rejection messages routinely contain the app name, the reviewer's notes, and sometimes the demo credentials you pasted into App Store Connect.
Google didn't cite any policy number. Now what?
Play doesn't work like Apple. You get a policy name («Broken Functionality», «Spam») and a one-line issue («App installs, but doesn't load») with no device, no OS and no logs. Paste that line anyway — the decoder keys off Google's issue strings too. Then go to Play Console → Pre-launch report: Google ran your app on real devices before rejecting it, and the crash or ANR is often sitting there.
Keep reading
The most common App Store rejection reasons covers each guideline in depth. The submission checklist is the version of this to read before you submit, not after.