Hello Apple Developer Community, We have developed two totally separate apps for parental control: one for parents (xyz/parent.com) and one for children (abc/child.com). These are not two sides of the same app, but rather distinct applications. Recently, we integrated these two apps and encountered a few challenges and questions that we hope the community can help with. Family Picker Behavior: We noticed that only the parent app on the current device is displayed in the Family Activity Picker. Is this the intended behavior? Our expectation was that the Family Activity Picker would show both the parent and child apps available on the device. Is there a way to ensure that both types of apps are listed? Filtering Apps in Family Picker: Is it possible to filter the apps displayed in the Family Activity Picker to show only the child’s app and exclude the parent app? Our goal is to streamline the selection process for users by removing irrelevant apps from the picker. If direct filtering is not possible, are there any recommended workarounds or best practices to achieve a similar result? Screen Time Permission Requirements: We’ve successfully implemented screen time permissions using the Authorization Center for the child app. However, do we also need to request screen time permissions from within the parent app? If so, are there any specific guidelines or best practices for managing screen time permissions across two interconnected apps? Triggering Child Managed Settings from Multiple Apps: Is it feasible to trigger managed settings (e.g., enabling restrictions) for the child app from both the parent and child apps? We want to ensure consistent enforcement of settings regardless of which app initiates the change. Are there any limitations or conflicts we should be aware of when managing settings from two different apps? We appreciate any guidance or insights you can provide on these issues. We’ve referred to the Family Controls and Screen Time documentation, but we're seeking more specific advice related to the integration of two separate apps in this context. Thank you in advance for your help!

We have an iPad app which can write to user-specified locations on USB-connected storage devices. On unmanaged devices, this works just fine. However, when the device is under MDM, although the Files app can see the external USB storage device, it does not show up in the file browser in our own app. There's a restriction called "allowFilesUSBDriveAccess" which is set to true (the default), but there's no restriction called "allowOtherAppsUSBDriveAccess". Are MDM-managed iPads simply not allowed to access USB drives (except through the Files app)?

Using the Screen Time API, I can create multiple ManagedSettingStore objects with different names. Is there a way to retrieve these later by name? For example, if I create them dynamically from a configuration managed by the user of my app, and the app crashes or its data gets corrupted, how can I get rid of "stale" ManagedSettingStore objects that I no longer know? Or, if I somehow lose the name of a ManagedSettingStore I created, how long does the store stay active? Forever? How can I get rid of the "stale" store?

Can ManagedSettingsStore and DeviceActivityCenter be used from a background thread, or do I need to access them from the main thread/queue only?

i just downloaded the iOS 18 beta yesterday and now my phones (iPhone 15 pro) screen time keeps crashing. when I reach my limit and input the screen time code it won’t respond and keeps me locked out. when I went into the settings to just turn off screen time the entire settings app just freezes and then crashes entirely. I’ve tried restarting the phone several times and nothing has any impact and can’t find anything online except a lot of other people having the same issue without a fix.

Enrol Supervised iOS device. Push an CardDAV policy for the above device, the contacts gets synced in the native Contacts app as expected. (https://developer.apple.com/documentation/devicemanagement/carddav) When the above same profile is re-installed in the above device, the synced contacts are lost and password prompt is shown to enter the password - even though the installed profile contains password for the CardDAV policy. Password prompt from the device Re-Installed configuration <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadUUID</key> <string>35ee541b-fec0-46b0-bd48-bcc0702ab60b</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadOrganization</key> <string>MDM</string> <key>PayloadIdentifier</key> <string>com.mdm.ec89620f-2905-4c14-b09d-7e9f17944468.CardDAV</string> <key>PayloadDisplayName</key> <string>CardDAV</string> <key>PayloadRemovalDisallowed</key> <true/> <key>PayloadContent</key> <array> <dict> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadUUID</key> <string>07c423b5-8ae2-4e6e-9336-aa9ca850d6c9</string> <key>PayloadType</key> <string>com.apple.carddav.account</string> <key>PayloadOrganization</key> <string>MDM</string> <key>PayloadIdentifier</key> <string>07cV423b5-8ae2-4e6e-9336-aa9ca850d6c9</string> <key>PayloadDisplayName</key> <string>CardDAV Policy</string> <key>CardDAVAccountDescription</key> <string>****</string> <key>CardDAVHostName</key> <string>www.googleapis.com</string> <key>CardDAVPassword</key> <string>****</string> <key>CardDAVPort</key> <integer>443</integer> <key>CardDAVPrincipalURL</key> <string></string> <key>CardDAVUseSSL</key> <true/> <key>CardDAVUsername</key> <string>****</string> </dict> </array> </dict> </plist> Feedback ID : FB14250521

Enrol Supervised iOS device Turn ON screen time restriction by opening Settings app -> Content & Privacy restrictions -> Passcode & Face ID -> Don’t Allow. Now install a Passcode policy profile via MDM with the key “forcePIN” set to “true”, such that the device is needed to change the passcode in device. By following above steps, the profile fails. The failure response from the device states that passcode restriction is applied in the device, “The profile ‘Profilename’ may require a passcode change but the passcode cannot be modified.” This is an incorrect behaviour as MDM should have more control over the screen-time restriction as well. Error response from the device <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CommandUUID</key> <string>InstallProfile</string> <key>ErrorChain</key> <array> <dict> <key>ErrorCode</key> <integer>4001</integer> <key>ErrorDomain</key> <string>MCInstallationErrorDomain</string> <key>LocalizedDescription</key> <string>Profile Installation Failed</string> <key>USEnglishDescription</key> <string>Profile Installation Failed</string> </dict> <dict> <key>ErrorCode</key> <integer>4026</integer> <key>ErrorDomain</key> <string>MCInstallationErrorDomain</string> <key>LocalizedDescription</key> <string>The profile **** may require a passcode change but the passcode cannot be modified.</string> <key>USEnglishDescription</key> <string>The profile **** may require a passcode change but the passcode cannot be modified.</string> </dict> </array> <key>Status</key> <string>Error</string> <key>UDID</key> <string>****</string> </dict> </plist> Feedback ID : FB14249704

Brief & History Since iOS 17.4 and up we experience a lot of flakyness when it comes to DeviceActivity event thresholds. After a lot of testing and investigations inside system logs and filing countless bug reports we found a reproducible way why the event thresholds are not getting properly called. Findings Apparently when the device reaches near to max memory something called jetsamkills processes left and right. This means that the UsageTrackingAgent that (we think) is responsible for tracking the usage time of the device gets killed and doesn't recover until significant memory is freeing up on the device. How to test it yourself Use a slightly older device with ~ 3 or 4 GB of RAM Open a game or two that is meomry intensive (like Fishing Clash, yes..) and observe In the console logs you see something that only happens then: Process UsageTrackingAgent [39307] killed by jetsam reason highwater This happens often but recovers itself when the UsageTrackingAgent exceeds their 6MB memory limit. Yet the log looks like this: Process UsageTrackingAgent [39307] killed by jetsam reason per-process limit Once you kick the game, the memory is free and sometimes the event thresholds are calling in again. Defeating the purpose However this defeats the purpose of tracking usage time and shielding perhaps the playing app from being played after a certain amount of time! Feedback Assistant Ticket Here is the ticket with sysdiagnose, step by step and more information: FB13884981 Please fix this ASAP, this is such a pain for production users and their kids EVERY DAY.

Since iOS 18 Seed 2, I've noticed an issue. When calling startMonitoring(_:during:events:) with an already monitored activity, intervalDidStart in the Device Activity Monitor extension isn't triggered as it should be. I have to manually call stopMonitoring(_:) BEFORE restarting the activity for intervalDidStart to be called. This is 100% reproducible. This is different from how it worked before iOS 18 Seed 2 and contradicts the official documentation, which says, “If the app already monitored the activity, this method overwrites the previous schedule and events.” IMO, this suggests we shouldn't have to stop the activity manually; the startMonitoring(_:during:events:) method should handle it automatically. Is this a mistake or intended behavior? If intended: Could you give us the reason? The documentation should be updated to reflect this change. I've already filed a feedback about this issue (FB14110789).

The listening callbacks were not triggered for intervalDidStart and intervalDidEnd after successfully starting center.startMonitoring when I attempted to set a schedule with DeviceActivitySchedule at 20-minute intervals Is there anyone who can assist me? Thank you. Below you will find my code. let intervalLengthInSeconds = 20 * 60 let intervalEnd = Date(timeIntervalSinceNow: TimeInterval(intervalLengthInSeconds)) let intervalStart = Date() let schedule = DeviceActivitySchedule(intervalStart: Calendar.current.dateComponents([.hour, .minute], from: intervalStart), intervalEnd: Calendar.current.dateComponents([.hour, .minute], from: intervalEnd), repeats: false, warningTime: DateComponents(minute: 1)) let newActivity = DeviceActivityName(rawValue: "20minuteUse") Log("😯 \(String(describing: schedule.nextInterval))") do { try center.startMonitoring(newActivity, during: schedule) } catch { print("failed to start session: \(error.localizedDescription)") } class MyMonitorExtension: DeviceActivityMonitor { let store = ManagedSettingsStore() // You can use the `store` property to shield apps when an interval starts, ends, or meets a threshold. override func intervalDidStart(for activity: DeviceActivityName) { super.intervalDidStart(for: activity) // Shield selected applications. Log("😓 start-------") } override func intervalDidEnd(for activity: DeviceActivityName) { super.intervalDidEnd(for: activity) Log("😓 end-------") } override func intervalWillStartWarning(for activity: DeviceActivityName) { super.intervalWillStartWarning(for: activity) Log("😓 StartWarning-------") } override func intervalWillEndWarning(for activity: DeviceActivityName) { super.intervalWillEndWarning(for: activity) Log("😓 EndWarning-------") } } schedule.nextInterval ------ print: 😯 Optional(2024-06-21 08:34:00 +0000 to 2024-06-21 08:54:00 +0000)

Hello, I am working on an app that schedules a device activity monitor from the screen time API. I noticed that sometimes scheduling an activity monitor won’t work and instead I see this log: Canceling request to […].DeviceActivityMonitorExtension because it exceeded its allowed time. What does this mean? What exactly is exceeding its allowed time? Would love to get some feedback on this so I can prevent this from happening. Thanks a lot for any help and have a nice day!

Enroll an iOS device via MDM and apply passcode policy with "maxFailedAttempts" setting enabled https://developer.apple.com/documentation/devicemanagement/passcode Now when the user attempts to unlock device exceeds above "maxFailedAttempts" - the device gets wiped. Now the administrator is unaware of this event. It would be helpful to get an message/DDM status from device to notify the MDM server that device is wiped due to incorrect passcode attempts.

Hi, I uses to have the Time management for my Kids. Since my kid is using the bêta version of ios 18, Time management is not working anymore. He can use the iPhone without any restrictions … what can I do?

I have a mobile application accepted in the app store, and want to restrict access to ONLY iPhone. I have turned off access for macOS and visionOS, but cannot find a way to restrict access on iPads. Is there a way to do this without or with a new build?

Hi, I was trying to configure the Managed Wi-Fi Settings profile for a Mac device which is running on the Sonoma 14 OS. (https://developer.apple.com/documentation/devicemanagement/wifimanagedsettings?language=objc). I wanted to enable admin authorization for turning Wi-Fi on/off, and for switching between Wi-Fi networks. I followed the docs and tried these restrictions in lower macOS versions(Monterey, Mojave), and they are being enabled in the device-end. However for Sonoma devices, the restrictions are not being enabled(even though the profile is being pushed to the device). While looking around, I came across the fact that the airport cli utility was discontinued recently(https://www.intuitibits.com/2024/03/14/goodbye-airport/, doesn't allow me to hyperlink). So does that affect the working of the Managed Wi-Fi device profile in any way?

Hello, We are experiencing intermittent tunnel communication failures in iOS devices following internal application updates or fresh installations. This issue occurs specifically with VMware Workspace ONE Advanced (includes AirWatch) - On Premise and Workspace ONE Tunnel. Our enterprise mobility management platform provides comprehensive tools for managing corporate-owned and BYOD devices across various operating systems. Detailed Information: Applications Involved: VMware Workspace ONE Advanced (On-Premise): Manages and secures devices and applications. Workspace ONE Tunnel: Enables per-app VPN services, routing traffic from specific managed applications through our VPN. Problem Context: After a recent update, and notably after introducing deeplinking capabilities which required making our public DNS changes to host the Apple-app-site-association file, iOS devices are not routing application traffic through the Workspace ONE Tunnel correctly. Instead, applications are bypassing VPN configurations and connecting directly to public networks, jeopardizing data security. This behavior is inconsistent and varies across devices. To illustrate, I have attached a diagram (Diagram 1) that shows the flow of traffic during the issue compared to normal operations. Timeline and Troubleshooting Steps Taken: Initial Report Date: February 2024, following the iOS update 17.3.1 and post-deeplinking modifications. VMware Involvement: Multiple troubleshooting sessions, including log analysis and configuration reviews. VMware indicated the issue might not be directly related to their platform as the tunnel functions normally post-device restart. Logs Reviewed: Application logs, network traces, and device management logs. No errors directly linked to VMware solutions were found. The logs showing the issue occurrence and after a device restart are included (see Logs Set A and Logs Set B). Additional Information: Devices Affected: Various iOS devices, total fleet approximately 1500 units. Inconsistencies: The issue manifests inconsistently across different organizational groups (OGs) and is not tied to a specific app version or device model. Developer Notes: The issue does not occur when applications are deployed via Xcode during testing phases. It only arises when apps are updated in a live environment. Request for Assistance: We request Apple’s assistance in investigating potential iOS-specific causes or configurations contributing to this issue, particularly in the context of the deeplinking changes. A joint troubleshooting session is proposed to further diagnose and address the problem. Prompt support in resolving this issue, given its impact on our operations, would be greatly appreciated. Attachments: Diagram 1&2: Traffic Routing During Issue vs. Normal Operation Diagram 3: Our App communications diagram Logs Set A: Device Logs When Issue Occurs Logs Set B: Device Logs After Restart (Set A) After restart - no issue .log https://drive.google.com/file/d/1Q2COgXkMa3KnN1N-ggZKwYhHP7KC-Hwy/view?usp=sharing (Set B) before restart.log https://drive.google.com/file/d/1uS9kAV6zJyRvVRQoWQNKdWBBR7sxM6Js/view?usp=sharing Any suggestions? Thank you!

https://developer.apple.com/documentation/devicemanagement/systempreferences The Above documentation of "System Preferences" says deprecated. I assume that some of the panes are not working in latest OS due to this deprecation. My query is , Is there any other alternative to Disable or Enabled Preference Panes which was attained by SystemPreferences Payload. I couldn't find any. Is it entirely stopped and in latest OS's ,it wont allowed to restrict those panes?

In older versions of macOS, such as those predating Mac OS Sonoma, users had the ability to set the Lock Screen independently from their desktop wallpaper. However, with the introduction of Mac OS Sonoma, this feature seems to have been altered or removed altogether. Currently, there appears to be no option to set the Lock Screen image separately; instead, only changing the desktop wallpaper, changes the Lock Screen image. This change raises questions about whether it is a deliberate alteration in the setting flow or if it could potentially be a bug in the system. Users may wonder if this adjustment is intended to streamline the interface or if there are plans to reintroduce the ability to customize the Lock Screen image independently of the wallpaper in future updates.