I’ve set up a focus filter, but the perform() method in SetFocusFilterIntent isn't called when the focus mode is toggled on or off on my iPhone since I updated to iOS 18 beta (22A5326f). I can reproduce the issue for my app, but focus filters are also broken for any third-party apps installed on my phone, so I guess it's not specific to how I've implemented my filter intent. This used to work perfectly on iOS 17. I didn't change a single line of code, and it broke completely on the latest iOS 18 beta. I've filed a bug report including a sysdiagnose (FB14715113). To the developers out there, is this something you are also observing in your apps?

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

Starting with iOS 17.4, the DeviceActivityEvent initializer includes a new parameter named includesPastActivity.

The default value for this parameter is set to false, whereas device activity events have behaved as though this parameter were set to true up until now. This breaking change is a MAJOR ISSUE for developers who used device activity events in their apps before iOS 17.4 because their apps might not work the way they intended after the update. They'll have to release new app versions that specifically set includesPastActivityto true. In my opinion, the default value for includesPastActivity should be true to avoid disrupting events scheduled on older versions of iOS. I have filed an enhancement report (FB13573556) about this. I really hope this is changed before the official iOS 17.4 release.

The device activity monitor extension sometimes fails to launch when a schedule starts/ends or when an event threshold is reached. This issue may persist for several minutes or hours once it begins. Currently, the only known workarounds are: Restarting the phone. Waiting for an indeterminate period, ranging from a few minutes to hours, after which the device activity extension may or may not launch. I've filed a new bug report (FB13556935), which includes a sysdiagnose and precise timestamps of when the issue was reproduced. By looking at the errors, it appears the system is failing to launch the extension because it's looking at an invalid path: Service could not initialize: access(/private/var/containers/Bundle/Application/C6598B47-8977-447C-870B-4D21BDE8ACF9/Jomo.app/PlugIns/JomoDeviceActivityMonitor.appex/JomoDeviceActivityMonitor, X_OK) failed with errno 2 - No such file or directory, error 0x6f - Invalid or missing Program/ProgramArguments [u 8104FF60-5C49-45BD-8AFB-97BE88488134:m (null)] [()] Failed to start plugin; pkd returned an error: Error Domain=PlugInKit Code=4 "RBSLaunchRequest error trying to launch plugin com.jomo.Jomo.JomoDeviceActivityMonitor(8104FF60-5C49-45BD-8AFB-97BE88488134): Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x5dd8273e0 {Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}" UserInfo={NSLocalizedDescription=RBSLaunchRequest error trying to launch plugin com.jomo.Jomo.JomoDeviceActivityMonitor(8104FF60-5C49-45BD-8AFB-97BE88488134): Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x5dd8273e0 {Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}} This bug is CRITICAL for all apps relying on the Device Activity framework. It likely explains a range of issues reported since the framework's release. Specifically, due to this bug, end users may encounter problems such as apps not unblocking at the end of a schedule, apps not blocking at the start of a schedule, and time limits not being updated, among others.

Hello everyone 👋 I wanted to discuss an issue that has always been somewhat present, but seems to have become more frequent since the latest iOS 17 versions. When scheduling an activity that includes an event, the eventDidReachThreshold method does not trigger consistently within the device activity monitor extension. The issue is intermittent. However, repeating the following procedure increases the likelihood of encountering the problem: Schedule a simple activity with an event: Set the start time to the beginning of the current day and the end time to the end of the current day. Include an application token and a threshold (that you've already met for today 🙂). Once the activity is scheduled, monitor whether eventDidReachThreshold triggers in the device activity monitor extension. Workarounds I've discovered: Restart the activity: Not very reliable. Force restart the phone: A more drastic measure, but sometimes effective. Just wait: Wait for an undetermined amount of time, ranging from a few minutes to several hours, after which eventDidReachThreshold will start triggering just fine again. I've filed a bug report (FB13188666) concerning this specific issue. I'm curious to know if anyone else is experiencing it and what workarounds you've found!

Whenever a user focuses a textfield inside the view provided a device activity report extension, the extension crashes in iOS 17 (21A5248v). This worked flawlessly in iOS 16. I've submitted a bug report (FB12270432), but I can't dig deeper into the problem because I'm stuck on this: https://developer.apple.com/forums/thread/731010. Has anyone else come across this issue since upgrading to iOS 17?

A few days ago, I upgraded my phone to iOS 17 and have since encountered a serious issue with my app, which heavily uses the Screen Time API. Randomly throughout the day, the Screen Time connection breaks. As a result, all device activity reports turn up empty and the device activity center stops tracking activities. This problem doesn't only affect my app, but also all others that have Screen Time permissions on my phone. The only workaround I've found is to switch off and then switch on the Screen Time permission again. This issue is clearly a significant concern for all developers working with the Screen Time API. I've submitted a bug report (FB12332405), but I can't dig deeper into the problem because I'm stuck on this: https://developer.apple.com/forums/thread/731010. Has anyone else come across this issue since upgrading to iOS 17?