In the per-app case it’s definitely not possible. The mechanism used to associate the filter configuration with the app (ContentFilterUUID) requires that the app be installed by MDM. In the global case I think it’s possible [1], but it requires that the device be supervised, which is a significant constraint. Ok thank you. It looks like the per-app case won't work as it requires an MDM installation of the app. Also looks like the global case won't work as it requires the device to be supervised. Hopefully the feedback item (FB16614357) is reviewed and potential movement on these restrictions are made in a future update. Supporting this on unsupervised and unmanaged iOS devices will help iOS to provide this functionality in a secure and privacy cognisant manner.

This is a classic why question, which I can’t answer. Ok, got it – I'll submit a formal feedback to address the usage of these APIs on unsupervised, unmanaged iOS devices. Update: Feedback submitted - FB16614357 Third time lucky, though is there any technical answer that someone may be able to answer, if the following would function on iOS non-developer devices: Question: Is it technically possible for the user to first manually install a MDM configuration profile which includes the required 'Content Filter' details and then have a Content Filter provider (using NEFilterManager, NEFilterDataProvider and NEFilterControlProvider) work on the device?

Thank you for the response. Regarding your note: I’m not sure what you mean by “VPN or DNS approach” Currently on iOS, there are two main ways that apps on the App Store provide network content blocking or network filtering capabilities on unsupervised and unmanaged devices: DNS - Create a DNS server which blocks name requests for certain domains. An accompanying iOS client app prompts users to download a custom Configuration Profile on the device and then manually accept in Settings, which modifies the DNS name servers for that device allowing certain traffic to be filtered and blocked by the domain name server. VPN - Create a VPN Server that tunnels all network traffic and blocks traffic requests for certain domains. An accompanying iOS client app sets up the VPN connection via the NEVPNManager API. Both of these approaches are currently in use on the App Store and are inherently privacy hostile. The providers of either the DNS or VPN service can track domains accessed and/or traffic routed via their servers. I am wanting to filter traffic which is guaranteed to be more privacy compliant on-device on unsupervised and unmanaged iOS devices, by using the Content Filter Provider approach (NEFilterManager, NEFilterDataProvider and NEFilterControlProvider). These APIs are designed from the ground up to ensure that traffic and domains cannot be tracked and yet the more privacy compliant approach is not supported by Apple? Why? You may say: I wouldn’t. To be clear, the limitations on content filter are not an accidental omission but an expression of a privacy policy. I understand why the APIs are architected in a privacy compliant manner, which I fully support, but Apple's policy in allowing their use forces app developers to use less privacy compliant means to provide this functionality and simply externalises the privacy breaches for users. This argument that these APIs may be problematic to be used broadly for on-device network filtering also falls apart because: Apple supports their use on children's devices! The tech note explains that it's ok to use them in ScreenTime scenarios on a child's device which is managed by a parent. So these are problematic to use, but it's ok to use them on children's devices? So Apple thinks a parent can make a fully informed evaluation on the suitability of this functionality for their children but are incapable of making a fully informed evaluation of the suitability of this functionality for themselves and their own devices? Apple supports the exact same APIs on unmanaged Macs. Sure Macs are generally given more flexibility, but the API's work well and are not causing major privacy issues on that platform. In lieu of the above changing in an iOS update – which I can send feedback via Feedback assistant about – is there any answer or guidance on the other question: If it can't work on unsupervised, unmanaged iOS devices, is possible for the user to first manually install a MDM profile which includes the required 'Content Filter' details and then have it work?

If this is on iOS 15.4 then it's likely a bug in the OS; see a similar issue with SFContentBlockerManager.getStateOfContentBlocker(...) : https://developer.apple.com/forums/thread/702746

It also looks like SFContentBlockerManager.reloadContentBlocker(withIdentifier:completionHandler:) also doesn't work on iOS 15.4 (at least in the iOS simulator, likely also on device). Calling this method does not reload the content blocking rules for the identified content blocking extension. You need to manually turn the content blocking extension off and on to have the rules reloaded which breaks my app.

Am seeing the same issue on iOS 15.4. getStateOfContentBlocker returns the correct state on initial app launch, however if the state is then changed in the background while the app is running and getStateOfContentBlocker is called again it will return the incorrect initial state of the content blocker, not the correct changed state. This bug does not occur on iOS 15.3 and earlier with the exact same code. Doesn't seem to be a fix unless the app is killed and re-launched.

Not an answer