There are two ways to initialize a WebDomain when adding it to a ManagedSettingStore to be shielded. The first is by providing the relevant URL. The second is by providing a token representing a WebDomain that the user picked from the FamilyActivityPicker When using the second way, I'm able to configure the appropriate shield with aShieldConfigurationDelegate and control its behavior with a ShieldActionDelegate When using the first way, I am not. The shield is rendered, but I have no control over its appearance or behavior. My ShieldConfigurationDelegate and ShieldActionDelegate classes are not being hit. How can I set the ShieldConfigurationDataSource of WebDomains constructed via explicit URL?

Hi there, In rare cases (about 0.2% of the time?), I'm seeing calls to startMonitoring on an instance of DeviceActivityCenter throw an error with localizedDescription "couldn’t communicate with a helper application." I am certain I am passing valid parameters to the startMonitoring call because sometimes a naive retry after a few seconds succeeds. Similarly, I am certain that FamilyControls permissions have been granted by the user. Was hoping to get more color from the systems team on what some causes of this error are and if it is avoidable by the programmer.

selecting the Facebook app from the FamilyActivityPicker returns an ApplicationToken. When adding that token to a ManagedSettingsStore's shield.applications set, both Facebook and the "Facebook Messenger Kids" apps gets shielded, even though the latter was not selected from the picker. (Interestingly, the "Facebook Messenger" app does not get shielded - just the kids version) The same is true for shielding the ApplicationToken produced by selecting the Amazon app. It causes the Alexa app to be shielded. I assume this is occurring because the apps share a keychain group, bundle id substring, or some other property that the picker is using, but how can I avoid this behavior?

I'm seeing an issue where if I create and start a DeviceMonitoringActivitySchedule that begins 1 minute in the future lasts for 20 minutes has a warning time of 1 minute monitors a single app registers a threshold of 10 minutes for that app's usage the threshold is immediately breached upon the .startMonitoring call for that activity. However if I repeat the exact same experiment but with the interval beginning in the same minute we're currently in (not 1 in the future), it works as expected - the threshold is breached after 10 minutes of using the app. Is this expected behavior? If so why?

Is there a maximum length for the name of a DeviceActivity? Practically, I'm wondering if I can assume no loss/truncation in the string as long as it's under 2000 characters, nothing too crazy.

Hi there, I'm presenting a FamilyActivityPicker inside of a sheet, and on some phones, the FamilyActivityPicker freezes and crashes when the user expands the "Other" category only. "Other" is the only category that exhibits this behavior, and it only does this on some phones, not in all cases. This issue is perfectly reproducible on those phones when using the FamilyActivityPicker for the "other" category only, but on those same phones it does not reproducible in the Native ScreenTime Picker in Settings → ScreenTime → App Limits → Add Limit. I don't have access to these phones as they are user reports, but any guidance here would be deeply appreciated. More broadly, there are several issues with the FamilyActivityPicker (categories expand on top of each other when multiple are opened, varying behavior with tapping rows vs tapping select bubbles depending on phone size, etc) that the Native ScreenTime Picker doesn't have. Grouping websites as a standalone category is preferable as well. Could we as developers just have access to that one?

Modifying the WebContentSettings.FilterPolicy of a managedSettingsStore object to so that its type is not .none removes the private browsing capability in Safari by default. Is there a way to avoid this? Is this mentioned somewhere in the documentation? Are there any other unexpected side-effects of modifying the WebContentSettings.FilterPolicy?

We persist ApplicationTokens in a storage container that ShieldConfigurationExtension has access to. In rare, cases all the ApplicationTokens for a user seem to change. We know this because the Application parameter passed into configuration(shielding application: Application) -> ShieldConfiguration function has a Token that does not match (using == ) any of the ones we are persisting in storage. Interestingly, the persisted ones still work, so I don't believe storage has gotten corrupted or anything. We can use them to add or remove shields, we can use them to display labels of the apps they represent, etc. But they don’t match what’s passed into the ShieldConfiguration extension. If the user goes into the FamilyPicker at this point and selects an app of a token that we are already persisting, the FamilyPickerSelection will have a token matching the new one that is passed into ShieldConfigurationExtension, not the one we persisted when they last selected that app. This leads me to believe the tokens are updated/rotated in some cases. When and why does this happen, and how can we handle it gracefully?

When asking for ScreenTime permission from users, were are seeing cases where guard let error = error as? FamilyControlsError else { print(String(describing: error) print("\n") print(error.localizedDescription) return } prints Error Domain=FamilyControls.FamilyControlsError Code=5 "(null)" The operation couldn’t be completed. (FamilyControls.FamilyControlsError error 5.) We've also seen this with error code 4 and 7. Why are these failing to cast to FamilyControlsError?

We are seeing cases where DeviceActivityMonitoring extension is crashing permanently. This is due to a now-fixed bug that was causing a stack overflow. On devices where the extension crashed, it appears permanently unable to recover - even weeks after the crash and after multiple restarts of the device. It looks like recovery is being attempted, as the same four NSLog activities are emitted roughly every second that the phone is active. Logs: Process: DeviceActivityMonitoring Activity: beginning extension request Message: NSExtensionPrincipalClass `<private>` does not conform to NSExtensionRequestHandling protocol! Process: DeviceActivityMonitoring Activity: Loading Preferences From User Session CFPrefsD Message: Process: DeviceActivityMonitoring Activity: container_system_group_path_for_identifier Message: Requesting container lookup; class = 13, identifier = <private>, group_identifier = <private>, create = 1, temp = 0, euid = 501, uid = 501 container_query_get_single_result: success container_system_group_path_for_identifier: success Process: DeviceActivityMonitoring Activity: container_create_or_lookup_app_group_path_by_app_group_identifier Message: Requesting app group container lookup; personaid = 1000, type = DEFAULT, name = 9F7F4BA7-79CF-453C-B81C-568E96ADB711, origin [pid = 29, personaid = 199], proximate [pid = 3505, personaid = 199], identifier = <private>, euid = 501, uid = 501, platform = 2 containermanagerd stat [<private>]: exists: 1, isDirectory: 0, fsNode: <~~~> containermanagerd <private> is sandboxed. Issuing token for path: [<private>] (extension class: com.apple.sandbox.application-group) containermanagerd [0] command=38, client=<<~~~>, u=<501/501/~~/0/1000>, uid=501, pid=5595, sandboxed=1, platform=2 (1/1/0) [<~~~>], cached, cs cached>, error=(null) Consuming sandbox extension; path = [<private>], key = 0 Revoking sandbox extension; key = 0 Can anyone provide some insight into what is going on with the recovery attempt here? Practically, how can we recover the extension in these cases? Will an app update force the extension to restart properly? Hard reset of the device? Something else? Is there any way to check on the health of an extension from the main app so that we can deterministically know if the extension is healthy or not before relying on it?