Submitted: https://feedbackassistant.apple.com/feedback/15776860
A more severe issue that may be related is that DeviceActivityMonitor is over-counting screen time for a large percentage of my users. I've detailed the issue at https://developer.apple.com/forums/thread/763542 - with other devs noting they have the same issue. I've also filed a bug report at https://feedbackassistant.apple.com/feedback/15103784 . PLEASE look into this, it renders DeviceActivityMonitor essentially unusable.
Post
Replies
Boosts
Views
Activity
Please file a bug report using Feedback Assistant, making Apple much more likely to address this growing issue!
Please file a bug report using Feedback Assistant, making Apple much more likely to address this growing issue!
Another Update: When troubleshooting with an affected user, after turning on "Share Across Devices," the screen time shown in Settings matched exactly the screen time indicated by the DeviceActivityEvents. Previously the user had this setting turned off, but events were still firing for thresholds triggered from her other devices. This helps to confirm my hypothesis that DeviceActivityMonitor is tracking screen time from other devices even when "Share Across Devices" is turned off for iOS 17.6
Seems like this happens when event thresholds are two close together. I have some thresholds that are an hour apart that usually deliver normally, however I have some that are ten minutes apart that recently get delivered together consistently.
I have not. My experience with Feedback Assistant has been poor, none of my bug reports ever get any replies. I simply avoided using @AppStorage variables in the DeviceActivityMonitor extension functions. This seemed to help at first, but have started breaking again with the release of iOS 17.2 without the use @AppStorage. I suspect it may be caused by any use of User Defaults at all. How does your app read / write data in the extensions?
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?
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.
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?
Having the same issue. Can't access the ticket, I'm getting "Feedback Not Found" - are there access restrictions?
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
Same thing is happening to me, please let me know if you solved it!
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.
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?
Hey Flybuys - let me know if you figure out a solution to that problem, it seems like a huge bug