Hi, Consider a content filter app that allows most requests. While running, it handles requests and determine what to do. It does not affect any request while it is not running. However, during startup, it seems to block all requests, on iOS 16 or 17. On iOS 15, the behavior is bit different. Show the picture below: Questions Is this the expected behavior? Is this documented? Steps to reproduce Create content filter app with filter data provider with lengthy startup, something like the following: import NetworkExtension class FilterDataProvider: NEFilterDataProvider { override func startFilter(completionHandler: @escaping ((any Error)?) -> Void) { Task { try await Task.sleep(nanoseconds: 10 * 1_000_000_000) completionHandler(nil) } } override func stopFilter(with reason: NEProviderStopReason) async {} override func handleNewFlow(_ flow: NEFilterFlow) -> NEFilterNewFlowVerdict { guard let url: String = flow.url?.absoluteString else { return .allow() } if url.contains("example.net/") { return .drop() } if url.contains("example.org/") { exit(42) } return .allow() } } Install the app on a supervised iPhone or iPad. Install a WebContentFilter profile. Wait for the content filter to start. You can check the status in Settings > General > VPN & Device Management > Content Filter. Open Safari app. Request http://example.net/ and confirm that it is blocked. Request the other URLs and confirm that it is allowed. Request http://example.org. It kills the filter data provider. Request some URLs quickly. Background to the questions We offer a content filter app that might be stopped during the device sleeps. When a non-our-app’s push notification is received, the device wakes up, and the content filter starts up. Then the push notification seems to be lost. It is observed on iOS 16 and 17, not on iOS 15.

We provide a MDM product. In our product, payloads and properties which require supervision display those requirements. Two properties forcePreserveESIMOnErase and allowWebDistributionAppInstallation of the restriction payload don’t require a supervised device according to the descriptions in Apple Developer Documentation. However, in our observation, those properties seem to require it. Are those OS bugs or documentation errors? (In which category should I submit a feedback?) Steps to reproduce Prepare a supervised device (I used an iPhone 12 mini with iOS 18.1) and a configuration profile contains the following restrictions: <!-- Does not require a supervised device --> <key>allowDiagnosticSubmission</key> <false/> <!-- Requires a supervised device --> <key>allowESIMModification</key> <false/> <!-- Does not require a supervised device according to its description --> <key>allowWebDistributionAppInstallation</key> <false/> <!-- Does not require a supervised device according to its description --> <key>forcePreserveESIMOnErase</key> <true/> Then, Install the profile with Apple Configurator. Confirm 4 restrictions are shown in Settings > General > VPN & Device Management > PayloadDisplayName > Restrictions. Punch Settings > General > Transfer or Reset iPhone > Erase All Content and Settings, to unsupervise. Install the profile with Apple Configurator. It cannot be installed automatically because the device was not supervised. Manually install the downloaded profile. Check Settings > General > VPN & Device Management > PayloadDisplayName > Restrictions. Expected results 3 restrictions—allowDiagnosticSubmission, allowWebDistributionAppInstallation and forcePreserveESIMOnErase—are shown. Actual results Only one restriction—allowDiagnosticSubmission—is shown. Appendix: Restriction keys and their restricted message shown in Settings allowESIMModification: eSIM modification not allowed forcePreserveESIMOnErase: Preserve eSIM on erase enforced allowWebDistributionAppInstallation: Web app distribution not allowed allowDiagnosticSubmission: Diagnostic submission not allowed