URL Filters not activating on iOS 27 beta

The issue appears to be an OS-level provisioning bug with how Apple's internal Privacy Proxy handles production bundle identifiers.

• Apple's CipherML is trying to route PIR token requests through a Privacy Proxy. In the beta, the App Store (production) build fails the ⁠NEMembershipChecker⁠ (Code 3). Because the membership check fails, the proxy isn't provisioned. Since CipherML is designed to "fail closed" if a proxy can't be established, the connection drops entirely, resulting in your ⁠-1009 Offline⁠ error and the ⁠_NSURLErrorPrivacyProxyFailureKey=true⁠ flag.
• Dev-signed builds route to a proxy, so that's why Xcode works.
• When a VPN is active, iOS bypasses internal system Privacy Proxies to avoid tunnel-in-tunnel conflicts. That's why VPNs work.

If you haven't already, install the VPN (NetworkExtension) debug profile on your test device. This will un-redact the ⁠com.apple.CipherML Code 1800⁠ errors in the macOS Console and should explicitly confirm the proxy provisioning failure.

Update your Feedback/Radar ticket to highlight that ⁠NEMembershipChecker⁠ Code 3 is failing specifically for production-signed profiles, causing CipherML to fail closed on the privacy proxy.

Also, if the ⁠NEURLFilterManager⁠ or PIR configuration APIs allow it, see if there is a temporary parameter to set the proxy behavior to "fail open" (direct connection fallback) for the duration of the beta cycle.

If you haven't already, install the VPN (NetworkExtension) debug profile on your test device. This will un-redact the ⁠com.apple.CipherML Code 1800⁠ errors in the macOS Console and should explicitly confirm the proxy provisioning failure.

I’m pretty sure I had this already, that’s how I was able to get the logs above. Maybe it’s a different profile that will un-redact them?

Update your Feedback/Radar ticket to highlight that ⁠NEMembershipChecker⁠ Code 3 is failing specifically for production-signed profiles, causing CipherML to fail closed on the privacy proxy.

It was already in there, but why not, done 😅

Also, if the ⁠NEURLFilterManager⁠ or PIR configuration APIs allow it, see if there is a temporary parameter to set the proxy behavior to "fail open" (direct connection fallback) for the duration of the beta cycle.

There is a “fail open/close” parameter but I think it means a different thing in this context. Fail open means that the URL Filter won’t block a load that gets caught by the local prefilter if the server can’t be consulted, fail closed means it will block it.

Seems like this was fixed in the backend a few days ago!

@KayleeSC is it fixed because I am facing the same issue for the Test Flight build on iOS 26.5.2

It’s fixed. You might be getting .serverSetupIncomplete, a looot of things can cause that, but you’re probably not getting the rest of the logs shown here.

@KayleeSC I am able to run the same configuration when running through xcode and my OHTTP entitlement is also approved by the apple. One thing are you using real bearer token while passing it to pirAuthenticationToken

@KayleeSC one more important thing

I got an approval for Network Extension but apple is mentioning about onboarding ** Your configuration [NE URL Filter] has been approved and is pending onboarding. It has passed all required validation and review steps and will proceed to the onboarding process.**

So does it take time to onboard and even if this onboarding is pending still we can distribute the app to the test flight ?

Until that process is complete you won’t be able to use the URL Filter on the App Store or TestFlight.

So you mean this approval mail is not the final status. Once onboarding is finished we will get another mail ? because while uploading the app to the Test Flight I did not get any error

See my respones on your specific thread.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"