Is there a way to use DeviceActivityMonitor to monitor a user's Screen Time ONLY on the current device, even if they have "Share Across Devices" enabled in their Screen Time settings? For DeviceActivityReport, you can provide a DeviceActivityFilter which can specify the devices you want to show. But I have not seen any way to filter devices with the DeviveActivityMonitor API. I would expect there to be a additional argument to DeviceActivityEvent's init method: init( applications: Set<ApplicationToken> = [], categories: Set<ActivityCategoryToken> = [], webDomains: Set<WebDomainToken> = [], threshold: DateComponents ) Where you can specify devices as well. Right now, it seems like the default behavior is to monitor across all shared devices, which is causing problems for my application.

My app monitors DeviceActivityEvents with no categories, apps, or websites selected because we want to monitor their time spent on all categories, apps, and websites. This is because my app gives users rewards for keeping their total Screen Time low. Unfortunately, it has been seemingly impossible to align the Screen Time shown with DeviceActivityReport to the Screen Time monitored with DeviceActivityMonitor. By default, the DeviceActivityReport captures more Screen Time than the DeviceActivityMonitor by default. But if I try to filter the report by totalActivityDuration on each category, it misses some Screen Time captured by the monitor (like FaceTime, for instance). I simply want to report to the user exactly the Screen Time I am monitoring by default with DeviceActivityMonitor. Is that possible without selecting any categories, apps, or websites in the monitor?

My app has been "waiting in review" for several days. Usually it at least gets into review within 24 hours, sometimes even approved within that time frame. Is there a slowdown during the holiday season? I read that Apple was supposedly keeping the review process working during the holidays

My app "Present: Screen Time Control" (bundle ID com.getpresentapp.Present) has been in review for a week. Usually the app review takes about a day. Is there a reason for the long review time?

My app uses a repeating 24 hour DeviceActivitySchedule defined like this: let intervalStart = DateComponents(hour: 0, minute: 0, second: 0) let intervalEnd = DateComponents(hour: 23, minute: 59, second: 59) let schedule = DeviceActivitySchedule( intervalStart: intervalStart, intervalEnd: intervalEnd, repeats: true) try center.startMonitoring(       ACTIVITY_NAME,       during: schedule,       events: [...]) Both intervalDidStart and intervalDidEnd callback functions update CoreData and UserDefaults, and sometimes make network requests, and I'm worried that their close invocations may cause unexpected behavior. Since intervalDidStart should be invoked only one second after intervalDidEnd, but intervalDidEnd may take longer than one second to run, due to updating local data and waiting for network requests to complete, how should this effect the invocation time of intervalDidStart? Is there a rule about the ordering of these functions, for instance if the interval is repeating and essentially overlaps like mine, is it guaranteed that intervalDidStart will always be called after intervalDidEnd returns, or is the behavior more undefined?

I've downloaded another screen time app that uses DeviceActivityMonitor, and once that app starts monitoring during an active monitoring schedule on my app - my app's monitoring schedule immediately ends. Is this expected behavior? Can't find this in any of the docs, but are two separate apps allowed to monitor activities during an overlapping schedule?

It seems like private browsing is undetectable with DeviceActivityMonitor for two reasons: Specific web domains do not cause the monitoring threshold callback functions to fire, due to the privacy setting Safari is not able to be monitored as an app or a category. It doesn't appear in the FamilyActivityPicker, and it doesn't appear to belong to any Screen Time category when viewing Safari's information in Screen Time Settings Is there any way to monitor device activity during private browsing? If not, that seems like a big problem for apps that allow parents to set device activity limits for their kids.

Since Monday March 13 2023, DeviceActivityReport with a daily segment filter shows 0 screen time, for all users of my app (there are thousands). When changing the segment to hourly, it works but performance suffers. I've defined the filter like this: @State private var filter = DeviceActivityFilter(segment: .daily(during: DateInterval( start: Calendar.current.startOfDay(for: .now), end: .now))) Is anybody else experiencing this? This happened on its own after no change in the code or update to the app, and seems to be correlated with the first full day of Daylight Savings. I will file a bug in Feedback Assistant, but is there any other guidance you can give on what might be the root cause, and if there's a fix? Seems like a large issue. Thanks in advance!

When using ManagedSettingsStore to shield apps, no system apps are shielded even when specifying all application categories. Here is my code: managedSettings.shield.applicationCategories = .all() Even when using the FamilyActivityPicker and selecting "All Apps & Categories" system apps like Messages do not get shielded. managedSettings.shield.applicationCategories = .specific(selectedCategories) I find this strange, since Messages exists inside the Social category, and is tracked fine using DeviceActivityMonitor. Why can't it be shielded using app categories? I'd like to be able to shield all apps, including Messages, without having the user to specifically select the apps using FamilyActivityPicker. Is that possible?

We have an app that uses the Screen Time APIs to block certain apps set by the user on a schedule: We use ManagedSettings to shield selected apps We use DeviceActivityMonitor to shield the apps automatically on a schedule set by the user. The shielding starts during the intervalDidStart callback function and ends during the intervalDidEnd callback function We are getting reports from the majority of our iOS 17 users that the app blocking schedules no longer work on iOS 17. We have tested this on our own iOS 17 devices and reproduced the behavior. But the feature still works consistently on iOS 16 devices. The app is still built using Xcode 14 instead of Xcode 15 due to another issue - the DeviceActivityReport is blank for all iOS 16 users when built in Xcode 15 (link to issue on the developer forums: https://developer.apple.com/forums/thread/735915). When testing with Xcode 15 builds, the bug appears to improve - however it still occurs intermittently. Are there any other mechanisms to run tasks on repeating schedules? For this specific feature, we don't need to eventDidReachThreshold callbacks, which is the main purpose of DeviceActivityMonitor. So we really don't need any Device Activity integration at all, just setting and disabling ManagedSettings shields at certain times. Would love if anyone could suggest and alternative to DeviceActivityMonitor.

I am having a lot of trouble reliably making network requests from the DeviceActivityMonitor extension. In the app extension, when intervalDidEnd is called by the system, I add some data to the app's local CoreData store and sync that with the server. I use URLSession dataTask to make a POST request to my server, with URLSessionConfiguration.sharedContainerIdentifier set to my App Group's shared identifier. It is extremely rare that my server receives this request, although sometimes (rarely) it does. I've tried things like wrapping the task in performExpiringActivity or using URLSessionConfiguration.background suspecting that this task needs to run in the background, but none of it seems to work. What I suspect is happening is that the App Extension gets cancelled before the request is able to be invoked. Looking at the console logs, sometimes the work stops before the request is called, sometimes during the request task, and sometimes even before I am able to update my local data store. It's been very difficult to find any information on the lifecycle of the DeviceActivityMonitor Extension. What I want to know is: How can I reliably make network requests from the DeviceActivityMonitor Extension? What is the lifecycle of this extension? (How long do I have to complete work inside callback functions invoked by the system? And can I extend this time if necessary?)

My app sends screen time awareness notifications based on DeviceActivityMonitor thresholds. Often, users receive two notifications in a row for the same screen time threshold. This means that the app extension is triggering the same eventDidReachThreshold callback function twice for the same threshold. I've made sure that there is only one activity schedule being monitored. This happens often, but not every time (over 50% of the time). Anybody else experience this issue, and any way to mitigate it?

I've been experiencing some serious performance issues with DeviceActivityReport. Their severity tends to vary across devices - for some of my users it's really bad and for some it's mostly fine - but every device seems to experience these issues at some point. 1. DeviceActivityReport is completely blank. Often on launch, the DeviceActivityReport is completely blank and the only way to make it show up is to click back and forth between tabs, or quit the app and re-open it. Sometimes, it will show up after one or two seconds, but that is still a bad user experience. When looking at logs during this issue, I can see that makeConfiguration still runs successfully and returns a value, so I suspect the issue is with the rendering of the View in the App Extension. 2. Gestures are slow to register, or can't register at all. For example, if I place my DeviceActivityReport inside a ScrollView, I cannot scroll if I perform the gesture on the report view. If I try to scroll on the part of the screen that's not inside the report view, the screen scrolls but it will lag. This makes me think that if I perform a gesture on the report view, only the view inside the App Extension will register the gesture, but not the parent view in my host app. Is that the expected behavior? My primary concern is number (1), it's by far the biggest pain point for my users and makes my app almost useless to them if they can't view their screen time :(. These issue have been reported before by other developers on the forum (https://developer.apple.com/forums/thread/723444, https://developer.apple.com/forums/thread/723491, https://developer.apple.com/forums/thread/720549). Instead of recommending that I submit a bug to Feedback Assistant (which I will do), I am kindly asking for some recommendations to work around the known performance issues of DeviceActivityReport. Several apps out there that use the DeviceActivity API that do not appear to have these performance issues, like Opal and Jomo, so they must be doing something right! One thing I've noticed is that the further up in the View hierarchy the DeviceActivityReport is, the better its performance, but I'm not sure why - maybe it is because the earlier the extension is connected to, the better. My app also has several tabs, makes network requests with asynchronous tasks on launch, uses the DeviceActivityMonitorExtension, and uses CoreData as a local data store. Maybe these things affect performance? Thank you in advance for any performance recommendations that you could provide!

I understand that the DeviceActivityMonitor extension is designed to be very lightweight, and the system terminates the extension as soon as its callback functions return. However, I want to save values to UserDefaults inside the extension's callback functions. This creates concurrency issues for my app because the documentation for UserDefaults states that "When you set a default value, it’s changed synchronously within your process, and asynchronously to persistent storage and other processes." In order to guarantee that these values are persisted before the extension terminates my app, I want to call UserDefaults.synchronize(), but its documentations states that it's "unnecessary and shouldn't be used." Furthermore, it's listed under "Legacy" but not marked deprecated. Is synchronize() the recommended way to solve my concurrency problem? Or could there be a better way to wait for storage synchronization before returning from a synchronous function?

Hello, I have an iOS app using the DeviceActivityReport app extension. Occasionally, the extension gets terminated (likely due to reaching memory limit**), which in turn disrupts the connection with the main app. How can the main app detect when the DeviceActivityReport extension has been terminated due to memory constraints, and what's the best way to re-establish the connection afterward? Thanks in advance for your insights and suggestions! ** I'm also unsure why the extension should be reaching its memory limit. When profiling the extension in XCode, it never reaches above 15MB, and I know the limit is 100MB. It's not doing anything out of the ordinary - and I've seen very similar complaints about DeviceActivityReport terminating on these forums. Any thoughts on how to prevent termination in the first place would also be super helpful!