Quick update, September 29: still "Waiting for Review". It's been almost seven days since we submitted 3.3.7 on September 23, and nobody has opened it yet. We can see reviewer sessions on our own server, and there haven't been any on this version since the TestFlight build was approved on the 24th. No messages from App Review either. I'll keep this thread updated in case it helps anyone else stuck in the same spot.

Following up on my own thread with a bit more context. We do understand that App Review is under real pressure right now. Submission volume has grown a lot, AI-assisted development has multiplied the number of apps and updates being sent in every week, and we are well aware that reviewers are not sitting idle. A few days of delay is something we can plan around, and we would not complain about that. Seven days with no movement at all is a different matter. The hard part is not only the waiting. It is that after seven days the outcome could still be a rejection, and then the clock starts again from zero. That makes it impossible to plan a release, to tell our users anything, or to coordinate anything around it. The status has not changed once since September 12, and we have had no confirmation that the submission is queued, assigned, or being looked at. I will also be honest about something. This is not the first time we post here, and every time we have, things seemed to move sooner afterwards. I genuinely do not know whether that is cause or coincidence, and it may well be placebo on our side. But when a submission has been sitting for a week with no information at all, writing a post is the only thing left that costs nothing to try. I would much rather not need to. None of this would be necessary with a three or four day turnaround. That would be entirely reasonable, and this thread would not exist. If there is anything we can provide from our side to help, please let me know.

Andy, same situation here, and I am adding our numbers because I think they change what you should expect from the expedited request. NotBetting (Apple ID 6737483983), on the App Store since December 2024. We submitted on 4 September at 13:34 UTC. Seven days later it is still Waiting for Review and has never transitioned to In Review. No rejection, nothing in Resolution Center, no metadata flag. The part that matters for your launch: we already did what you are doing. We have an open Developer Support case, and on 3 September a support engineer told us they had escalated it to the review team on our behalf and that no further action was required from us. That was eight days ago. Nothing has happened since, and the review team has not contacted us. I am not saying yours will go the same way, but I would not plan a launch date on the assumption that the escalation moves it. One more data point that I think is the most revealing one. In the same period our TestFlight builds are being reviewed and approved normally, three of them in the last week, the most recent within hours. Apple reviewers are opening our app with the demo account almost daily and everything passes. So the app works, the credentials work, the builds get approved, and yet the App Store submission has not been picked up once. Whatever this is, it does not look like a problem with the apps themselves. Our store page is still serving a build from 26 June, 75 days ago, while our Android releases have shipped continuously in that time. Counting this thread there are now at least four open with the same symptom this week, and one of them has been stuck since 12 August. If anyone from App Review is reading these: the recurring request is not a faster review, it is a way to tell a normally queued submission apart from a stalled one, because from App Store Connect they look identical and they call for opposite decisions. Good luck with the launch today. If yours moves, please post what unblocked it.

Same here, and I think our case adds something useful to yours: we are not a new app. NotBetting (Apple ID 6737483983) has been on the App Store since December 2024. We submitted on September 4 at 13:34 UTC and we are still in Waiting for Review four days later. Like you, it has never transitioned to In Review, there is no rejection, nothing in Resolution Center, no metadata flag, and agreements and banking are complete. I mention the age of the account on purpose. Your submission is a first release, ours is an update to an app that has been through review many times. If both are sitting in the same state, whatever is happening is not specific to new apps. For context on what normal looks like for us: our last approved version went from submission to the store in about 26 hours, and our rejections in June and July all came back within 12 to 31 hours. So four days without even entering review is well outside our own history, not just outside the published averages. I am not asking to jump the queue either. What is genuinely hard to work with is the lack of a signal: Waiting for Review looks identical whether a submission is queued normally or stuck, so there is no way to tell whether to keep waiting or to withdraw and resubmit. Withdrawing has a real cost since it puts you at the back of the queue, and doing it on a hunch is a bad trade. If anyone from App Review is reading: some way to tell "queued, this is normal" apart from "something went wrong with this submission" would save developers a lot of guesswork. Even an acknowledgement that the submission was picked up would be enough.

Before the 5.4 questions, one thing about the plan itself, because it may make both of them moot. To detect adult sites outside Safari, I plan to use a NEPacketTunnelProvider that runs entirely on the device: it inspects the SNI locally NEPacketTunnelProvider works at the IP layer. It does not receive flow or application-level metadata, which is exactly what content filtering needs — Apple's own guidance on this is blunt: if your goal is to filter content, use the Content Filter API, not a packet tunnel. SNI inspection also stops working the moment Encrypted Client Hello is in play, and that is not a hypothetical any more. You already hold Family Controls (Distribution), and that is the shorter road. With .individual authorization: ManagedSettingsStore().webContent.blockedByFilter = .auto() That applies Apple's own adult-content classifier system-wide — every browser, not just Safari — with no tunnel, no VPN profile, no network extension, and therefore no Guideline 5.4 at all. For a self-control app aimed at exactly this category of site, it is the intended mechanism. Two things worth knowing before you rely on it. .specific(...) domain lists cap out around 49 entries and blocking silently stops past that — undocumented, and people keep rediscovering it. And if you genuinely need URL-level rather than domain-level decisions, the modern sanctioned path is NEURLFilter (iOS 26, introduced at WWDC25), which is a content filter, not a VPN — different framework, different review conversation. Now the two questions. Does the requirement that an app "may only be offered by developers enrolled as an organization" apply to a content blocking app of this kind? Read literally, no: that sentence is scoped to "apps offering VPN services", and parental control, content blocking and security apps appear in a separate sentence. Read practically, it does not help you, because a NEPacketTunnelProvider installs a VPN configuration and puts the VPN badge in the status bar. To App Review, that is an app offering a VPN, regardless of whether a single packet leaves the device. The "it never routes traffic anywhere" argument is true and largely irrelevant to how the submission is read. What is an "approved provider" in the sense of Guideline 5.4? There is no definition, no form, and no entitlement by that name — you are not missing a page. The nearest concrete gate is the Network Extension capability, and since 2016 Packet Tunnel, App Proxy, Content Filter and DNS Proxy are self-serve: you enable them in Xcode, no request. Only Hotspot Helper and the NE app push provider are still requested. So "approved provider" is not a programme you can apply to in advance; it is App Review's judgement at submission, which is precisely the uncertainty you were trying to avoid by asking first. Which is the strongest argument for the Screen Time route: it removes the question instead of answering it.

adding any build to an external testing group fails at both steps of the dialog with "There was an error processing your request. Please try again later." That line is the diagnosis, and I think it is more useful than the install failure. Those two symptoms together — internal installs dying at Error Downloading Install Data, and external groups refusing builds with a generic error — are the known signature of the TestFlight beta contract getting detached from the account on Apple's backend. It is not your signing chain, and your own evidence already rules that out better than any checklist: two app records, two bundle IDs, two accounts, fresh certificates and profiles, and another developer's beta installing on the same device. There is a long-running thread on it: https://developer.apple.com/forums/thread/814565 — going since February, around 30 developers, all of them with agreements showing Active and nothing pending. The contract is read-only from outside; you cannot repair it yourself. Confirm it in one request. The web UI hides the real error behind "try again later". The API does not. Try adding the build to the external group, or creating the beta review submission, through the App Store Connect API instead: POST /v1/betaAppReviewSubmissions with the build id, or POST /v1/betaGroups/{id}/relationships/builds If it comes back 422 ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING, that is it, and you now have a concrete error string to put in front of support instead of a screenshot of a generic dialog. Every thread I can find on the visible symptom ends with the developer being directed to Developer Technical Support, and no fix recorded. One route has a recorded fix, and it is not the support email: Feedback Assistant, with a HAR capture of the failing request including response headers, plus every affected App ID. Reported resolution in a couple of days. The email path is where these go to die — DTS cannot re-provision a contract either, which is why those threads all end the same way. Ask for it in those words: re-provision / re-attach the TestFlight beta contract on the backend. A DTS engineer confirmed in that thread that this is how it gets fixed, and that you should upload a fresh build about 48 hours after — expired builds do not come back. Worth knowing before you celebrate: it has recurred for several people days or weeks later, so keep the case number. And thanks for posting the Ad Hoc plus ideviceinstaller workaround. That is the part most of these threads are missing.

23 July 2026 — after that submission showed no movement, I removed it and submitted a fresh build of the same version. That is the part I would flag first, because it is not neutral. Apple's own help page for removing a submission says the status becomes Developer Rejected and "if you resubmit the review process will start over." So this is not two clean submissions stalling identically. The second one started from zero on 23 July. Your real queue time is the 38 days; the five weeks before it were spent and then discarded. Whatever else you do, do not remove this one. One thing worth checking that is not on your list: how many items your submission contains. A review submission is not just the app version. In-app purchases, subscriptions, in-app events and asset packs ride in the same submission, and App Review has to accept all of them for it to complete. An incomplete subscription will hold the entire submission without ever producing a Resolution Center message — which matches your symptoms exactly: no message, no action-required banner, no pickup. You can look without touching anything: GET /v1/apps/{APP_ID}/reviewSubmissions?filter[state]=WAITING_FOR_REVIEW&include=items If items comes back with anything besides the app version, that is your first suspect. We hit the mirror image of this recently — an incomplete subscription blocking a group submission, no message anywhere, just silence. For context on the queue itself: there are several threads this month reporting 6 to 10 days since mid-August, so the backlog is real. 38 days is well past it, though. Two smaller things. @Apple does not route anywhere from here. This is a peer forum and App Review does not read it. The DTS engineers do, but they cannot move a submission. And on the case you opened: the pattern people report is that a reply from Developer Support correlates with movement, and that the web form is slow to produce one. The one channel with actual reports of shifting a stuck submission is requesting a phone callback during business hours and asking them to look at that submission specifically. Plenty of people report the opposite, so no promises — but it is the only route I have seen work more than once.

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.

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.

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.

Expedited review request refused by the form with "You don't have a submission in review" (the submission is in "Unresolved Issues" status) That line is the one I would look at. While the item sits in Unresolved Issues it genuinely is not in review — so the expedited form has nothing to attach itself to, and it may also mean nobody is assigned to your app right now. So worth checking in App Store Connect: does the rejected item still say Unresolved Issues? A Resolution Center reply on its own may not be putting you back in the queue. What re-queued ours was the web flow: open the version, use the control that flips the item back to Ready for Review ("Update Review"), then hit Resubmit to App Review at the top. Until that second button, nothing moves. We just came out of sixteen days of silence ourselves, so you have my sympathy. In our case the resubmit was the only thing that changed anything. One thing that cost me half a day: the App Store Connect API returns 409 on everything while a submission is in Unresolved Issues — you cannot script your way out of it, it has to be the web UI.

Romanian number is a red herring, I think. Same failure is all over these forums with +51 Peru, +55 Brazil, UK and Dutch landlines, Canadian business lines — going back to April 2024. The one that gives it away is the call option: it rings, connects, and hangs up without ever reading a code. That's not your SIM. First thing — stop retrying. You're rate limited now, every new attempt seems to push the window out, and people who asked support to reset that counter were told they can't. The thing that actually worked for someone stuck exactly like you (thread https://developer.apple.com/forums/thread/759771) was phone support. Not the email form, not the web case — request a callback from Developer Support during business hours and have them verify the trader info on their end. That got sorted in a day after the email route went nowhere for weeks. Worth quoting at them when you get through: Apple's own help page for DSA trader requirements says "If you're using a phone number that can't receive two-factor authentication codes, you can request manual verification." Nobody in these threads could find that option in the UI, so you kind of have to make support do it. And a 10-second check since it costs nothing: Romanian mobiles go in as +40 7XX XXX XXX with the national leading zero dropped. If there's a 0 after the +40 it fails silently every time.

This one isn't on your side. There's a long-running thread on exactly this error going since February — https://developer.apple.com/forums/thread/814565 — around 30 devs in it, and every single one had all agreements showing Active, banking fine, nothing pending. Same as you. What's actually breaking is the internal TestFlight beta contract getting detached from the account on Apple's backend, which is why checking the Agreements page fixes nothing. It can't be repaired through the API either. The only thing that's worked for people: a case with Developer Account Support (developer.apple.com/contact) asking them, in those words, to re-provision / re-attach the TestFlight beta contract on the backend. A DTS engineer in that thread confirmed that's how they fix it, and said to upload a fresh build about 48 hours after — already-expired builds don't come back, which matches what you're seeing. Since this is your third round: if you still have the old case number, reopen that same case and tell them it's recurring. That tends to get it escalated instead of starting over with a new agent. And link them to that thread so they can see it's systemic, not your account.

Good news — I just checked with the public iTunes search API and your problem appears to have resolved itself while you were waiting. Searching "RemiMinderAI" in the US store now returns your app in position 1. Same for "RemiMinder" and "remi minder". A lookup by your app ID also succeeds in the US, UK, Germany, Spain and Turkey storefronts, so availability looks fine everywhere I tried. What you ran into is the indexing gap: "Ready for Distribution" means the listing is live (direct link works immediately), but the search index is a separate system that can take anywhere from a few hours to ~72h to pick up a brand-new app. Your release date shows August 23 and your post is from yesterday — classic timing. Nothing was broken, it just had not propagated yet. About the missing release button in your title: if your version was set to automatic release after approval, there is no button to press — it releases itself, which matches what you saw. For next time, you can check this yourself in seconds instead of waiting for answers: https://itunes.apple.com/search?term=YOUR+APP+NAME&country=us&entity=software — if your trackId is in the response, you are indexed and any remaining issue is ranking, not indexing. Give it a search now on a device — you should find it.

I checked your listing with the public iTunes search API just now, so here is what is actually happening rather than a guess. Good news first: your app is indexed fine. Searching "outmark" in the US store returns it in position 1. So nothing is broken. The problem is ranking, not indexing. I ran the generic terms for your niche — "hunting map", "gps hunting", "hunting app", "deer hunting map", "hunt gps" — and you are not in the top 50 for any of them. Those terms return 40-50 results each, and the top spots are held by apps with years of downloads and tens of thousands of ratings. Your app is 10 days old with 4 ratings. The search algorithm weighs downloads, ratings and engagement heavily, so a brand-new app simply does not surface for competitive terms yet, no matter how relevant it is. Two weeks is nothing on that clock. What actually moves it, from having gone through this ourselves: Make sure the 100-character keyword field in App Store Connect is completely full, and spend it on long-tail terms you can actually win ("deer stand marker", "hunting waypoints", that kind of thing) instead of "hunting app", which you will not crack for months. Your subtitle repeats words already in your title. Words in the title and subtitle are the strongest ranking signal you control — do not waste the subtitle duplicating them, use it for a second set of terms. Ask for ratings in-app (SKStoreReviewController) at a happy moment. Volume of ratings is a ranking input, and 4 vs 100 is a different league for the algorithm. If you can spare even a tiny budget, Apple Search Ads on your own niche terms does two things: instant visibility while organic catches up, and real data on which terms actually convert — which then tells you what to put in the keyword field. You can verify all of this yourself without waiting for anyone: https://itunes.apple.com/search?term=YOUR+TERM&country=us&entity=software — if your trackId is in the results, you are indexed and it is a ranking problem; if it is not there at all for your exact name, then something is actually broken. Hang in there. The exact-name-only phase is normal for week two.