I've experienced the same thing consistently in my application. @foijodsf let me know if you've filed the bug and please link it here! It seems like there are apps that have been able to get around the lag (like Jomo for example, which never lags at all) - so there seems to be an existing way to anticipate the lag and re-render Scene. Kmart, could you shed any light on how to get around the frequent lag of DeviceActivityReport?

Thanks for your response! It helps a lot but still is not ideal. I made a reply to this post with my further struggles and code examples (since the comment only allowed me so many characters). Would love to hear any additional thoughts you have!

Thanks for the response! I'm not familiar with that rule or what it means - could you link to any documentation?

There are other apps that use DeviceActivityReport that are never laggy, like Jomo for instance. I wonder if there is some general performance guidance on how to leverage DeviceActivityReport's implementation and fit its use into an app with best possible performance?

Thanks for the response! A few questions: 1. Is there an estimated release date for the iOS version when this should be fixed? 2. By "deauthorize and re-authorize" the app, I assume you mean have the user revoke Screen Time access in the app's settings. This worked for some users, but did not work on my device (which is developer enabled). Is this a sure fix? 3. Since revoking Screen Time access is supposed to fix this, should this be a problem for new users?

Thanks for your response Kmart! While profiling the extension in Xcode, it maxes out at around 10MB on my device. I've also ensured that I'm looking at the extension target and not the host app. Could the memory usage vary that widely on other users devices that it could exceed 100MB while my device maxes out at 10? Or might there be something else going on?

Hey Flybuys - let me know if you figure out a solution to that problem, it seems like a huge bug

I'm storing timestamps of certain screen time thresholds with DeviceActivityMonitor. Whether or not this is its intended use, something is still off. DeviceActivityMonitor is part of an app extension that is invoked and terminated by the system. Once its functions return, the extension is immediately terminated, meaning there may be data in UserDefaults that never gets persisted. The also docs don't say it's a no-op just that it's "unnecessary" - but maybe it's necessary inside an app extension?

Thanks for the clarification! Is there a doc that says that? The docs I linked state that the data is persisted asynchronously. Also, the DeviceActivityMonitor extension is allowed to access UserDefaults, since it doesn't have access to granular screen time data like specific apps. It's the DeviceActivityReport extension that has these restrictions. Defaults set in the monitor extension are usually propagated to my app, but sometimes not, which led me to think it was a concurrency issue.

Same thing is happening to me, please let me know if you solved it!

Thanks for the reply! Already have reload capabilities in my app but it's still a terrible user experience for the report to show up blank so often. Seems like other screen time apps have been able to mitigate this issue mostly, but not sure what their workarounds are. I'm thinking of creating a group chat for iOS screen time devs to troubleshoot together since the APIs are still pretty buggy and it's hard to get answers from Apple. If you're interested, email me at screentimedev23 @ gmail.com

Having the same issue. Can't access the ticket, I'm getting "Feedback Not Found" - are there access restrictions?

I've been able to manually refresh the report UI by incrementing an id: @State var reportId = 0 ... DeviceActivityReport(context, filter: filter) .id(reportId) Button(action: { reportId += 1 }) { Text("Refresh") } However, what I really want to do is detect from the host app when the app extension or DeviceActivityReportService gets terminated, and then programmatically refresh the view. Has anyone been able to figure out how to detect termination of the extension?

I'm not - I saw your reply to https://developer.apple.com/forums/thread/741810 so I understand why you're asking that. I also make sure not to send notifications if intervalDidStart was called recently (indicating the schedule was re-started) and that has been tested thoroughly, so that is not the issue.

However, I do interact with UserDefaults in the callback functions. And sometimes actions that are meant to be performed in the callback functions do not occur, indicating failure. I think it's likely that the callback functions are failing at some point and being retried, and so notifications get sent multiple times. But it's very difficult to debug these situations because of limited access to the app extension. Any advice?