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?

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

⬇️ ANYONE ON APPLE'S SCREEN TIME TEAM, PLEASE READ THIS ⬇️ Let's summarize the situation. 3rd-party apps with screen time access can be disabled by going to Settings > Screen Time > Apps with Screen Time Access. That's fine. Now, if I want to make it harder to remove my restrictions, I can ask a friend to enter a Screen Time Passcode for me. Great idea! The problem is my Screen Time Passcode isn't requested when disabling permissions for a third-party app. It's required for modifying any other Screen Time setting EXCEPT permissions for 3rd party apps. This is frustrating. The Screen Time passcode is a great feature. Making it compatible with permissions granted through the Family Controls framework is our NUMBER ONE REQUEST from tens of thousands of users. This feature has been requested for a long time (iOS 16, iOS 17, …): https://forums.developer.apple.com/forums/thread/714651 https://forums.developer.apple.com/forums/thread/727291 https://discussions.apple.com/thread/255421819 FB13548526
 If you're a developer working on Screen Time, share your feedback below or file one using Feedback Assistant. It is very disappointing to see it wasn't implemented for iOS 18. I can't believe this would require tremendous work from the Screen Time team to make it happen, but it would be a significant improvement for the Family Controls Framework and a ray of sunshine for all the developers who have worked really hard to deliver high-quality apps using the Screen Time API. Could an Apple engineer or a Screen Time team member give us any updates? Implementing this before the public release of iOS 18 would make A LOT of developers happy.

Some of our users encounter an issue after updating their iPhone/iPad to iOS 17.5.1. The tokens passed in the Shield Configuration extension don't match the tokens they selected in my app using the FamilyPicker before updating to iOS 17.5.1. It seems the tokens changed for no reason. My app can't match the token from the ShieldConfigurationDataSource to any tokens stored on my end, causing my shield screens to turn blank. The same applies to tokens in the Device Activity Report extension. The only workaround I've found is to tell affected users to unselect and reselect apps and websites to block in my app. This gets them new tokens from the FamilyActivityPicker, which solves the issue. However, for some users, the bug reoccurs a few days later. Tokens seem to change again, causing the same issue in the Shield Configuration extension. I am not able to reproduce the issue on my test devices so I have no sysdiagnose to attach. However, this issue is affecting other screen time apps: https://developer.apple.com/forums/thread/732845 https://forums.developer.apple.com/forums/thread/756440 FB14082790 FB14111223 A change in iOS 17.5.1 must have triggered this behaviour. Could an Apple engineer give us any updates on this?

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).

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?

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)

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?

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.

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?

Recently i created an ABM account and seemed to work fine. all of the sudden we cannot log in anymore and we get a notification that this apple ID is deactivated (but it is active). when i want to reset password, deactivate or delete this user in ABM, i get an INTERNAL_ERROR message with no further explination. i can delete and deactivate other users but not this one. The log file is not realy any use since it sais 'SUB_STATUS, COMLETED_WITH_FAILURE". Any idea how i can resolve this?

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.

Is anyone else having the same problems. We been contacting Apple for almost two week, have raised at least 3 or 4 claim tickets to get our issue resolved, but Apple does not/has not responded? Does anyone have recommendation as to what we can do. We are losing money as we cannot open up our App? Thanks, CDL

Hello, I'm working on an app that makes use of Screen Time features by leveraging the Family Controls, Device Activity and Managed Settings frameworks. The main app works fine by shielding/unshielding apps with a toggle. When it comes to monitoring the time intervals with the Device Activity Monitor (DAM) extension (e.g. lock X apps for Y minutes), I'm experiencing several issues. To shield/unshield apps and kick off the monitoring I perform the following instructions: let timeInMinutes = 15 let startDate = Date(timeIntervalSinceNow: 1.0) // padding added to avoid invalid DAM ranges < 15 mins. let endDate = startDate.addingTimeInterval(timeInMinutes * 60.0) let components: Set<Calendar.Component> = [.day, .month, .year, .hour, .minute, .second] let calendar = Calendar.current let intervalStart = calendar.dateComponents(components, from: startDate) let intervalEnd = calendar.dateComponents(components, from: endDate) let schedule = DeviceActivitySchedule(intervalStart: intervalStart, intervalEnd: intervalEnd, repeats: false) try deviceActivityCenter.startMonitoring(.definiteShield, during: schedule) let managedSettingsStore = ManagedSettingsStore() managedSettingsStore.shield.applications = selection.applicationTokens // `selection` being an instance of `FamilyActivitySelection` The main pain points are: After this code is performed, I would expect the Device Activity Monitor extension to start, or at least to start once I go to background. To check whether the DAM extension is running or not, I attach to the extension process manually (Product > Attach to Process by PID or Name). But I can see the extension correctly running only after 3-4 attempts of calling startMonitoring. Even when the DAM extension runs, intervalDidStart and intervalDidEnd methods in the extension are called quite randomly - most of the times not being called at all - thus making the extension hugely unaffordable. Please note: I already ask for Screen Time permissions during the onboarding by calling AuthorizationCenter.shared.requestAuthorization(for: .individual), so by the time the user shields the apps, these permissions are already granted. I already have Family Control entitlements for development and distribution, and for both the main target and the DAM extension target. In the intervalDidEnd method, I simply call ManagedSettingsStore().clearAllSettings() and DeviceActivityCenter().stopMonitoring(). This looks like to be enough to stay way below the 6MB memory limit. Am I doing something wrong, is there a way to fix this, or is just the Device Activity framework that is unstable?