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.

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.

Same boat, only worse. We submitted on 14 August — 15 days ago. We got rejected on the 22nd, fixed all four points the same night, and the resubmission has now been sitting in Waiting for Review for 7 days without anyone opening it. For what it's worth, we tried everything you did and none of it moved the needle: expedited review (confirmed, then nothing), a support case (six days for a reply saying "the review is proceeding normally"), a follow-up on that case (no answer, four days now), and an App Review appointment (declined). We have a global launch on 1 September. At this point we're almost certainly shipping without iOS and postponing it, with everything that implies — marketing, users we've told, the lot. Not great. So I don't have a fix for you, sorry. Just so you know 48 hours is not the ceiling and you probably shouldn't burn your expedite yet if you might need it later. Something broke around the 8 August maintenance and a lot of us have been stuck since.

Your app is indexed and searchable — but only in the US store. I checked with the public iTunes API just now: Searching "YouWorth" in the US store returns your app in position 1. A lookup by ID succeeds for country=us, but returns nothing for country=es or country=gb. So the app is only available in the United States. Anyone searching from another storefront will never see it, no matter what they type. If the people who "cannot find it" are outside the US, that is your answer — check Pricing and Availability in App Store Connect and confirm which countries are selected. Two other things worth knowing: Your original release date is 22 August, but version 1.1 went live on 29 August. Search indexing is not instant — it can take 24-48h after a new version — so if you tested right after that update, you may simply have looked too early. Your listing is English-only. That does not block search, but it limits how you rank on non-English terms in other storefronts if you expand later. You can verify any of this yourself without waiting: https://itunes.apple.com/lookup?id=6762416926&country=us versus the same URL with country=gb. If one returns a result and the other returns zero, it is availability, not indexing.

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 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. 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. 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. 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. 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?