App Store review is opaque by design. The guidelines run to dozens of pages, the rejection feedback is often two sentences, and there's no visibility into what the reviewer actually touched.
This is what we've been able to reconstruct: the shape of a first-pass review, minute by minute, and what each step is really checking.
- A first pass is roughly six to eight minutes, bounded by reviewer throughput
- Install and first screen, screenshot comparison, account create and delete, primary flow, permissions scan
- The account deletion loop eats a quarter of that budget on its own
- Your description sets the expectation the reviewer then tests against
- Most rejections are one of these five steps failing, not a judgement about your product
Sources and caveats
Two former App Store reviewers, both contract, both departed within the last eighteen months, interviewed anonymously. Cross-referenced against our own submission log: 200+ submissions across roughly 30 apps over three years.
Treat the reviewer accounts as single-source. The patterns line up with what we see at scale, but review procedure varies over time and between reviewers, and nothing here is Apple policy.
Minutes 1 to 2: install and first screen
They install the build, launch it, and wait for the first meaningful screen.
What's being checked:
- Does it crash on launch
- Does it reach a functional screen in a reasonable time
- Does it behave sensibly without a network connection
That last one catches people. Reviewers do sometimes kill the connection mid-launch, and an app that shows a blank screen or a raw connection error has demonstrated it has no existence independent of a server. That reads as a wrapped website even when it isn't one.
Design for it: cache the last known good state. Don't require network on first launch if you can avoid it. Ship an offline state you designed rather than one you inherited.
Minutes 2 to 3: screenshots versus reality
They open your store listing on a second device and compare each screenshot to what the app actually shows.
What's being checked:
- Are these screenshots from this build
- Does the UI match the listing copy
- Is anything shown that doesn't exist in the app
Design for it: regenerate screenshots every release, even when the UI barely changed. Automate it. And never reuse assets from a different app, however similar, because a screenshot that appears in two listings is the kind of signal that pulls the whole submission into a slower queue.
Minutes 3 to 5: create an account, then delete it
If your app allows account creation, they create one, use it briefly, and then try to remove it.
What's being checked:
- Can they sign up with a test email, without phone verification or obscure required fields blocking them
- Is there an in-app account deletion flow, which Apple requires under Guideline 5.1.1
- Is deletion findable quickly from a signed-in state
- Does deletion actually delete, which they may verify by attempting to sign back in
This step is worth a quarter of the entire review budget, which is wildly disproportionate to how much attention it usually gets during development.
Design for it: put the delete button in Settings, one tap deep, labelled "Delete Account" rather than buried under "Manage". Confirm intent, then actually delete. And supply a test account in the review notes that has permission to do all of this.
Minutes 5 to 7: the primary flow against your own description
They read the first paragraph of your App Store description and then try to do the thing it says.
What's being checked:
- Does the app do what the listing claims
- Is the primary feature discoverable without help
- Does a paywall or upsell block the flow the description promised
Design for it: the first sentence of your description should describe what a user can do in their first thirty seconds. If the copy promises an AI writing assistant and the first screen is a login wall, the reviewer has found a mismatch before they've evaluated anything else. If authentication is unavoidable, ship a demo mode or a reviewer bypass and say so in the notes.
This is also the step where an overwritten description costs you. Your listing sets the expectation that the next two minutes test against, and nothing else in the review is graded against a bar you set yourself.
Minutes 7 to 8: permissions and signals
A scan of what the app asks for and anything that looks off.
What's being checked:
- Are requested permissions justified by what the app does
- Do the usage description strings explain why
- Any entitlements that don't belong in a consumer app
- Any sign this is a template with placeholder content still in it
Design for it: prune permissions ruthlessly. A note-taking app requesting contacts access is a question you don't want asked. Write usage strings that name the feature: "To let you add photos to your notes" tells a reviewer something, "Photos" doesn't.
And search your build for placeholder content before submitting. Lorem ipsum and Sample Item 1 in a shipped app suggest nobody opened the screens, which is the impression that colours everything else.
What this changes
Reviewer attention is a scarce resource. Every second they spend confused moves you closer to a rejection, and there are only about four hundred of those seconds.
The account loop is disproportionate. Two of eight minutes on sign-up and deletion, for a flow most teams treat as an afterthought. If your app has accounts, that flow deserves the same care as your primary feature.
Your description is the rubric. You write it, then get tested against it. Underpromise in the listing and overdeliver in the app, not the reverse.
The thing reviewers actually complain about
Asked what frustrates them most, both said a version of the same thing: apps where you can tell nobody on the team ever used the app end to end.
The fix is unglamorous. Walk the whole thing yourself before submitting. Then hand it to someone who didn't build it and watch them try, without helping. Fix everything they get stuck on. Then submit.
The short version
Review isn't adversarial and isn't magic. It's a few hundred seconds of a person answering a small number of specific questions about your app.
Design so those questions answer themselves, and most of the rejection surface disappears.
For teams shipping repeatedly, moving screenshots, metadata, and review notes into the release pipeline rather than reassembling them each submission removes the most common source of drift between the listing and the build. That's part of what letsdeploy.it handles.
What got you rejected, and how long did it take to work out why? The gap between the rejection text and the actual cause is the part nobody warns you about.
Top comments (0)