What Actually Happens After You Hit Submit for App Store Review
You hit Submit, refresh App Store Connect, and the status changes to "In Review." Then you wait — sometimes ten minutes, sometimes most of a day. Is a reviewer actually examining your app that entire time? What triggers a rejection versus a quick approval? Understanding the pipeline behind that status label takes a lot of the mystery (and anxiety) out of the process.
Step 1: The Automated System Check
The moment your submission enters review, it runs through an automated check first. This pass evaluates the build against a set of automated signals — the kind of things software can verify without a human: metadata, obvious policy triggers, technical validation, and pattern matches against known problems.
The automated check produces one of two broad outcomes: it either clears the submission, or it flags something that needs a human to look more closely. Think of it as triage. Most straightforward submissions — a clean bug-fix update to an app that's passed review many times before — can move through this stage with little friction.
Step 2: Escalation to Manual Review
When the automated check flags something, a human reviewer opens your submission. Their job is to test the app against the specific guideline the flag relates to and decide whether it complies. This is where the things you provide at submission time matter most:
- Demo credentials so the reviewer can actually log in
- Test steps so they can reach the feature in question
- App Review Notes explaining anything unusual
If the reviewer can't reach a feature or can't tell how something is supposed to work, the safest outcome for them is to reject and ask — which costs you a full cycle. Everything the reviewer needs should be waiting for them. (See our guide on what to put in your App Review Notes for a template.)
The reviewer then returns a result: approved, or rejected with a guideline reference.
Why Review Times Swing So Wildly
Here's the part that confuses most developers. You've had the same app approved in ten minutes one week and take six hours the next. That range almost never means a reviewer spent six hours on your app.
Two things drive elapsed time:
- Queue position. Submissions line up. A long wait usually just means yours was further back — not that anything is wrong.
- Parallel handling. Reviewers work through many submissions at once. The clock you're watching between "In Review" and a decision includes all the batching and context-switching happening behind the scenes, not focused attention on your app alone.
So a six-hour review doesn't mean six hours of scrutiny, and a ten-minute review doesn't mean your app was waved through carelessly. Both can be the same depth of review — they just entered and exited the queue at different times. For a deeper look at the factors that push submissions into slower or faster lanes, see our guide on why some reviews take an hour and others take a week.
Established Apps Get the Same Treatment
A common assumption is that once your app has been on the store for years, updates get a lighter review. They don't. An update to an established app runs through the same pipeline as a first-time submission — the same automated check, the same possibility of manual escalation.
There's no "trusted developer" toggle that skips the process. What does help is making the review efficient: precise release notes, clear App Review Notes, and an explicit callout when an update is minor. You can't shorten the queue, but you can make sure that when a reviewer looks, they can confirm compliance fast.
About Those "Bug Fixes and Improvements" Release Notes
Generic release notes — "Bug fixes and performance improvements" — don't offend anyone reviewing your app. Evaluating the build is the job, whatever the notes say. But they're a missed opportunity.
If your update genuinely is a small change, spell it out in the App Review Notes: what changed, and just as importantly, what didn't. The review process can't always tell how minor a change is on its own. Telling the reviewer "no changes to permissions, payments, or account logic since the last approved version" gives them a fast, confident path to approval — and is one of the best ways to reduce the frustrating experience of a near-identical resubmission getting a different result than last time.
The Takeaway
The "In Review" status hides a two-stage pipeline: an automated check that clears or flags, and a human review when something needs a closer look. The wait time you see is mostly queue mechanics, not scrutiny intensity. And no app — however established — skips the process. You can't control the queue, but you can control how easy you make the reviewer's job. That's where clear notes, working demo accounts, and honest release notes pay off.
After Approval, the Real Work Begins
Getting through review is just the start. Once your app is live, user reviews drive your rating and ranking every single day. AppStoreReview monitors your app across 175+ countries, sends instant alerts for new and negative reviews, and lets you filter by keyword — so nothing slips past you.
Frequently Asked Questions
When my app says 'In Review,' is a person looking at it the whole time?
Not usually. When a submission enters review it first runs through an automated system check. That check either clears the app or flags it for a human to inspect. If a human does look, they're testing your app against the relevant guidelines — but they're handling many submissions in parallel, so the elapsed time between 'In Review' and a result is mostly queue and batching, not one reviewer staring at your app for hours.
Why did one submission review in ten minutes and another take six hours?
The elapsed time reflects where your submission sat in the queue and whether it was flagged for manual review, not how interesting your app is. A fast result often means the automated check cleared it or a reviewer picked it up quickly. A long wait usually means it was further back in line or got routed for a closer look. The variance is normal and largely outside your control.
Do established apps get reviewed less strictly than new apps?
No. An update to a long-established app goes through the same review process as a brand-new app. There's no 'trusted app' fast lane that skips the checks. What you can do is make the review efficient — clear release notes and App Review Notes help the reviewer confirm quickly that nothing problematic changed.
Does 'Bug fixes and performance improvements' as release notes annoy reviewers?
No — reviewers don't take it personally; evaluating the build is the job. But vague release notes do miss an opportunity. If your update really is minor, saying exactly what changed (and what didn't) in the App Review Notes helps the reviewer confirm there's nothing new to scrutinize, which can smooth out inconsistent re-review outcomes.