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?

The DeviceActivityReport is often laggy or sometimes doesn't show up at all. Quitting and re-opening the app usually fixes this problem. I'm wondering, is there a way to programmatically terminate and then re-launch the DeviceActivityReport App Extension from the host app? This way, that could act as a "refresh" when the DeviceActivityReport fails to show up.

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?

Within the DeviceActivity API, the documentation for DeviceActivityCenter.startMonitoring says: "Attempting to monitor too many activities or activities that are too tightly scheduled can cause this method to throw an error." Is there a documented limit of the amount of activities that are able to be monitored simultaneously? I understand that monitoring "too many activities" will throw an excessiveActivities error, but I can not find documentation that specifically identifies the conditions that this error can be thrown.

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

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!

I've asked several questions about DeviceActivity performance issues where the answers have cited limitations to the lifecycle of the DeviceActivity App Extensions. For example: Question about DeviceActivityReport lag and performance issues responded letting me know that my extension may be exceeding its memory limit of 100MB and subsequently getting terminated by the system. Question about async tasks in DeviceActivityMonitor responded letting me know that the monitor extensions lifecycle ends and is terminated by the system once all synchronous functions return, so it has no async support. I couldn't find either of these facts documented anywhere, and the DeviceActivity docs mention very little about how the extensions actually work. In general, it seems like these app extensions are basically a black box. Is there any additional comprehensive documentation about the true lifecycle of the app extensions, their limitations, and how apps should handle error cases (like the system terminating the app extension process)? If not, I would be very grateful if you could provide any information you have in the response to this question. Thanks in advance!

DeviceActivityReport view often shows up blank in the host app. What's the best way to refresh the view when this occurs?

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?

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.