Apple's App Store Review Guidelines run to tens of thousands of words. Most of it covers edge cases and categories that will never apply to your app.
What the review team actually tests in a typical submission is much narrower. Understanding what reviewers do — step by step, from the moment they pick up your submission — is more useful than reading every guideline in full.
Here's what actually happens during review.
Before the Reviewer Opens the App
Review starts with the listing, not the build.
The reviewer reads your app name, subtitle, and description. They look at your screenshots. They check that your privacy policy URL loads and that your support URL is reachable. They scan the listed permissions and data practices.
This pre-app check takes a few minutes. But it sets the frame for everything that follows. A reviewer who finds a mismatch in the listing — screenshots that don't match the description, promises of features that seem implausible, links that don't work — opens the app already skeptical.
Skeptical reviewers look harder.
The First Session Test
The reviewer installs the app fresh. No prior account. No setup. Clean state.
They see exactly what a first-time user sees. If there's no clear first step, they don't know what to do. If the onboarding flow ends abruptly, they're left on a blank screen with no direction. If the main action requires account creation and the email verification is slow or broken, review stops there.
What They're Not Doing
Reviewers are not reading your code. They're not auditing your architecture. They're not testing every feature in every possible state.
They're testing whether a new user can understand the app, use the core feature, and trust what the listing said.
This has an important implication: your most obscure features and edge-case flows are unlikely to be what causes a rejection. Rejections almost always come from the main path — the first session, the core feature, the listing accuracy — not from a bug buried three levels deep.
Network Testing
Reviewers test on real devices under real-world network conditions — including slow and unstable connections.
Apps built on assumptions of fast, reliable connectivity fail this test regularly. A spinner that never resolves. A blank screen where data should appear. A button that appears to do nothing because the API call is timing out.
From the reviewer's perspective, an unresponsive button is a bug. They don't know it's a network issue. They document a frozen UI and reject the build.
The fix isn't complex: every network call needs a visible loading state, an error message if it fails, and a retry option or graceful fallback. Apps that handle poor connectivity predictably pass this part of review without friction.
Permission Prompts
Reviewers are trained to notice when permission prompts appear too early or without clear justification.
A camera permission requested on the first screen — before the user has any context for why the app needs camera access — is a flag. A notification permission requested before the user has experienced any value from the app is a flag.
The timing rule: request permissions at the moment the user initiates an action that requires them. Not before. Not preemptively "just in case." At the moment of clear need, with a brief explanation of what the permission enables.
iOS allows you to show a custom explanation screen before the system permission dialog appears. Use it. A sentence explaining "we need camera access to scan receipts" dramatically increases both acceptance rates and review confidence.
Payment and Subscription Flow
If your app has in-app purchases or subscriptions, the reviewer completes a test purchase.
What they're checking: whether the terms are clearly displayed before confirmation, whether the payment flow uses Apple's IAP framework correctly, and whether there are any attempts to route users to an external payment method for digital content.
Subscription apps specifically get checked for a Restore Purchases option and clear management instructions. These are tested, not just read about in a description.
What Triggers Escalation to a Senior Reviewer
Most rejections are handled at the initial review level. A few categories tend to escalate to senior review — which means longer wait times and higher scrutiny:
- Apps that make health, medical, or financial claims that could harm users if inaccurate
- Apps that target children or appear in kids categories
- Apps with user-generated content that lack clear moderation mechanisms
- Apps that appear to duplicate existing first-party iOS functionality without differentiation
- Apps with significant policy gray areas — certain VPN configurations, privacy tools, or apps touching sensitive data categories
If your app falls into any of these categories, expect longer review times regardless of submission quality. It's not a rejection signal — it's a routing signal.
The Practical Takeaway
Review is a first-impression test performed by a person who knows nothing about your app and has limited time to evaluate it.
If the listing is accurate, the first session is clean, the core feature works under real-world conditions, and the business model is implemented correctly, most apps clear review without issue.
The apps that struggle are almost never the ones with the most complex features. They're the ones where the first few minutes of the user experience — the exact path a reviewer follows — breaks down in ways that were never tested from a fresh install.
