iOS 26 regression: `DeviceActivityEvent`: `eventDidReachThreshold` called immediately (instead of waiting till threshold is reached)
Hello Albert!
I am experiencing some strange bugs around DeviceActivityEvents (part of the DeviceActivity framework) on iOS 26 / iOS 26.1 / iOS 26.2 beta:
When creating a DeviceActivityEvent we can assign a threshold and applicationTokens.
The idea is, that after the user has spent said threshold on said apps, eventDidReachThreshold() is called.
The property includesPastActivity is set to false.
On iOS 26 however, it happens (quite reliably after updating to a new beta seed) quite often that eventDidReachThreshold() is called immediately (after a couple of seconds) instead of waiting for the threshold to be met.
Is anyone else seeing similar issues on iOS 26 / iOS 26.1 / iOS 26.2 beta?
Only workaround I have found is to ask users to revoke and re-grant Screen Time permissions. This only holds for about two weeks though or at most until the next iOS 26 beta update is installed, so it is not a permanent solution unfortunately.
Feedback (incl. sysdiagnoses and sample project) is filed under:
- FB18061981
- FB18927456
One of our users has filed their own feedback request as well:
- FB20817853
Thanks a lot for any help on this!
Hey! Wondering if you got any resolution on this? We’re facing the same thing still :)
Wondering if you got any resolution on this?
Hey @ohadh123!
This might be fixed on iOS 26.5 beta 1, but we are still waiting for confirmation from Apple.
Since this bug is not consistently reproducible, I don’t want to be too quick to give green light here :)
Thank you for the post and sorry I missed it the first time. Also, thank you for providing the detailed context and for filing the Feedback reports (FB18061981, FB18927456, FB20817853) with sysdiagnoses. Having the sysdiagnoses from the exact moment the threshold fires incorrectly is exactly what is needed for the engineering teams to investigate the daemon state.
When includesPastActivity is false, the system is supposed to establish a fresh baseline for the event. If it fires immediately. The fact that revoking and re-granting Screen Time permissions temporarily resolves the issue aligns perfectly with this theory, as doing so clears the app's local Screen Time authorization state and forces the daemon to drop its cached data for your app.
May I ask to test the latest beta released to see if you can reproduce the issue using that build?
Your Feedback reports are in the system and routed to the correct team, however much work has been done and I wanted to make sure this is still an issue. Would you be able to let me know what versions of the beta and build number have you reproduce the issue?
Thanks
Albert Pascual Worldwide Developer Relations.
May I ask to test the latest beta released to see if you can reproduce the issue using that build?
Hey @DTS Engineer Albert!
Thanks a lot for getting back to me!
I’m currently in contact with the Screen Time team via my radar FB18061981 and they informed me that this specific problem should be resolved on the new iOS 26.5 beta 1.
I have not been able to reproduce the issue there. However, that does not mean that the issue has actually been fixed: the difficult thing about this bug is that it is not consistently reproducible. There are sometimes weeks where everything works fine…and then the issue hits back.
It’s only been one week with the new beta, so I don't want to be too quick to confirm the fix.
But at least so far it looks good. I’m just super confused why such a serious regression takes almost one year to get addressed – even though I filed bug reports directly in June 2025 on beta 1 of iOS 26.0…
For now I’m a bit hesitant to confirm the fix, especially because a similar screen time bug triggered the same notification for iOS 26.5 beta 1, and then it turned out the fix didn't make it into beta 1: FB18764644
@Quappi Thanks so much for your reply and providing me the FB numbers. Looks like the team has updated iOS 26.5 beta 1.
I comprehend that without extensive testing, on your end, it may be challenging for you to verify the fix. I would recommend monitoring the situation closely. However, I would encourage you to inform your customers when the release becomes available for download. I believe this are excellent news, and I observe that the team has diligently worked to ensure that the issue is being resolved and thoroughly tested. Nevertheless, please inform me if you encounter any issues after the release. I am confident that you will be satisfied with the fix.
Albert Worldwide Developer Relations.
I comprehend that without extensive testing, on your end, it may be challenging for you to verify the fix. I would recommend monitoring the situation closely. […] I am confident that you will be satisfied with the fix.
Hey @DTS Engineer – also on this thread: thanks a lot for your help and sharing more details!
So far we are carefully optimistic: since this is a semi-decidable problem™️ we can only confirm the bug fix if the bug does not occur over a longer period of time.
I’ll update my radars in case we can still reproduce on 26.5.