I've been working with the Screen Time API for almost 6 months now. I found out it's completely unreliable, testing on iOS 17.4, the DeviceActivityReport is not showing, the DeviceActivityMonitor more often than not does not fire intervalDidStart. It's very frustrating. Has anyone found out a workaround? We all know there has to be something we're doing wrong, since apps like Opal and Jono does not present those types of issues. Let's please unite our forces and find a solution. How to use this API should not be a secret!

Using the DeviceActivity framework we are able to display data based on a user's screentime and device usage. With the DeviceActivityFilter property, you can specify the date interval to collect data between. In testing, it seems that data only becomes accessible once the extension has been installed (so the extension isn't reading the screentime data already collected on device). However, once installed, I'm curious how far back you can query data from in the data interval? Opal which uses the Screentime API appears to have a lifetime Screentime metric, so hypothetically it should possible to query data as far back as collection starts. Unless they are getting around the sandbox environment and storing the data somehow. Side note on Opal -- They seem to have a community average of Screentime among people in the same age group. Does anyone know how they are collecting the data for this average? Is it actually using live Screentime data or just aggregating data from other studies?

Our app uses DeviceActivityReport to display the user’s screen time. The performance of DeviceActivityReport is often very poor. These issue occur commonly: Screen time is reported as 0 minutes DeviceActivityReport View appears completely blank The host app loses connection with the DeviceActivityReport altogether I have implemented several workarounds which only slightly improve the performance, to varying degrees depending on the device iOS: Inside the DeviceActivityReport code - retry fetching screen time data until it returns a non-zero result Implement a “refresh” button which reloads the DeviceActivityReport view from the host app However, due to the sandboxed nature of DeviceActivityReport, there is no way for the host application to tell if the DeviceActivityReport extension is experiencing these performance issues. It results in a really bad user experience. I am building the app with Xcode 14 due to another issue where DeviceActivityReport fails to load for all iOS 16 devices when built with Xcode 15 (this is a know issue, here’s a link to a discussion on the developer forums: https://developer.apple.com/forums/thread/735915). However, when testing on iOS 17 devices with Xcode 15 builds, the above issues still occur. I have received no crash reports from DeviceActivityReport. These issues are known bugs and have been discussed on the developer forums, but I haven't yet seen a solution. Other screen time apps exist that use the DeviceActivityReport seemingly flawlessly, so I know that there is a way to improve the performance of DeviceActivityReport in my app. Please help! I have been dealing with this poor performance for a long time now with almost no improvement!

There have been several posts (i.e. here, here) about the lagginess of the DeviceActivityReport extension. Often it takes a few seconds for the view to load, or sometimes doesn't show up at all. I've confirmed this is not a case of excessive memory usage in the extension (exceeding 100MB), because I've profiled the extension and it consistently maxes out at 10MB. I've placed a loading screen behind the DeviceActivityReport inside a ZStack in the host app in order to see if the lag is because it takes some time for the extension to spin up - but the loading screen does not appear, indicating that the extension is running right away, but receiving the view from the extension in the host app is where the lag happens. It's been extremely difficult to debug because the lag only occurs a fraction of the time, and DeviceActivityReport is pretty much a black box. There's no documentation about how the host app and extension actually communicate. I've also combed through the logs using the Console app on Mac with no indication of any issues, (but I do see the message "Connection to view service was invalidated" coming from the extension even when there is no lag). I'm pretty convinced that the problem lies in the host app, because when I strip everything away from the host app, DeviceActivityReport never lags. I suspect that there are processes running (network requests, async tasks, or state updates) that block the report view from being received in the host app. Could you please help me understand why this could be happening, with as many details as you could provide? Any details on how the host and extension communicate, what processes could block the view from appearing, or anything else. Seems like this is a common issue but plenty of apps also don't experience it. Any guidance you can provide would be extremely helpful, as I've been trying to fix this bug every since I've been working with this API with no luck. Thanks in advance!

I have a request from a client that would like to create a solution where a central component is the ability to retrieve the users app usage. I can see that there are various api's todo that - one example is the Device Activity API. Another hope from the client is that this should be a web solution and not an app. I haven't quite been able to figure out if this is possible or not. I have three questions: Is it possible to retrieve app usage information through a REST api (or similar) outside an iOS app? Is it possible to use the appleId as a kind of auth solution for a web application Are there any similar APIs for older versions than iOS 15?

How can I differentiate between multiple children in order to display screentime data to the user separately for a parent with multiple children? As far as I can see, the options are .children, and .all? I understand I can retrieve some info from within the extension so I can group data separately, but is there any way to reliably filter between different children from within my app, say using a DeviceActivityFilter? Many thanks!

I am currently debugging an issue with DeviceActivityMonitor where the threshold is reached even though the target app (e.g. Instagram) is not being used actively. I noticed that the device with the unexpected behavior had the instagram.com website opened in the Safari web browser (among hundreds of other tabs). That tab was not actively used either (not in foreground, Safari app neither used). However, I was wondering if it can happen that this website is contributing towards the threshold as well even though it is in background and not used? Otherwise I cannot explain myself this strange behavior.

currently when I try to set several schedules to the same activity the latest schedule I set is the only one I understand I can have only 1 schedule for activity. ? I thought about setting a new schedule on the intervalDidEnd but, I get no interval did start if the current time is in the middle of the interval I set For example, now it is 15:00, and my previous interval started at 14:00 and ends at 16:00 but the user sets a new interval from 14:30 - 16:40 I call the deviceActivityCenter.stopMonitoring([someActivityName]) and get noIntervalDidEnd event Then I set the new interval successfully with deviceActivityCenter.startMonitoring(someActivityName, during: deviceActivitySchedule) and get no intervalDidStartEvent So how can I achieve several intervals? If I had gotten the events of the start and end it would be possible Thanks for the help

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.

As per our code, we have the apps to be shielded whenever the threshold is reached. According to this use-case, our code in DeviceActivityExtension looks something like: override func eventDidReachThreshold(_ event: DeviceActivityEvent.Name, activity: DeviceActivityName) { super.eventDidReachThreshold(event, activity: activity) defaults?.setValue(event.rawValue, forKey: "appLimitEventName") defaults?.setValue(true, forKey: "appLimitReached") defaults?.synchronize() // using darwinNotificationCenter to trigger callback in the application let darwinNotificationCenter = DarwinNotificationsManager.sharedInstance() darwinNotificationCenter.postNotification(withName: "nextAppLimitInitiated") // using Notifications to debug since print doesn't work scheduleNotification(with: "interval threshold reached") } And in our application, we have the shielding logic in place, init() { let darwinNotificationCenter = DarwinNotificationsManager.sharedInstance() darwinNotificationCenter.register(forNotificationName: "nextAppLimitInitiated"){ print("callback received") let appLimitReached = self.defaults?.bool(forKey: "appLimitReached") let appLimitEventName = self.defaults?.string(forKey: "appLimitEventName") if appLimitReached ?? false, appLimitEventName != "" { // this sends the notification when callback is received self.scheduleNotification(with: "init start") self.defaults?.setValue(false, forKey: "appLimitReached") guard var dataArray = self.defaults?.array(forKey: "appLimitdataArray"), !dataArray.isEmpty else { return } let appLimitData = dataArray.first as! NSDictionary let appLimitKey = appLimitData["appLimitId"] as! String let data = self.getSchedule(key: appLimitEventName ?? "") if let appTokens = data?.applicationTokens { for token in appTokens { if !self.applicationTokens.contains(appTokens) { self.applicationTokens.insert(token) } } } self.store.shield.applications = self.applicationTokens self.store.shield.applicationCategories = ShieldSettings.ActivityCategoryPolicy.specific(self.categoryTokens, except: Set()) dataArray.removeFirst() //dataArray.append(appLimitData) self.defaults?.set(dataArray, forKey: "appLimitdataArray") self.initiateMonitoring(initiateAgain: true) self.scheduleNotification(with: "init end") } } } This works as expected for multiple App Limits but only when the device is connected to the Xcode. If we disconnect the device from Xcode/ stop application from Xcode/ try in release mode, the callback is not received from extension to the app/init block. When the device is connected to Xcode, if the apps hit the threshold, they are shielded automatically. But if the device is disconnected/ app is in release mode, the apps are not shielded automatically even after the threshold is reached. It is shielded later only after opening our app once. Please let me know if I'm doing anything wrong in receiving callback or in my shielding logic. If I need to place the shielding logic in the extension, please tell me how I can handle multiple appTokens.

I have two repeating DeviceActivitySchedules running in my app and noticed a super strange behavior: whenever I modify Screen Time API permission settings (granting an additional app permission, or removing permission for a different app (completely different unrelated screen time apps from App Store)) all my DeviceActivitySchedules are cancelled and the intervalDidEnd callbacks are called my permission is not modified in this scenario this is a super strange and unexpected behavior is anyone able to reproduce this? for me this happens 100% of the times I do this any known workarounds?

How can I count the number of pickups for a certain application? The docs say that there is a struct ApplicationActivity within the DeviceActivityData: https://developer.apple.com/documentation/deviceactivity/deviceactivitydata Using this code I receive a warning in XCode: Value of type 'DeviceActivityData' has no member 'applicationActivity' struct ApplicationPickupCountReport: DeviceActivityReportScene { // Define which context your scene will represent. let context: DeviceActivityReport.Context = .applicationPickupCount // Define the custom configuration and the resulting view for this report. let content: (String) -> ApplicationPickupCountView func makeConfiguration(representing data: DeviceActivityResults<DeviceActivityData>) async -> String { var totalPickups = 0 let totalPickups = await data.flatMap { $0.applicationActivity }.reduce(0, { $0 + $1.numberOfPickups }) return "\(totalPickups)" } }

Hello, I am using a DeviceActivityEvent to limit access to an app after the user has spent x minutes on it. Sometimes it can happen that a DeviceActivitySchedule spans from 11:55pm - 12:25am (just an example). In these cases, I have noticed, the DeviceActivityMonitorExtension’s eventDidReachThreshold is not called after the user has reached the threshold time interval in the observed app. I assume this is because we have transitioned over midnight and something weird happens to the DeviceActivitySchedule. I’ve tried adding the day components to the DeviceActivitySchedule as well, but then it fails completely. Any advice how to handle this? I could, of course, create two separate DeviceActivitySchedules: one for before midnight, and one for after. But depending on the user’s real app usage that could lead to slightly different (and unexpected) behavior.

Hello! I am using the eventDidReachThreshold callback in the DeviceActivityMonitor in order to shield a target app after the user has spend x amount of time on it (e.g. x = 5 minutes). Many times this works fine, and I can trigger my shield after the specified threshold has been met. However sometimes, when they leave the target app before the threshold has been reached, the eventDidReachThreshold callback gets called randomly while they are doing something else on their phone (e.g. using a different app, on the Home Screen, phone locked…). From my perspective this does not make sense, since they are not actively spending time on the target app, and that time should not be counted towards the target app’s threshold. And it is also very confusing for the users because they will then find a blocked target app even though they haven’t used their time budget completely. This is not related to the intervalDidStart / intervalDidEnd callbacks, because they are not correlating with the timing of when the eventDidReachThreshold callback is called unexpectedly. Any ideas what this could be related to?

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.

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.

There is a way to allow DeviceActivityMonitor to make UI changes? Currently I have some code in the intervalDidStart and intervalDidEnd that updates Core Data entities, and it works correctly. However, the changes are only reflected if the app is terminated and opened again. Thus, if the app is opened and one of the methods inside the DeviceActivityMonitor is being called, the UI won't be updated. PS: I am using @FetchRequest to retrieve the core data entities called BlockEntity, and I have a little circle in the UI which should indicate the status of the block: active/inactive, so it would be nice to update the color in real time when intervalDidStart or intervalDidEnd are called.

I am able to correctly select and store the tokens of apps and categories my users will block, but I am unable to pre-populate Picker whenever the app is rebooted with previously selected and stored tokens. Below is the selection variable I am passing to the picker... var selectionsToBlock = FamilyActivitySelection() { willSet { saveSelection(selection: newValue) blockersSelected = true } } Is there any way I can provide my existing blockers (shown below) so that the user can easily edit their list of restricted apps from the Picker? func savedBlockers() -> FamilyActivitySelection? { let defaults = UserDefaults.standard guard let data = defaults.data(forKey: userDefaultsKey) else { return nil } return try? decoder.decode( FamilyActivitySelection.self, from: data ) }