App Review is running weeks behind for some developers: through late October 2026, threads on Apple's developer forums describe apps stuck in "Waiting for Review" for three weeks, a month, and in one reported case since 19 September. The delays are concentrated in first submissions of new apps and in resubmissions after a rejection; developers shipping routine updates to established apps are mostly still seeing the usual day or two.
The advice differs by queue. Here is what is documented, what developers report, and what can change your week.
First, separate the average from the tail
Per Apple's documentation: "App Review works around the clock with the goal of reviewing at least 50% of submissions in less than 24 hours and 90% in less than 48 hours."
That is a target, not a promise for your submission. The useful context came from Apple's response to MobileGamer.biz on 20 October: over the previous 12 weeks, App Review processed an average of 378,000 submissions per week, with an average review time of 1.5 days for all apps and 14 hours for minor updates. Apple also said some new apps take longer when they need additional scrutiny, and that it had prioritized updates to existing apps, expanded automation, strengthened abuse detection, and added safeguards against repeated submissions with the same unresolved issues.
An average of 1.5 days is compatible with a long tail of three-week waits. The Information's April report of an 84% year-on-year jump in submissions is repeated by both outlets; it is secondhand, not an Apple metric.
Developers report: "Reviews often take 3–5 days, even when expedited, while feedback is frequently vague and appears not to reflect our app descriptions or testing instructions," one studio boss told MobileGamer.biz. The Register collected forum posts titled "Stuck in Waiting for Review for about 3 weeks" and "Stuck in 'Waiting for Review' since October 8"; one developer said they had been waiting since 19 September. MobileGamer.biz also spoke to a studio with a five-year-old game that had seen no change in update review times. The pattern is new apps and post-rejection resubmissions, not routine updates.
Seven actions for this week
1. Classify your submission before you do anything else.
A first submission of a new app, an update to a live app, and a resubmission after a rejection are not the same queue in practice. The reported pain is in the first and third. If you are in the update queue and within 48 hours, wait; if you are a new app at day seven, start the escalation path below.
2. Do not resubmit just to bump the queue.
Per Apple's documentation, a resubmission starts a new review rather than moving the existing one up; in the Bug Fix flow it says: "Do not resubmit the app at this time, as it will trigger a new review." Apple also told MobileGamer.biz that it had added safeguards against repeated submissions with the same unresolved issues, which is a strong hint that churn does not help.
Developers report: uploading replacement builds while waiting can move you to the back of the line. Apple has not documented this; treat it as a risk. One submission, then use the documented channels.
3. Use expedited review only if you meet one of two conditions.
Per Apple's documentation, only submissions already sent to App Review can be expedited, and the request goes through "Request an Expedited App Review" with the app and platform selected. The eligible reasons are a critical bug fix or a release that must align with a dated event. For a bug, put the specifics in the Notes field; for an event, give the event, its date, and how the app relates to it.
Two constraints are easy to miss. Apple decides "as allowed by availability and demand", and it warns that "Expedite requests should be reserved for matters of genuine urgency." A request that says "we would like to launch sooner" is not one of the two categories.
4. If you were rejected, reply before you resubmit.
Per Apple's documentation, "Using App Store Connect to contact App Review is the best way to receive assistance with an ongoing submission", and a specialist familiar with your app will reply. Be specific about the feature, guideline, or step. Do not use this window to appeal or to request an expedited review; Apple says to use the appropriate Contact Us form for those.
A reply that tends to get a useful answer looks like this:
Build 1.4.2 (318) is the submission under review. The feature you flagged is at Settings > Export > CSV. Demo account: review@example.com. The backend flag export_v2 is enabled for that account. Attached are a 40-second screen recording and a point-by-point mapping to Guideline 2.1. Could you confirm whether this resolves the issue?
If you need a call, request it in the same window with your time zone and language. Apple says calls typically complete within three to five business days.
5. Check the rejection for the Bug Fix Submission offer.
Per Apple's documentation, if the message begins "Bug Fix Submissions: The issues we've identified below are eligible to be resolved on your next update", you can reply to accept the current submission and fix the issues next time. The same page is explicit: "Do not resubmit the app at this time, as it will trigger a new review." All deferred issues must be fixed in the next update, and the same issue cannot be deferred twice in a row.
This is the fastest documented path for a live app with a fixable metadata problem. It does not cover legal or safety issues, and it is not available for a first submission.
6. Appeal once, and only after clarification fails.
Per Apple's documentation, an appeal to the App Review Board is for three situations: you believe a rejected or removed app follows the guidelines; your account faces termination but you believe it complies; or you believe the review was unfair or biased. Reply first, then appeal if the clarification does not resolve it. Submit one appeal per app, address every cited violation in that one appeal, and note that the form accepts up to five apps. Do not use an appeal to ask for a status update, an expedite, or reinstatement of an already-terminated account.
7. Build the review packet now, not after the rejection.
The cheapest delay to remove is a reviewer having to guess. Put a demo account or demo mode, the exact path to each flagged feature, backend flags or regional dependencies, and a short screen recording in the Notes field before submission. If a feature needs a server state that is hard to reach, say how to reach it. It does not speed up the queue, but it can cut a rejection loop from three round-trips to one.
A five-day plan
Monday: classify the submission as new, update, or resubmission. Tuesday: rewrite the notes and record the demo path. Wednesday: submit the expedited request if you qualify, or send one precise reply. Thursday: fix what you can without a new build. Friday: reassess. One follow-up is reasonable; a daily ping is not.
What not to do
Do not file an appeal as a status check. Do not request an expedite without a critical bug or a dated event. Do not resubmit an unchanged binary and expect a different queue. Do not treat the 1.5-day average as a commitment. And do not assume "AI-generated" is a rejection reason: Apple says every app is held to the same standards; the backlog is about volume, not a ban.
None of this guarantees approval or shortens the queue. It keeps your submission from losing another week to a process mistake.
If you're already in a rejection loop, I packaged the 10-step 48-hour checklist and the two Resolution Center reply templates into one download. Get it here — App Store Rejection Response Kit — Free (free, email required).
A full checklist with source links is here: https://hhfa008.github.io/personal/app-store-rescue.html
Top comments (0)