App stuck in "Waiting for Review" for 7+ days — anyone else since the Aug 8 maintenance?

was working fine last week and I was getting review in less than 24h. Now I m stuck in review since 5 days... Expedited review but nothing changed.

Hi , Unfortunately, the queue is busy and everyone needs to be patient, especially for the initial release.

Update — 29 August. Day 14, still in "Waiting for Review". Answering my own questions in case it helps anyone else here, and adding what we have learned since. TIMELINE 14 Aug — 3.1.1 (170) submitted. First submission after transferring the app to our company account. 17 Aug — Expedited review requested. Got the "We'll expedite review" confirmation. Nothing moved. 18 Aug — Developer Support case opened after 93h waiting. 22 Aug, 19:05 — A reviewer finally opened the app. Eight days after submission. 22 Aug, 19:16 — Rejected on four guidelines: 2.3.6 (age rating), 5.1.1(ii) (purpose strings), 2.1 (questions about our contest), 1.2 (UGC safeguards). 22 Aug, 23:25 — All four addressed. New build uploaded the same night, with the screen recording they asked for attached to the review notes. 24 Aug, 17:29 — Support replied, six days after the case was opened: "the review is proceeding normally, there is no further action you need to take." 25 Aug — Requested a one-on-one App Review appointment. Declined. 26 Aug — Replied to the support case with the current status and our launch date. No answer, three days later. 29 Aug — Resubmission still in "Waiting for Review": 160 hours. 14 days since the original submission. ANSWERING MY OWN THREE QUESTIONS Was it the transfer? Apparently not. The rejection, when it finally came, had nothing to do with the transfer or with ITMS-90076 — it was ordinary guideline feedback. The transfer does not seem to have put us in a slower lane. Did the expedite help? No. Same as Owmince above: requested, confirmed, nothing changed. Same for the support case and for the appointment request. What eventually moved it? Nothing has, yet. FIVE THINGS WE LEARNED THAT MIGHT SAVE SOMEONE TIME

1. The resubmission clock resets, and the UI and the API disagree. When you attach a new build after a rejection, submittedDate in the App Store Connect API resets to that moment. Our App Store Connect page said "submitted 23 days ago" while the API said 2.
2. A rejection response does not appear to be fast-tracked. We assumed answering a rejection would go into a quicker lane than a new submission. Six and a half days in, that is clearly not happening.
3. Support cannot move the queue, and says so. Our case got a polite "proceeding normally" after six days, and the follow-up has had no reply at all. The case number is useful for the record, not for acceleration.
4. Phone support does not cover App Review. The contact options for "App Review Status" offer email only. Apple's telephone support page lists enrollment, membership, app submission and management — App Review is not on it.
5. You can see the reviewer from your own backend. Ours came from 17.234.96.115 — Apple owns the whole 17.0.0.0/8 block — geolocating to San Jose, and the session lasted a few minutes. If you log sessions server-side that tells you far more than the App Store Connect status does. It is also how I know nobody has opened our app since 22 August.

We reach our 1 September launch without the iOS build approved and with no way to test the released version with real users first. The version currently live is several releases behind and is missing security fixes that have been sitting in this queue for two weeks. Same genuine question as before: has anyone stuck since the 8 August maintenance actually been approved yet? If so, how long did it take, and did anything unblock it — or did it just eventually happen on its own?

has anyone stuck since the 8 August maintenance actually been approved yet?

There are many similar reports in the forums. Sometimes they do eventually get approved.

If so, how long did it take, and did anything unblock it — or did it just eventually happen on its own?

While there are many, virtually identical reports here in the forums, I can only remember a handful, maybe 3 or 4, that posted a followup saying they were eventually approved.

Update, day 16. Honestly? I'm running out of polite ways to describe this. After SEVEN days sitting in the queue, a reviewer finally opened our resubmission today. Total review time: a few minutes. Result: rejected. "The app launched to an indefinite and unresponsive black screen" on an iPad Air M3, screenshot attached. Except here is what our server logs say: ZERO requests from the review device. Not one packet ever reached us. The same build loads perfectly on our own iPads against production, right now. The reviewer's own screenshot shows a VPN icon in the status bar — our app uses certificate pinning, and any TLS-inspecting VPN kills every request at the client. The device could not reach the internet. The app was reviewed, and rejected, on a connection where no app that talks to a server could possibly work. Yes, part of this is on us and I'll own it: our splash sat there silently instead of saying "no connectivity". That is a real bug and we fixed it THE SAME DAY — visible notice, retry button, resubmitted this afternoon. That is not the part that makes me want to put my head through a wall. The part that does: there is no human being you can talk to. Seven days of silence, then minutes of review on a broken network, then a rejection letter, and now — what, another seven days? One message before rejecting — "hey, black screen on launch, anything on your side?" — costs a reviewer two minutes and would have saved BOTH of us a week. That conversation is simply not available while you sit in the queue. Expedited request: confirmed, then ignored. Support case: "proceeding normally, no action needed", six days later. An App Review appointment: declined. We have a public launch on September 1 and the only thing between us and it is a queue nobody can see into. We did everything you are supposed to do. Fixed every guideline point within hours, attached the demo video they asked for, answered every question in writing. It has not bought us a single day. For anyone else in this thread: if your app pins certificates, assume review happens behind a TLS-inspecting proxy and make absolutely sure your first screen SAYS SOMETHING without connectivity. A silent splash equals 2.1(a), full stop. And log everything server-side — our logs are the only reason we know the device never reached us, instead of chasing a crash that does not exist. Android: same build, submitted today, live within hours. No drama, no mystery, actual release notes. The contrast does itself.

our app uses certificate pinning, and any TLS-inspecting VPN kills every request at the client

Does it need to do that?

That is a real bug and we fixed it THE SAME DAY

The speed that you fix bugs has no bearing on app review timelines.

Furthermore, even if you did display an appropriate message, that doesn't necessarily mean Apple will accept it. For example, if your app isn't directly involved in some highly-secure, regulated industry, this could be seen as an attempt to evade app review.

there is no human being you can talk to

While Apple does now use AI for app reviews, there is always a human in the loop. You can reply to rejections and a human will see it. No guarantees about that human's workload and willingness to reply.

costs a reviewer two minutes and would have saved BOTH of us a week

Apple incurs no cost for app review delays. This would cost the reviewer two minutes. But it wouldn't necessarily save you a week. It definitely wouldn't save Apple any time.

Apple operates at scale. They review over 9 million submissions a year. That's 25,000 a day. Two minutes matters at that scale. So why should Apple spend any extra time on your app when there are so many other submissions that they might be able to review and approve while your next submission is sitting in the queue?

Android: same build, submitted today, live within hours. No drama, no mystery, actual release notes. The contrast does itself.

So why not abandon Apple and focus on Android? You and I both know the reason. That's the same reason for all the delays. Apple doesn't have any deadline.

Does it need to do that?

Yes. User accounts and paid subscriptions. Pinning is standard for that, and Apple ships a first-class API for it — NSPinnedDomains inside the ATS dictionary. Strange thing to be asked to justify.

The speed that you fix bugs has no bearing on app review timelines.

Correct, and that is the complaint rather than the boast. Fixing it in a day earns nothing. Waiting a week for the two-minute question that would have triggered the fix is the problem.

this could be seen as an attempt to evade app review

An offline notice is what Gmail, Instagram and Apple’s own apps show when the network dies. If "check your connection" counts as evading review, the whole store is evading review.

You can reply to rejections and a human will see it.

We tried all three doors. The App Review appointment was declined. The support case came back six days later with "proceeding normally, no action needed". And once you resubmit, the Reply box goes away with the old submission. A human exists. Reaching one is the part that does not work.

Two minutes matters at that scale. So why should Apple spend any extra time on your app?

Because those two minutes replace a second full review. You are arguing Apple should skip the cheap step in order to protect the expensive one. We are not asking for extra time, only for the same time spent in a different order.

So why not abandon Apple and focus on Android? You and I both know the reason. Apple doesn’t have any deadline.

We do both know it. That asymmetry is the argument for holding the process to a standard, not the excuse for it. "They have no deadline" explains the delay. It does not defend it.

For the record, since it is the only part of this anyone can actually verify: a reviewer ran the new build this afternoon. It started normally on their device and they browsed it for several minutes, with zero errors on our side. Which is roughly what week one should have looked like.

Yes. User accounts and paid subscriptions. Pinning is standard for that, and Apple ships a first-class API for it — NSPinnedDomains inside the ATS dictionary. Strange thing to be asked to justify.

Apple has many APIs that are inappropriate or impossible for the App Store. As I said, if this were a banking app or some highly regulated industry, then certificate pinning might be expected. But pretty much all apps these days have user accounts and subscriptions. Apple Developer support describes certificate pinning as a "two edged sword".

An offline notice is what Gmail, Instagram and Apple’s own apps show when the network dies. If "check your connection" counts as evading review, the whole store is evading review.

By your own admission, your app didn't do that. Apple itself isn't subject to App Review. Google and Meta are well-known, established developers.

For the record, since it is the only part of this anyone can actually verify: a reviewer ran the new build this afternoon. It started normally on their device and they browsed it for several minutes, with zero errors on our side. Which is roughly what week one should have looked like.

So the process is working and the review is making forward progress then.

Apple has many APIs that are inappropriate or impossible for the App Store.

NSPinnedDomains shipped with iOS 14, lives in the ATS dictionary and has its own documentation page. If a first-party API in the system configuration is inappropriate for the App Store, that seems worth someone at Apple knowing.

Apple Developer support describes certificate pinning as a "two edged sword"

They do, and the edge they describe is operational: rotate a certificate badly and you brick your own app. That is a maintenance warning, not a hint that it is forbidden. Ours pins to a CA bundle we control, for exactly that reason.

None of which was the rejection. We were cited under 2.1(a) for a black screen. Pinning is how the screen went black, not what we were cited for. You are arguing against a claim nobody made.

By your own admission, your app didn't do that.

Yes. I said so myself, in the post you are quoting, unprompted, and we shipped the fix the same day.

The complaint was never "we did nothing wrong". It is that we diagnosed it from the screenshot alone, in about two hours — and the round trip to obtain that screenshot took eight days. One sentence on day one, "black screen on launch", produces the same fix on day one.

Apple itself isn't subject to App Review. Google and Meta are well-known, established developers.

That is the clearest thing written in this thread, and it is not the defence you seem to think it is. Same behaviour, same guideline, different outcome depending on the name on the account.

So the process is working and the review is making forward progress then.

Day 17. The App Store submission is still Waiting for Review.

What did move today: two TestFlight builds approved, hours apart. Same binary, same certificate pinning, same everything — reviewed, passed, distributing. So the artefact was never the question. What we are waiting on is a queue, which is what I said on day seven.

NSPinnedDomains shipped with iOS 14, lives in the ATS dictionary and has its own documentation page. If a first-party API in the system configuration is inappropriate for the App Store, that seems worth someone at Apple knowing.

There are many developers who ship iOS apps not using the App Store. Originally, it was only enterprise developers doing this, but apparently, anyone in the EU can do that now.

Apple does not document which APIs work in the App Store and which do not. This is a much bigger problem for Mac apps, but it could happen on iOS too.

If you explain why you need this capability, and if it seems like you really do need it, and you gracefully handle a failure, then you may be able to use it. But it might also require a more thorough, and lengthy, review period.

Also note that when I say "explain", I mean explain to App Review. You're wasting your time trying to argue with me. I don't care. I'm just trying to give you another perspective.

What did move today: two TestFlight builds approved, hours apart. Same binary, same certificate pinning, same everything — reviewed, passed, distributing. So the artefact was never the question. What we are waiting on is a queue, which is what I said on day seven.

The perspective that I'm offering is someone who reads these forums on a regular basis.

I can tell you, with great confidence, that TestFlight is a different path. I can also tell you, with great confidence, that a 7 day app review delay is normal, and has always been normal. In today's AI slop world, some people are waiting weeks. And there does appear to be a correlation between rejections and very long wait times.

And here's another perspective I can offer. I've also read Apple's App Store Transparency reports.

The two most relevant data points are the number of submissions, the number of rejections, and the number of approvals after rejection. In 2025, Apple reviewed 9,100,620 submissions. 2,093,244 were rejected. That's 23%. 387,087 were approved after rejection. So if your app gets rejected, there's an 81.5% chance that it will not be approved.

So therefore, if you have 9 million submissions a year, or 25,000 a day, it makes sense to put any rejection onto a slow queue so that you can more quickly approve those 19,000 apps that don't have a problem.

As the numbers clearly show, getting approved after a rejection is possible, just not common. But if you are going to do it, you'll likely need more time.

So try to look at your app from a different perspective and don't give App Review any reason to reject it. That's a good use of your time, no arguing with people on the internet.

You're wasting your time trying to argue with me. I don't care. I'm just trying to give you another perspective.

Understood, and the perspective is useful — the correlation between rejections and long waits especially. That one I had not seen stated anywhere, so thanks.

One correction, though, because it will mislead whoever finds this thread later.

2,093,244 were rejected... 387,087 were approved after rejection. So if your app gets rejected, there's an 81.5% chance that it will not be approved.

The division is right. The two numbers just don't share a denominator.

Apple's own methodology note in that report says apps may be submitted to App Review multiple times before they are approved. So the rejection figure counts submission rejections, not distinct apps — one app rejected three times contributes three. Dividing an app-level outcome by an event-level count does not give you a per-app probability.

Two more things compress the numerator. "Approved after rejection" only counts approvals within the same reporting year — rejected in December, approved in January, and you disappear from it. And the largest rejection bucket by a distance is performance: crashes, broken flows and incomplete builds, over 1.2M of the 1.93M in the 2024 report. That bucket is mostly submissions nobody ever resubmits.

So 18.5% is the share of rejection events followed by an approval in the same calendar year. It is not the odds facing a maintained app that fixed the one thing it was told to fix. Those two statements are very far apart, and only one of them is in the report.

don't give App Review any reason to reject it

No disagreement there. We didn't argue the rejection either — the fix shipped the same day. This thread was about the eight days before it, not the rejection itself.