- App Store rejection reasons cluster into classes: 2.1 performance and crashes, 3.x payments, 4.x design, 5.x legal and privacy.
- A Guideline 2.1 rejection usually means the reviewer hit a crash, a broken feature, or a state your own devices never reproduce.
- The guess-and-resubmit loop breaks when you can read the actual review session that produced the rejection.
- You can observe an anonymous session and what failed in it. You cannot see, name, or identify the reviewer.
Definitions used in this guide
The sequence of user actions, route changes, and requests that happened before an error fired.
A normalized signature that groups repeated failures together even when line numbers or values vary slightly.
A plain-English explanation of who was affected, what they were doing, and why the error matters to the business.
The problem: a vague rejection and a guess-and-resubmit loop
If you searched "why did Apple reject my app," you already know the shape of the pain. The rejection arrives in App Store Connect as a guideline number, a sentence or two of boilerplate, and — if you are lucky — one screenshot of a moment in your app. The feature "did not work." The app "crashed on launch." Something was "not appropriate." You read it three times and you are no closer to knowing what actually happened on the device.
So you guess. You change something plausible, write a note in Resolution Center, and resubmit. Then you wait days for the next decision, which may reject you for the same reason or a new one. That guess-and-resubmit loop is the real cost of an Apple app review rejected outcome: not the rejection itself, but the days you burn cycling against a description instead of a fact.
The first half of this guide is the genuinely useful part even if you never touch Crossdeck: what the common rejection guideline classes actually mean. The second half is the step change — reading the real session beside the rejection.
App Store rejection reasons, by guideline class
Apple's App Review Guidelines are organized into numbered sections, and most rejections you will ever see fall into a handful of classes. Knowing the class tells you what kind of evidence to go looking for.
| Class | Theme | What it usually means in practice |
|---|---|---|
| 2.1 | Performance — App Completeness | The build crashed, a feature did not function, placeholder content showed, or the reviewer hit a state your own devices never reproduce. The most common and most reproducible-with-telemetry class. |
| 3.x | Business — Payments | Something about purchases: missing restore, using non-Apple payment for digital goods, mismatched or missing in-app purchase products, unclear subscription terms. |
| 4.x | Design | Minimum functionality, spam or duplicate apps, sign-in requirements, or UI that does not meet platform expectations. Often subjective and harder to debug from telemetry alone. |
| 5.x | Legal | Privacy, data handling, permissions, account deletion, intellectual property, or regulatory issues. Usually a policy or disclosure fix, not a runtime bug. |
A closer look at the Guideline 2.1 rejection
The Guideline 2.1 rejection — "App Completeness" under the Performance section — is worth its own heading because it is the one developers most often cannot reproduce. The feedback is some version of "the app crashed" or "this feature did not work," frequently with a screenshot of an empty screen, a stuck spinner, or a blank grid.
The maddening part of a 2.1 is that the app works perfectly on every device you own. That is exactly the signature of an environment-specific failure: a regional content endpoint that returns an error only for a US-configured device, a race condition that only fires on a clean install, a permission prompt that behaves differently on a fresh device. The reviewer saw a real failure; you just were not holding the device when it happened.
This is precisely the gap that observing the review session closes. A 2.1 that points at an empty screen plus an error that fired the instant that screen loaded is no longer a mystery — it is a bug report with a repro path.
- App crashed on launch or during a core flow — look for an uncaught exception in that session.
- Feature "did not work" — look for a failed network request or stuck state at the cited screen.
- Empty or blank content — look for a regional endpoint failing for the device's configured region.
- Cannot reproduce on your own devices — that is the signal it is environment-specific, not that the reviewer was wrong.
The step change: observe the actual review session
Here is what changes the game. The build Apple reviews is the build you shipped — SDK and all. If your build carried the Crossdeck SDK, the session that ran on the review device is anonymous production telemetry that appears in Crossdeck Live and People like any other first-time visitor: a journey across screens, dwell on each, dismissals, device context, and any errors that fired. There is nothing to enable per submission.
That means the forensic workflow is short. Filter your session list to the window between submission and decision. Find the fresh anonymous session — a new identity with no prior history, often US device context, often a methodical walk-the-surface pattern. Open its journey, walk to the moment the rejection screenshot describes, and cross-reference Issues for an error that fired there. The empty grid in the screenshot is frequently a failed request, observed.
Be clear about what this is. You are observing an anonymous visitor's session, the same kind you collect from every install. You are not identifying, naming, watching, or tracking a reviewer — Crossdeck cannot do that, and this is not that. The value is the session behaviour and the error it surfaces, not the identity behind it. Not every review produces such a session; automated checks may dominate, and you will not always know why you were rejected. The full procedure lives in the App Review sessions guide and the step-by-step forensics walkthrough; the story of the first time I saw one is in I watched Apple review my app — live. If your build does not carry the SDK yet, start with the iOS quickstart so your next resubmission is visible.
Frequently asked questions
Why did Apple reject my app?
Most rejections cite a specific App Review guideline — commonly 2.1 (a crash or broken feature), 3.x (payments), 4.x (design or minimum functionality), or 5.x (legal and privacy). The guideline tells you the category; the hard part is finding what actually happened on the review device. If your build carried the SDK, you can open the anonymous review session and walk to the cited moment to see the real failure.
What is a Guideline 2.1 rejection?
Guideline 2.1 covers App Completeness under Performance. In practice it usually means the build crashed, a feature did not function, or the reviewer hit an environment-specific state your own devices never reproduce — an empty screen, a stuck spinner, a failed regional request. It is the rejection class most often solved by reading the actual session and the error that fired in it.
How long does App Review take?
Apple does not guarantee a fixed time, and it varies by submission. Many reviews complete within a day or two, but it can be faster or slower. The practical point for forensics is to filter your session list to the window between your submission and the decision, whatever that window turned out to be.
Can I see what the reviewer did?
You can see what happened in an anonymous session — the journey, the dwell, the dismissals, and any errors that fired — if your build carried the SDK. You cannot see, name, or identify the reviewer. You observe an anonymous visitor's session exactly as you do for any visitor; Crossdeck does not identify the person behind it, and device context like timezone is configuration, not proof of location or identity.
How do I resubmit after rejection?
Fix the root cause, then resubmit through App Store Connect with a Resolution Center note that references the concrete behaviour you observed rather than a guess. If your build carried the SDK, base that note on the actual failure the anonymous review session surfaced — the failed request or crash at the cited screen — and confirm the fix under the same conditions that triggered it. The step-by-step forensics guide has the full resubmission checklist.
Take this into the product
Read the full guide on running rejection forensics from an anonymous review session, then add the SDK so your next resubmission is visible.