Why is my app stuck on Waiting for Review on App Store Connect?

If you searched for this article, your build is probably sitting on Waiting for Review in App Store Connect right now, and the last thread you read on the Apple Developer Forums was someone else asking the same question. The status is genuinely vague, the wait is genuinely longer in 2026 than it was a year ago, and Apple publishes very little about what is happening on the other side. The good news: most stuck builds are not flagged for anything. They are queue.

Short answer

Waiting for Review means Apple has accepted your submission and no reviewer has picked it up yet, per Apple's App Store Connect status reference. The status itself does not indicate a problem. As of May 2026, Runway's live App Store review times tracker shows a Waiting for Review average near ten hours, with In Review running under two hours, but the variance is wide and developers on the Apple Developer Forums regularly report stretches of two to three weeks. The honest answer is: most apps clear within a day, some sit for a fortnight, and you usually cannot tell which group you are in from inside App Store Connect.

What you should know

• Waiting for Review is queue time, not investigation time. Per Apple, it means received and not yet started. There is no human looking at your build during this status.
• In Review is the working status. When it flips to In Review, an actual reviewer has the build. That step is short, often under two hours on Runway's tracker.
• 2026 has more submissions than 2025. Appfigures reported Q1 2026 app releases up roughly 60 percent worldwide and about 80 percent on iOS, largely because AI coding tools generate more submissions per developer.
• Removing and resubmitting puts you at the back of the queue. Apple's documentation is explicit that the review process starts over.
• Expedited Review is rationed. Apple grants a small annual count per developer and reserves it for security patches or critical user-facing regressions.
• The status will not tell you why you are slow. App Store Connect surfaces the state, not the reason. The Apple Developer Forums and the Runway dashboard are the two best external signals.

What does Waiting for Review actually mean inside App Store Connect?

Apple's own reference page is unusually plain about this. The App and submission statuses page defines Waiting for Review as: you submitted a new app or updated version, Apple received your submission, and review has not started. Nothing more. Apple does not publish a target time for this status, and there is no documented service level for queue length.

While in Waiting for Review you can still edit certain app information, delete app previews, and remove the build from review. You cannot upload or edit screenshots or app previews. The next state in the flow is In Review, which is when a reviewer is actually looking at your binary. After that the path forks: Pending Developer Release if you chose manual release, Ready for Distribution if you chose automatic, or one of the rejection or metadata rejection states if something failed.

The practical consequence for a developer staring at the dashboard at midnight: there is no progress bar inside this state. You either sit and wait, or you do something deliberate (resubmit, expedite, contact Apple) that resets or changes the queue position.

How long should Waiting for Review actually take in 2026?

The public benchmark is the Runway App Store review times tracker, which aggregates real submissions rather than crowdsourced estimates. Recent figures pulled in May 2026:

The gap between the average and the tail is the part most developers do not see until they hit it. Threads on the Apple Developer Forums about unusually long Waiting for Review times collected dozens of February 2026 submissions stuck for ten to thirty days, and Apple Review eventually replied that the issue had been resolved, although several developers pushed back that their builds were still queued. This is the pattern: a calm baseline, periodic backlog windows, and very little visibility from inside the dashboard.

For planning purposes, treat 24 to 72 hours as the realistic upper bound under normal conditions, and treat anything past seven calendar days as backlog territory worth investigating.

Why are Waiting for Review queues longer in 2026 than they were a year ago?

The most cited explanation is volume. Worldwide app releases in Q1 2026 were reported up roughly 60 percent year over year and about 80 percent on iOS, driven mostly by AI coding tools producing more submissions per developer than the previous baseline. Apple's reviewer headcount did not scale at the same rate.

Layered on top of that are predictable events. Major iOS releases compress the queue every September. Holiday code freezes push submissions into late November. Policy enforcement waves (such as Privacy Manifests in 2024 and 2025, or the Required Reason API audits that ran through 2025) pull human reviewers off the standard queue. None of these are documented as queue-pausing events by Apple, but they show up in the Runway data and in forum threads as wider variance.

The inferred part of this picture is what Apple's internal triage does. Developers have observed that some builds appear to be sampled for deeper static analysis before a reviewer is assigned, and that builds with new SDKs or major binary size changes appear to sit longer in Waiting for Review. Apple does not document this, so treat it as directional. Two practical implications: keep binary diffs small between submissions when you can, and avoid introducing new SDKs into the same release that ships a major feature.

When should I remove the submission and resubmit?

The documented mechanic, per Apple's guide on removing a submission from review, is that you can pull a submission while it sits in Waiting for Review, In Review, or several post-review pending states. Doing so changes the status to Developer Rejected. If you resubmit, the review starts over from the beginning, and any items already marked as Accepted have to be resubmitted.

The honest threshold is around seven calendar days for most apps. Before then, the cost of resetting (back of the queue, full restart) usually outweighs the benefit. After seven days, the math flips: a fresh submission stands a reasonable chance of being picked up before the original one would have been, especially if a backlog window is closing. The pattern reported in February 2026 threads is that developers who pulled and resubmitted around day ten often saw the new submission move to In Review within a day or two.

A few cautions. Do not increment the version number unless you actually changed something, since Apple may flag it as a no-op submission. Do not pull a TestFlight build that has already gone through Beta App Review just because the App Store submission is slow, since they are independent queues. Do not chain three pulls in a row hoping for a faster lane; reviewers can see prior Developer Rejected entries on the same record.

How do I escalate without burning my expedited review quota?

Expedited Review is the right escalation for a real emergency. The qualifying cases Apple has historically accepted are: a critical security vulnerability in shipped code, a regression that breaks a major user flow for paying users, or a time-sensitive event tied to a specific calendar date that you can document. The official channel is the Apple Contact Us form under the App Store category, with Expedited Review as the topic. You will need to describe the issue in concrete terms and explain why a normal review window would cause meaningful harm.

For non-emergency queue questions, the better escalation order is: post on the Apple Developer Forums under App Review to see whether others are in the same backlog window, then use the Contact App Review form with a description of the queue time and your specific case. Generic patience requests rarely move builds. Specific notes (this is a security patch for a known CVE, paying users cannot complete checkout) do move them when the case is real.

For builders shipping AI-coded or no-code apps, where reviewer scrutiny tends to be higher, a calm pre-submission scan can shorten the round trip in a different way. Once a build passes Waiting for Review and reaches In Review, the most common rejection vectors are Guideline 5.1.1 privacy issues, hardcoded credentials, and missing Privacy Manifests. For an automated read of those before submission, PTKD.com (https://ptkd.com) is one of the platforms focused on scanning compiled APK, AAB, and IPA files against OWASP MASVS controls before they enter the App Review queue.

What to watch out for

• The status does not refresh in real time. App Store Connect can lag by minutes to hours behind the internal queue. Checking every fifteen minutes adds nothing.
• Email notifications are not always sent on state changes. Some developers report only seeing the move to In Review in the dashboard, with no email until a rejection or approval. Do not rely on inbox silence as a signal.
• Pulling and resubmitting too often can pattern-match as evasion. Repeated Developer Rejected entries on the same record may slow the next pickup. Use the lever sparingly.
• Beta App Review and App Review are different queues. A fast TestFlight approval does not predict App Store speed. Treat them as independent.
• The myth that contacting Apple resets the queue. It does not. Contacting App Review can clarify a stuck case, but it does not put you ahead of other submissions, and the Apple staff replies in forum threads are consistent about this.
• The myth that uploading at a specific time of day helps. Apple's review team is distributed across time zones. There is no documented quiet window. Uploading at 02:00 local time does not buy a faster pickup.

Key takeaways

• Waiting for Review is queue time. Most builds clear within a day, but 2026 variance is wide, and a two-week tail is real during backlog windows.
• Use Runway's live tracker and the Apple Developer Forums to calibrate. The status inside App Store Connect will not tell you whether you are average or stuck.
• Wait at least seven calendar days before pulling and resubmitting, and do not chain pulls. Apple's documentation is explicit that resubmission restarts the review.
• Save Expedited Review for genuine security or regression incidents. The quota is small, and the framing of the request determines whether it gets accepted.
• For pre-submission confidence on a compiled build, some teams scan APK, AAB, or IPA against OWASP MASVS controls using platforms such as PTKD.com (https://ptkd.com) so that when In Review begins, the most common rejection vectors are already cleared.