App Stuck in Waiting for Review: What Developers Found Works

Apple says most submissions are reviewed within a day or two, yet "stuck in Waiting for Review" has been one of the most-posted complaints in iOS developer communities throughout 2026. This guide collects what developers on r/iOSProgramming, r/iosdev, r/AppStore and the Apple Developer Forums reported from late 2025 to October 2026, and separates what repeatedly worked from folklore.

What developers are asking

The same handful of questions come up week after week:

• Is a wait of 5, 9 or 14 days normal, or is something wrong with my submission? ^4,6,12
• Does a first-ever app wait longer than an update, and does a new developer account make it worse? ^2,3,6
• Should I pull the build and resubmit, or will that send me to the back of the queue? ^2,4,10
• When is it acceptable to request an expedited review, and can asking too often hurt me? ^7,8
• What does it mean when the status flips to In Review and then sits there for a day or more? ¹¹
• If I replied to a rejection in the Resolution Center, is anyone reading it, and why does the status stay "Rejected"? ¹⁰
• My app was approved but my subscriptions are still Waiting for Review. What now? ¹⁶

Typical times in 2026, measured rather than promised

Apple's published target, as of October 2026, is that at least 50% of submissions get a decision within 24 hours and 90% within 48 hours ¹. Developer-collected data is more sobering.

A solo developer who exported the App Store Connect activity log for 43 apps and 291 review cycles (July 2024 to September 2026) found that 71% of submissions entered review within 24 hours and another 18% within 48 hours, with a worst case of 10 days. In that dataset a brand-new app did not wait meaningfully longer than an update (typical 18 hours versus 16 hours), submissions made on a Friday took about 2.5 times longer to enter review than Wednesday ones, and the actual In Review phase had a median of just over an hour ².

A separate log of 64 decisions across 21 apps in September and October 2026 paints a slower picture: a median of 73 hours from submission to decision, with only 27% of decisions inside 48 hours, and none of the 21 new apps approved on first submission ¹⁴. A 15-year App Store veteran reported that updates to existing apps still clear in hours, while his three new apps in the past year took a week, a week and 19 days respectively ³.

The community's summary: updates are usually fast, new apps on new accounts are the slow lane, and July to October 2026 was visibly congested ^3,5,6. Threads blame a flood of AI-generated submissions and October's new Xcode and device launches; both are plausible but unconfirmed unconfirmed ^5,6.

What the status changes actually mean

"Waiting for Review" is the queue: no human has looked at the build yet. "In Review" means a reviewer has picked it up; in the 291-cycle dataset that phase typically ended within one to three hours, though outliers of a day or more exist, especially for Mac builds and apps with unusual entitlements ^2,11.

After a rejection, the version shows "Rejected" and stays there even after you reply in the Resolution Center. Developers found this confusing because there is no queue position and no acknowledgement. Multiple reports say replies are read and can result in approval without a new build, often within a day or two, but you will get no signal until it happens ¹⁰.

In-app purchases and subscriptions are reviewed as separate items. If they were not attached to the version you submitted, the app can go live with no products available. The fix reported in community threads is to attach them to the next version submission and, if already live, ship a small update with the products attached ¹⁶.

When to request expedited review

Apple reserves expedited review for critical bug fixes and time-sensitive events, and says it may not grant repeated requests ^1,15. Community experience is split, so it pays to separate the cases.

For an update to an app that is already live, especially a fix for a real bug, expedited requests have an excellent track record: multiple developers report approval within 30 minutes to a few hours after days of silence ^4,5,8. One developer whose rebuilt app had sat for 17 days after a spam rejection requested expedited review and was approved the next morning ¹⁷.

For a first submission of a new app, results are far worse. Several developers reported that expedited requests were acknowledged but produced no visible movement for a week or more, and one Apple Developer Forums poster waited more than 20 days with an expedited request pending ^9,12,13.

Two details that developers learned the hard way: if a build in the expedited queue is rejected, the resubmission keeps its expedited status automatically, so you should not file a second request for the same submission ⁷. And if you withdraw the submission yourself, the expedited flag is lost and must be requested again ⁷. Claims that over-using the form gets an account blacklisted circulate widely, but nobody in the threads could cite an Apple source for that unconfirmed ⁸.

What developers say actually helped

• Leave the submission alone. The strongest finding in the 291-cycle data is that pulling your own build and resubmitting cost more queue time than being rejected by Apple did; the author now treats a build in Waiting for Review as immutable unless the bug is truly blocking ².
• Reply, do not resubmit, when you are only clarifying. Resubmitting restarts the queue with possibly a different reviewer; a reply stays attached to the existing case and several developers got approvals from a reply alone ¹⁰.
• Open a Developer Support case or request a callback. Support cannot approve apps, but several developers reported that a build moved within hours of a support contact, including one whose app had waited 10 days ^9,11. Others got only templated replies, so treat this as cheap to try rather than reliable ^12,13.
• Fill in App Review Notes like a checklist: demo credentials, where sensitive features live, why each permission is needed, and a short screen recording. Developers consistently credit this with fewer "Information Needed" round trips, which are the most common reason a new app loops back into the queue ^3,14.
• Submit early in the week if timing matters to you; one dataset found Friday submissions waited the longest ².

What did not help

Repeatedly emailing or calling did not reliably change anything, and Apple's forum replies are templated "we are investigating" messages ¹³. A second expedited request on the same submission does nothing ⁷. Resubmitting the same build to "retry" resets your place in line ^2,10. Cancelling a submission already In Review was the most expensive mistake in the measured data ².

How this shows up in the charts

Review queues shape the top charts more than most people realise. A launch that slips a week loses the press, newsletters and social posts timed for day one, and those first 48 hours of downloads are what push a new app into category rankings. The 2026 threads describe exactly this: a couples app missing Valentine's Day, games live on Google Play weeks before the App Store, and marketing campaigns paused mid-flight ^5,6.

On the AppWinners rankings you can sometimes see the effect directly: an app entering a Top Free or Top Paid chart weeks after its Android version appeared, or an established app's update cadence stalling for a month while competitors ship weekly. It is also why developers timing a chart push for a seasonal event submit two to three weeks ahead, hold the approved build with manual release, and save expedited review for a genuine fix.

A short playbook

Submit midweek with complete reviewer notes and a demo video, and do not touch the submission while it waits. For a live app with a real bug, use the expedited form once. For a new app with no movement after about a week, open a Developer Support case and keep replying in the existing thread rather than uploading new builds. Most "stuck" apps on Reddit were approved, just later than their developers had planned for.