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.

Will also stay on the lookout for if the bug returns over the next few weeks on 26.5! This fix is super critical for our users as well

Thank you for your post. Have you had the opportunity to test the latest iOS 26.5 beta 2 on the download site since yesterday on all your active devices that are signed into family accounts?

Please let me know how it goes.

Albert  WWDR

Hello Albert!

Thanks a lot for getting back to me!

Have you had the opportunity to test the latest iOS 26.5 beta 2 on the download site since yesterday on all your active devices that are signed into family accounts?

Indeed, we are quite positive that this has been resolved. It’s now been more than two weeks and I was not able to reproduce the issue in that time.

I just wanted to take a moment to prevent any misunderstandings: This issue is not about family sharing features such as screen time management of an underage family member.

Our app is targeted at individuals who want to manage their own Screen Time. Does this bug fix still apply?

We’re using this permission to set up the app:

import FamilyControls

try await AuthorizationCenter.shared.requestAuthorization(for: .individual)

– Frederik 🐻‍❄️ one sec app

@Quappi Thanks for explaining it that is about the age instead of the the family sharing features. Do you have a focused sample project as well as a target geo location? This is not one of my well known frameworks, so I would recommend to frame it on the title with DeclaredAgeRange using a new post and providing the focused sample.

Looking forward for our engineers to see it!

Albert
  Worldwide Developer Relations.

that is about the age instead of the the family sharing features

Sorry, I’m confused @DTS Engineer Albert. This is neither about age range nor about family sharing features.

This issue is (as described in my initial post) about DeviceActivityEvents firing their eventDidReachThreshold callback immediately instead of after the defined threshold.

Hope that helps!

@Quappi I'm the confused one.

Provide a focused project showing what you trying to accomplish and that the API is doing currently.

However you FB numbers you are in contact with the correct team, I would wait for their answer about your questions on that bug report.

Albert
  Worldwide Developer Relations.

Provide a focused project showing what you trying to accomplish and that the API is doing currently.

Thanks @DTS Engineer Albert for your response.

I believe it’s currently not required to add an additional sample project, as the Screen Time team has informed me that the issue is most likely resolved in iOS 26.5 beta. So far I wasn't able to reproduce the issue anymore.

I was just confused by your comment above that mentioned updating all devices signed into a family account, since we also reproduced the issue on devices where the user’s own screen time was managed compared to an underage family member. The bug might apply to families managing their kids’ screen time as well, but we don’t have that use-case in our app.

Anyway, I hope this all doesn't matter anyway since the bug is hopefully addressed!

iOS 26 regression: `DeviceActivityEvent`: `eventDidReachThreshold` called immediately (instead of waiting till threshold is reached)
 
 
Q