NEFilterDataProvider activation on consumer iOS — saveToPreferences fails (code 5), .mobileconfig requires MDM

Question

Created 17h

Replies 2

Boosts 0

Participants 2

Hello,

I'm developing a gambling blocker app that uses NEFilterDataProvider. My app was approved on the App Store, but the core feature doesn't work for end users. I have the content-filter-provider entitlement.

Issue 1 — saveToPreferences() fails in distribution builds

In dev builds (Xcode direct install), NEFilterManager.saveToPreferences() works fine — iOS shows a permission dialog and the filter is registered. In distribution builds (TestFlight/App Store), it fails immediately:

NEFilterErrorDomain code 5 — Operation not permitted

NEFilterErrorDomain code 5.png

Console log from nehelper: "Creating a content filter configuration is only allowed through profile in production version"

Issue 2 — .mobileconfig profile requires MDM

Following the Console hint, I tried a .mobileconfig profile with com.apple.webcontent-filter payload (ContentFilterUUID, FilterType: Plugin, PluginBundleID). On an unsupervised consumer iPhone (iOS 18.5), installation fails:

Profile Installation Failed — MDM required

MDM Required.png

Question: What is the correct mechanism to activate a NEFilterDataProvider on a consumer (non-MDM) iPhone in a distribution build? Is there a specific entitlement or approval process I'm missing?

(DTS Case-ID: 20087732)

Answered by DTS Engineer in 888761022

The limitations you’re bumping in to are by design. See the Deploying a content filter provider section of TN3134 Network Extension provider deployment for your options.

You might also look at switching to a URL filter. That has a privacy preserving design without any deployment limitations.

Finally, I recommend that you watch WWDC 2025 Session 234 Filter and tunnel network traffic with NetworkExtension, which offers a great summary of the various options in this space.

Oh, wait, one more thing:

the core feature doesn't work for end users.

The best way to avoid shocks like that in the future is to test your app using TestFlight. TestFlight reuses a bunch of App Store infrastructure, so it’s the closest you can get to an App Store release while still preventing ‘civilians’ from downloading your app.

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

Boost

Answer 1

DTS Engineer OP

Apple

8h

Recommended

The limitations you’re bumping in to are by design. See the Deploying a content filter provider section of TN3134 Network Extension provider deployment for your options.

You might also look at switching to a URL filter. That has a privacy preserving design without any deployment limitations.

Finally, I recommend that you watch WWDC 2025 Session 234 Filter and tunnel network traffic with NetworkExtension, which offers a great summary of the various options in this space.

Oh, wait, one more thing:

the core feature doesn't work for end users.

The best way to avoid shocks like that in the future is to test your app using TestFlight. TestFlight reuses a bunch of App Store infrastructure, so it’s the closest you can get to an App Store release while still preventing ‘civilians’ from downloading your app.

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

1

Answer 2

RomainDropB OP

3h

Thank you for your response. Two follow-up questions:

The url-filter-provider capability does not appear in the Capability Requests tab of my developer portal. Could you advise how to request it for com.dropbet.DropBet (App Store ID: 6762567708)?

Regarding the OHTTP relay onboarding form (developer.apple.com/contact/request/network-extension-url-filter): does the full PIR server + Privacy Pass infrastructure need to be deployed and running before submitting the form, or can the request be submitted earlier in the process?

Best regards

0