Hello, I've been working with an app that leverages a DeviceActivityReport app extension. I want to ensure that the main app can gracefully handle scenarios where the connection to the app extension might get terminated unexpectedly. Can anyone guide me on how to detect from the main app when the connection to the app extension gets terminated? I believe being able to detect this would allow for better error handling and potentially reduce instances where the UI appears blank due to a lost connection. Thank you for any insights or advice on this topic.

Hello Apple Developer Community, We're experiencing a critical issue with the Screen Time frameworks, and it's affecting one of our users severely. I'm hoping someone here can provide guidance or a potential solution. Details: Our app offers a feature using the ManagedSettings shield that lets users block all apps based on a set schedule. After the scheduled block ends, the apps are expected to become accessible again. In one case, a user reported that the apps did not unblock after the schedule ended. Upon trying to manually end the session from within our app, the app only displays a blank white screen. The user attempted to disable Screen Time access for our app via the iOS settings, but the apps remained blocked. Even after completely disabling Screen Time from the settings or restarting the phone, the apps stayed blocked. Interestingly, I attempted to replicate the issue on my end by toggling Screen Time settings and restarting, but everything worked as expected and I could not reproduce the problem. This issue, though seemingly isolated, has rendered a user's phone virtually unusable, and highlights a potential high-impact bug within the Screen Time framework. It feels necessary for there to be a "master off-switch" or a fail-safe mechanism in these scenarios. Any insights, solutions, or workarounds would be deeply appreciated. It's crucial for us to support our user and resolve this promptly. Thank you in advance!

I'm encountering a problem with the DeviceActivityMonitor framework on iOS 17 that wasn't present in iOS 16. The app extension sends analytics events via the Segment SDK whenever the extension's functions are called. This setup worked flawlessly on iOS 16. However, since upgrading to iOS 17, it appears that the vast majority of my iOS 17 users are not triggering the expected analytics events. I'm aware that network requests in app extensions are not officially supported, yet somehow, Segment's SDK managed to function without issues in the previous OS version. Could there have been any changes in iOS 17 related to app extensions or the DeviceActivityMonitor framework that might be influencing this change in analytics behavior? Or perhaps there's a new restriction or modification in the app extension's network capabilities that I might be overlooking? Any insights into these changes or guidance on how to ensure analytics events are triggered reliably within the app extension on iOS 17 would be greatly appreciated. Thank you in advance for your help!

My app uses DeviceActivitySchedule to let users set schedules to block certain apps. I naturally want to understand how my users are using the feature, so I capture analytics events using Segment. Ever since the release of iOS 17.1, analytics events from DeviceActivityMonitor have stopped firing. I believe this is due to the fact that the app extension that DeviceActivityMonitor runs in does not support asynchronous network requests. (However, I'm not sure why the analytics were working correctly with iOS 16). What is the best way to capture analytics inside the DeviceActivityMonitor app extension in iOS 17?

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?

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?