The App Store Review Process, End to End: What Happens After You Hit Submit

The App Store review process is the pipeline every build runs before it can go live: you upload the binary, Apple's servers process and scan it, a reviewer on the App Review team opens it and tests it against the App Review Guidelines, and then you get one of two verdicts — approved, or rejected with a specific guideline number to fix. Apple's own published figure is that 90% of submissions are reviewed in under 24 hours, so for most apps the whole thing is a same-day event.

But the day it isn't, you want to know exactly which stage you're sitting in and why. This walks the pipeline end to end: every status you'll see in App Store Connect, what actually happens at each one, and the handful of reasons a review turns into a rejection. One thing to name up front. This is Apple's *App Review*, the gate a build passes through before launch, and it's a different thing from the user reviews people leave once your app is live, though the two get tangled constantly. Google Play runs its own separate review pipeline, which we touch at the end.

There are five, and App Store Connect names each one so you always know where a build is. Most submissions walk straight through in order; the ones that stall almost always stall at the same two stages. Here's the full path from your Submit tap to a live app:

Before any person looks at your app, Apple's automated layer does. On upload, App Store Connect runs static analysis and a malware scan over the binary, and checks for the things a machine can catch faster than a human: use of private APIs, missing or mismatched entitlements, an unsupported minimum OS or architecture, a malformed Info.plist, or a privacy manifest that doesn't match the frameworks you linked. A chunk of rejections happen right here, automatically, and they read as 'Invalid Binary' or an ITMS error rather than a guideline citation.

Clear that, and the build enters the human queue as 'Waiting for Review.' The automated pass is necessary but not sufficient. It filters the obviously broken so the App Review team spends its time on judgment calls, not crash-on-launch builds. Think of it as the metal detector before the interview.

A real person installs your build on a real device and uses it, guidelines open beside them. They're not reading your code; they're driving your app the way a picky first-time user would, and checking that what you shipped matches what you promised. The things they hit hardest:

A rejection isn't a verdict on you; it's a message. Apple posts it in the Resolution Center inside App Store Connect, names the guideline you tripped, and often attaches a screenshot or a note about what they saw. You fix it, reply or resubmit, and it goes back in the queue, often for a faster second look, since the reviewer already has context. Most rejections are boringly fixable: a broken support URL, a missing demo account, a purpose string you forgot, a screenshot that no longer matches the UI.

The distinction that saves you a day is metadata versus binary. If Apple rejects only your metadata — a bad screenshot, a misleading subtitle, a dead privacy-policy link — you can fix it in App Store Connect and resubmit *the same build*, no new upload, no reprocessing. A binary rejection (a crash, a private-API use, a guideline the code itself violates) needs a new build and a fresh trip through Processing. Read which kind you got before you rebuild anything.

Apple's published figure is 90% of submissions reviewed within 24 hours, and in practice most first submissions and updates clear in a single business day. The variable part is 'Waiting for Review,' the queue, not 'In Review,' which is usually quick once a reviewer picks up your build. New apps tend to sit slightly longer than updates, and the year-end holidays stretch everything (Apple keeps reviewing but warns of reduced availability and slower turnaround around late December). For the full breakdown of typical times, what makes a review run long, and how to read the clock on each status, see [how long does App Store review take](/blog/how-long-does-app-store-review-take).

Two different situations, two different moves. If you have a genuine reason to jump the queue, like a critical bug fix for users or a time-sensitive launch tied to an event, Apple lets you file an expedited review request, and it's real: approved requests can turn a multi-day wait into hours. Use it sparingly; abuse it and future requests get ignored. The when, how, and etiquette of it live in [expedited App Store review](/blog/expedited-app-store-review).

Stuck is different. If a build has sat in 'In Review' for days with no movement, or 'Waiting for Review' has blown well past the norm for your account, that's not a speed problem — it's a snag, and it usually means the reviewer hit something they need to escalate, or the submission is caught in a manual check. The playbook for diagnosing and un-sticking it is [app stuck in review](/blog/app-store-stuck-in-review).

App Review is a gate you pass once per build. The moment you release, a second review process begins, the one that never ends: real users rating and reviewing your live app, every day, in every language you ship in. That's the process most teams underestimate, because unlike App Review there's no queue to clear and no approval to earn. There's just a steady stream of one-to-five-star feedback, and a public reply box under each one that a prospective installer will read.

This is where App Review and user reviews stop being the same word and start being two jobs. Apple decides whether your app ships. Your users decide, review by review, whether the next person installs it — and whether you look like a team that answers or one that ghosts. A crash report that would've been a 2.1 rejection pre-launch shows up post-launch as a one-star review instead, and now the fix is a reply plus a shipped update, not a resubmission.

That reply is the whole ongoing review process in miniature: acknowledge, name the fix, offer one next step, and do it publicly so the next reader sees a team that's on it. The research backs the effort. When Google introduced recency-weighted ratings at I/O 2019, it reported that responding correlates with an average lift of 0.7 stars, and across 4.5 million reviews Hassan et al. found users who got a response were roughly six times more likely to raise their rating (4.4% vs 0.7%). Passing App Review gets you on the shelf; answering reviews is what keeps you there.

That's the whole pipeline: upload and processing, the automated scan, the queue, a human pass against the guidelines, and a verdict you either release or fix and resubmit. Clear it and you're on the shelf — and the review process that actually decides your rating begins. When those user reviews start rolling in, and they will, the smart move is to answer them well and fast rather than let them pile up. [Start free with ReplyArgus](/signup), no card, and Argus drafts your first App Store and Google Play replies in minutes, each one in the reviewer's own language and grounded in what you've actually shipped. And if you're still deciding what to say to the harsh ones, [how to respond to negative app reviews](/blog/how-to-respond-to-negative-app-reviews) is the field guide.