App Store review time: 64 real decisions, median 73 hours

TL;DR: I pulled every App Review decision email my developer account has ever received: 64 decisions on 21 iPhone apps, September 10 to October 12, 2026, each with Apple's own "Submitted" timestamp and the time the decision landed. The median wait was 73 hours. Apple's page says it reviews "at least 50% of submissions in less than 24 hours and 90% in less than 48 hours". Mine: 19% inside 24 hours, 27% inside 48. Updates to apps already on the store took a median 64 hours, in-app purchases on their own took 12, and 0 of 21 new apps were approved on their first submission.

Short answer for the search. If you are planning a launch in 2026, budget 3 days per review round for an update, 2 to 5 days for a brand new app's approval, and at least one extra round for a new app on a new account, because the first one usually comes back with a question. A review that sits for a week is not a slow approval. In my data, every wait longer than 5.1 days except one ended in a guideline 4.3 spam rejection.

If you are still at the "what will this cost me" stage, the free iPhone app cost calculator turns features into hours and dollars; this article is about the part no calculator shows, the calendar time between "Submit" and "Ready for Distribution". I build these apps from a Windows PC with no Mac (here is the pipeline), so every submission below went out from a CI job or the App Store Connect website, never from Xcode.

How long does App Store review take in 2026?

Here are the numbers, split the way you will actually meet them. "Wait" is the time from the "Submitted" line in Apple's email to the moment the decision email arrived, so it includes the queue, not just the minutes a reviewer spent with the app.

What you submit	Decisions	Median wait	Fastest	Slowest	Approved
In-app purchases only	5	12.2 h	11.7 h	13.4 h	5 of 5
Update to a live app	16	64.4 h	6.3 h	203.6 h	11 of 16
New app (normal rounds)	21	51.2 h	3.1 h	120.5 h	8 of 21
New app (the two 4.3 spam batches)	22	187.8 h	167.7 h	223.3 h	0 of 22
All	64	73.1 h	3.1 h	223.3 h	24 of 64

Two things jump out. Rejections and questions on new apps come back fast (the 13 normal ones had a median of 27.8 hours), because the reviewer stops at the first problem. Approvals take longer: the 8 first-version approvals had a median of 69.9 hours and none came back inside 48. So a quick reply is, statistically, bad news.

The experiment: one timestamp pair per email

App Store Connect does not give you a history of review durations. Your inbox does. Every decision Apple sends has the same shape: a subject that says either "Review of your App (iOS) submission is complete." or "There's an issue with your App (iOS) submission.", and a body line like Submitted: Oct 08, 2026 at 03:48 PM Pacific Daylight Time. The email's own sent time is the decision time. That is the whole dataset.

I searched Gmail with one search operator query, from:no_reply@email.apple.com newer_than:60d, on October 17, 2026. It returned 69 threads; 64 are decisions (the other five are the App Store Connect welcome, API access approval, two "Welcome to the App Store" notes and one "Thank you for submitting"). The account opened on September 10, so this is the complete history, not a sample. Then the parse:

# media/deepdive/review-time/analyze.py (trimmed)
PT = timezone(timedelta(hours=-7))  # Pacific Daylight Time, as printed in Apple's emails

def sub_dt(s):  # "Oct 08 03:48 PM" from the email body
    return datetime.strptime("2026 " + s, "%Y %b %d %I:%M %p").replace(tzinfo=PT)

for e, app, out, sub, by, kind in ROWS:
    s = sub_dt(sub); d = utc(e)          # e = the email's sent time, UTC
    h = (d - s).total_seconds() / 3600   # hours from Submitted to decision
    recs.append(dict(app=app, outcome=out, kind=kind, hours=round(h, 2), ...))

Each row is also tagged by what was in the submission: a new app's first version, an update, or in-app purchases on their own. I took that from the app's own records (the repos' commit history and my notes) and checked the ambiguous batch against the email body, which lists the items: Chain's October 8 night submission says In-App Purchases (6) and no app version. Rejection reasons are not in the emails at all (the body just says "We noticed an issue"), so those came from the Resolution Center texts I had saved and the replies I sent.

What this method cannot see: submissions I cancelled before a decision (no email, no row), and the exact moment a reviewer opened the app. If you want "time in review" rather than "time waiting", the App Store Connect API exposes the version state, but not its history, so you would have to poll it yourself.

Apple's 24 hour number vs mine

Apple's wording is careful: it says it reviews half of submissions in under 24 hours. That can be true and still not match what you feel, for three reasons that show up in my data.

First, the clock starts in a queue. My approvals cluster at almost exactly the same elapsed time. Seven of the 16 updates landed between 63.5 and 64.5 hours, because they were submitted together on Saturday morning, September 26, and decided together within 32 minutes late on Monday night, Pacific time. Whatever the review itself took, the wait was set by when the queue reached them.

Second, Apple does not appear to work Saturdays on new decisions, at least not mine. Of 64 decisions, Pacific time: Monday 35, Friday 10, Thursday 7, Wednesday 5, Sunday 4, Tuesday 3, Saturday 0. The Monday pile is inflated by the two spam batches (22 decisions), but even without them nothing landed on a Saturday. So yes, App Review works on Sundays (two of the four Sunday decisions were approvals), but a Saturday morning submission still waited until Monday night.

Third, the slow tail is not random. Without the two 4.3 batches my numbers look a lot closer to Apple's: 29% inside 24 hours, 40% inside 48. The 22 spam rejections took 7 to 9.3 days each. Long waits were a signal, not bad luck.

The fast lane is in-app purchases. Five IAP-only submissions (new themes and packs for five live apps, sent through the API late on the night of Thursday, October 8) all came back approved between 11.7 and 13.4 hours later, within 95 minutes of each other. If you need to ship a new price point or a pack quickly, ship it as its own submission and leave the binary alone.

New apps: 0 of 21 approved on the first try

Every one of the 21 apps had its first submission returned. That sounds alarming until you read the reasons. Ten of the 21 first-round emails were guideline 2.1 "Information Needed" (the other 11 were the spam batch below), the routine questions a new developer account gets: send a screen recording of the app on a device, explain the main features, say whether it needs a login, list any external services. Apple's guidelines ask for this up front; the reviewers ask again anyway when the account is new.

The fix that worked was to stop treating the review notes as a formality. Every app now ships with a Store/review-notes.md that the pipeline pushes into App Store Connect's review details, written as a walkthrough a reviewer can follow in under a minute, including how to reach every paid screen:

# chain/Store/review-notes.md (trimmed)
No account, login or network connection is required.

IN-APP PURCHASES (StoreKit 2, all optional, Restore in Settings):
- Chain Unlimited (existing non-consumable): add three habits, tap New habit again; ...
- Streak Repair, $0.99 consumable: when a chain of 2+ days breaks, Today shows a
  "chain broke" banner and the rescue sheet opens. ... To see it on a fresh install:
  add a habit, open Week, tick the two days before yesterday, leave yesterday empty,
  then relaunch.

PRIVACY: no data is collected. No accounts, analytics, ads or third-party SDKs.

After the first 2.1 round, Chain, Ironbook and Quiver were resubmitted on September 22 at 4:21 AM Pacific with answers and a screen recording, and all three were approved 51 to 67 hours later. Of the 8 apps that made it to the store, the median time from the very first submission to the first approval was 4.4 days (range 3.75 to 7.2). That is the honest number to put in a launch plan for a new app on a new account: not 24 hours, closer to a working week.

The other first-round reasons are worth knowing because each one is cheap to prevent:

• 5.1.1 privacy, twice, same app. Minder, a focus timer whose cartoon eyes can follow your face (the eye animation is in this SwiftUI piece), was asked exactly what face data it collects, keeps and shares. The answer (one x/y position from Apple's on-device Vision framework, never stored) had to be in the privacy policy, not just in the reply. A week later it was rejected again because the privacy policy URL itself had stopped loading. I fixed the hosting, resubmitted six minutes after the email, and it was approved 24.8 hours later.
• 1.4.1, health claims need sources. Race Fuel gives carbohydrate, fluid and sodium targets for endurance races. Guideline 1.4.1 wants medical-adjacent numbers backed by citations. The fix was a sources screen with seven DOI-linked papers and a link under every figure.

Guideline 4.3: a week of silence, then 11 rejections in 30 seconds

Eleven of my apps (a car maintenance log, a parking timer, a home inventory, a grocery price log, a pet medication tracker, a chore chart, a tip tracker, a grade calculator, a bouldering log, a running pace calculator and a caffeine cutoff calculator) were submitted on September 26. They sat in the queue for 8.7 to 9.3 days. Then, on Monday, October 5, all 11 rejection emails arrived between 5:29:32 PM and 5:30:02 PM Eastern. Same text for every app: guideline 4.3 Spam plus 4.2.6, apps made from a template or app generation service, with nine questions to answer. The Resolution Center showed every message timestamped 5:29 PM.

The rejection text was explicit about what to do next: if you think the app already complies, do not resubmit, reply to the message and answer all nine questions. I replied to each one (no public beta, tested through automated Simulator runs; a shared StoreKit purchase class and test driver, disclosed), filed App Review Board appeals for all 11, and also resubmitted all 11 that same afternoon. The resubmissions were the mistake. Seven days later, on Monday, October 12, 11 more rejections arrived within 27 seconds, each one 7.0 days after its resubmission.

What the data says about 4.3, as a reader planning your own launch:

• The wait is the tell. In my data every review that ran past 5.1 days except one was a 4.3 rejection. The exception was Clear the Strait 1.1.1, which I resubmitted together with a long written explanation of how the game works after the reviewer asked; it took 8.5 days and was approved.
• It is decided per developer, not per app. Both batches landed inside 30 seconds. Whatever the review was, it was not 11 separate sessions with 11 apps.
• Do not resubmit unchanged. Apple's own email said a resubmission without substantial changes would be rejected again. It was, on a seven day clock, which cost a week per round.

Earlier I measured how much Swift code those apps actually share. The median overlap with the rest of the account was 34.5%, and the two most similar apps on the account (a golf journal and a tennis journal) are both live. Code similarity alone did not explain who got flagged; the numbers are in the iPhone app cost article. My read, labelled as a read: 11 single-purpose utilities from one new account, submitted the same morning, look like an app factory from the queue no matter how different the screens are. If you have several small app ideas, ship one, let it collect reviews and updates, and space out the rest, or fold them into one app with in-app purchases, which is exactly what guideline 4.3(a) suggests.

The whole calendar in one picture

Seen as a calendar, the pattern is obvious. The first two weeks are short red bars (fast 2.1 questions) followed by green bars of two to five days. From September 26 on, the account splits in two: apps that were already live get updates through in about 64 hours, while the 11 new utilities sit in two long red bars that end in the same 30-second window each time.

After approval: live in minutes

The email says "it can take up to 24 hours" for an approved item to show up. For my 8 live apps, the public release timestamp came much faster. I read it from Apple's own iTunes Search API, which returns a currentVersionReleaseDate for every app a developer has on the store:

# every app on the account, with the release time of its current version
curl -s "https://itunes.apple.com/lookup?id=6810582483&entity=software&country=us"

Against the approval emails, that release time landed 0.7 to 7.5 minutes after approval, median 2.5 minutes, for all 8 apps. If your launch date matters (press, an ad campaign, a Product Hunt slot), choose a manual release so an approval at 2 AM does not go live before your announcement.

While you wait, you will want the state without opening App Store Connect. This is the status check every one of my app repos carries; it asks the App Store Connect API for the last five versions and builds:

# chain/Store/asc.py
def status():
    app = find_app()
    if not app:
        print("no app record for", BUNDLE_ID)
        return
    print(f"{app['attributes']['name']}  ({BUNDLE_ID})  id={app['id']}")
    versions = call(
        "GET", f"/v1/apps/{app['id']}/appStoreVersions", params={"limit": 5}
    )
    for v in (versions or {}).get("data", []):
        a = v["attributes"]
        print(f"  version {a.get('versionString')}: {a.get('appStoreState')}")

The submission itself is one fastlane call at the end of a CI job, using upload_to_app_store. The three submission_information answers matter more than they look: they are the export compliance, advertising identifier and content rights questions, and answering them in code means a submission never stalls waiting for someone to click through a form.

# chain/fastlane/Fastfile, lane :release (trimmed)
upload_to_app_store(
  api_key: asc_key,
  app_identifier: APP_IDENTIFIER,
  ipa: "build/Chain.ipa",
  # Submit, rather than leaving it sitting in Connect for a human to press
  # the button on. This is the last step and it is the irreversible one.
  submit_for_review: true,
  force: true,
  precheck_include_in_app_purchases: false,
  submission_information: {
    add_id_info_uses_idfa: false,
    export_compliance_uses_encryption: false,
    content_rights_contains_third_party_content: false
  }
)

Does App Store review work on weekends?

Partly. Four of my 64 decisions came on a Sunday, Pacific time: Pocket Beings' first approval at 4:05 PM on September 20, and three on the evening of October 11 (two 1.2 updates sent back, Chain 1.2 approved at 10:42 PM). None came on a Saturday. The 19 submissions I made on Saturday, September 26 were all decided on Monday night or later, and the five updates I sent on Thursday, October 8 came back Sunday evening and early Monday. If you can choose, submit Monday to Wednesday; anything sent Thursday or later, assume it lands after the weekend.

What I would do in your project

1. Plan in rounds, not days. One round is about 3 days for an update and 2 to 5 for a new app. A new app on a new account needs two rounds: budget a working week from first submit to approval.
2. Write the review notes like a test script. Login (or "no login"), where every paid screen is, how to trigger the edge cases, what data you collect. Attach a screen recording to the first submission so 2.1 has nothing to ask.
3. Check your privacy policy URL loads before every submission. One dead link cost me a full round.
4. Ship in-app purchases separately when speed matters. 12 hours, 5 of 5 approved.
5. Treat a review over 5 days as a warning. Prepare answers to the nine 4.3 questions before you need them.
6. When Apple says reply, do not resubmit. A resubmission without changes bought me another identical rejection, seven days later to the hour.
7. Fix and resubmit fast when the issue is concrete. Minder's broken privacy link: resubmitted in 6 minutes, approved in 25 hours.
8. Need it sooner? Apple has an expedited review request for critical bug fixes and time-sensitive events. I have not used it, so I have no number for it.
9. Measure your own. Run the same Gmail query on your account. Ten minutes gives you your real review calendar, which beats any average, including this one.

The data, and how to rerun it

Everything is in one folder: emails.py (the 64 rows transcribed from the emails, with the Gmail query and pull time), analyze.py (medians, buckets, batches, approval-to-live lag), summary.json (every computed number in this article) and make_charts.py (the charts). Pulled October 17, 2026 around 10:15 PM Eastern; the iTunes lookup ran at about 10:20 PM. Apple's claim was read from developer.apple.com/distribute/app-review the same night, and the submission flow is described in Apple's Submit for review help page. One developer account, 21 apps, five weeks: a small sample, but a complete one, and the only kind of review-time data you can actually verify.

If you are building on Windows and want the same pipeline (cloud builds, signing, screenshots, fastlane submission, the review notes template) set up on your own repo, that is the No-Mac iOS Pipeline, $299: your first TestFlight build from a Windows PC in 5 business days. If you would rather hand over the whole app, fixed-price builds are on /build/.