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
entomoxalis
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Post
Replies
Boosts
Views
Activity
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.