iOS 26.2 RC DeviceActivityMonitor.eventDidReachThreshold regression?

Hi there,

Starting with iOS 26.2 RC, all my DeviceActivityMonitor.eventDidReachThreshold get activated immediately as I pick up my iPhone for the first time, two nights in a row.

Feedback: FB21267341

There's always a chance something odd is happening to my device in particular (although I can't recall making any changes here and the debug logs point to the issue), but just getting this out there ASAP in case others are seeing this (or haven't tried!), and it's critical as this is the RC.


DeviceActivityMonitor.eventDidReachThreshold issues also mentioned here: https://developer.apple.com/forums/thread/793747; but I believe they are different and were potentially fixed in iOS 26.1, but it points to this part of the technology having issues and maybe someone from Apple has been tweaking it.

Answered by DTS Engineer in 874099022

@nemecek_f

This is a known issue that is currently being investigated.

If you have already filed a bug report for this issue, thank you.

If you have not filed a bug report for this issue we encourage you to do so via Feedback Assistant (https://feedbackassistant.apple.com). For more information on Feedback Assistant, please visit https://developer.apple.com/bug-reporting.

By filing a bug report, you’ll be able to track the issue, update Apple Engineering with additional information, and get notified of problem resolution

Some other details:

  • this looks to happen right when I open my device for the first time (after not using my phone for like 6+ hours)...theoretically there could be a chance that because "iOS is just waking up" (not 100% the case since the phone is on and charging) there's some odd bug where things go wrong
  • using iOS 26.2 before RC seemed to be OK

My hope is that this is just some odd side-effect due to my device state, but if it's not, it's critical for all Screen Time apps to test this & report.

I’m curious what you mean with that. im also sometimes under the impression that my device is cursed when it comes to screen time, because there are so so many bugs. But then again, it’s not just me: we get user reports every day with complaints about bugs related to the Screen Time API.

odd side-effect due to my device state

got it again:

  • today it was all the limits once more
  • few days ago it was just some of the limits

the behavior is the same:

  • first device pick up of the day (didn't even open the app), and immediately limits get activated

I'm not sure if this is any different than the bug here: https://developer.apple.com/forums/thread/793747

BUT I only started getting THIS specific behavior in 26.2 RC...so maybe it is new?

Just got a user email from iOS 26.2 that looks like this bug

(Again, I'm not sure if this is any different than the bug here but sounds different due to the explicit start on iOS 26.2 and that its strictly a beginning-of-the-day-thing: https://developer.apple.com/forums/thread/793747)

Confirming a very similar issue on iOS 26.2 (23C55).

In my case, DeviceActivityMonitor.eventDidReachThreshold fires when iOS Screen Time shows 0 minutes for the selected apps for that day, and ManagedSettings shielding applies immediately after the callback. It’s intermittent (some days no occurrence; other times multiple days in a row) and often happens after the device has been idle/locked for hours. However, I haven’t personally seen it specifically on first device pickup / first unlock yet.

I filed Feedback Assistant with sysdiagnose + Screen Time screenshots + log excerpt showing UsageTrackingAgent notifying the extension that the event reached threshold: FB21450954.

Quick questions to help narrow this:

Do you also see this on a device with no other Screen Time/blocker apps installed?

Are you restarting monitoring at interval boundaries (e.g., midnight) or setting includesPastActivity explicitly?

Hopefully Apple can correlate FBs and confirm a 26.2 regression.

Update: Found a possible reproduction pattern correlated with plugging the device into power. Reproduced again on a device with no other Screen Time/blocker apps installed besides my own. Attached a second sysdiagnose in my feedback: FB21450954.

Observed behavior: DeviceActivityMonitor.eventDidReachThreshold fires even though iOS Screen Time shows 0 minutes for the selected app that day (verified in Settings > Screen Time), and my extension applies ManagedSettings shielding immediately after the callback.

Possible repro pattern:

iOS 26.2 (23C55). Daily schedule 00:00–23:59.

Do not open the selected app(s); leave device idle/locked for hours (0 usage).

Plug the device into power while it remains locked/idle.

Within minutes, eventDidReachThreshold fires despite 0 Screen Time minutes.

Hello,

we have reported this concerning bug with the first beta of iOS 26 in June 2025.

Apple has not yet addressed this bug, neither do they have acknowledged that anyone has taken a look at it.

I believe this is yet another confirmation that Apple is not interested in maintaining the Screen Time framework – it’s now in a state where it’s barely usable to build stable apps.

here are my feedback number for reference:

  • FB18927456
  • FB18061981

feel free to cross reference those in your feedback reports!

Found a possible reproduction pattern correlated with plugging the device into power

I think you may be onto something with this as I maybe am also reproducing it easier if I pick-up my phone while it's plugged in. Still happening on iOS 26.3 beta.

Thank you everyone for participating :)

Regardless of these new issues, I've felt like the Screen Time framework has been getting more stable since iOS 16 so I do want to thank the Apple engineers for that.

Hi all, Same behavior described in https://developer.apple.com/forums/thread/812472 We have hundreds of users affected, also in 26.3 beta.

Any info gathered I'll share on my thread

as an update, it's not just third-party apps, this problem affects even the "native" Apple Screen Time "App Limit" feature; Reddit is full of threads of people complaining about this starting with iOS 26.2

We are also noticing issues with this, very likely since iOS 26.0.

It seems to be connected to device being on charger - happened on my device two times already.

My guess is that the charger makes the system run some background tasks for Screen Time and they incorrectly call that eventDidReachThreshold method.

Accepted Answer

@nemecek_f

This is a known issue that is currently being investigated.

If you have already filed a bug report for this issue, thank you.

If you have not filed a bug report for this issue we encourage you to do so via Feedback Assistant (https://feedbackassistant.apple.com). For more information on Feedback Assistant, please visit https://developer.apple.com/bug-reporting.

By filing a bug report, you’ll be able to track the issue, update Apple Engineering with additional information, and get notified of problem resolution

iOS 26.3 beta 3 might have a new (arguably worse?) behavior where instead of all limits blocking instantly on DEVICE pickup, each limit blocks instantly separately only when you open the app

so if you have two separate limits (YouTube and Instagram), YouTube will block when its opened for the first time while leaving Instagram unaffected, until you open Instagram for the first time (where then that will also instantly block)

iOS 26.3 RC does not seem to fix the problem

I have been using iOS 26.4 and haven't gotten the misfire to happen yet... Looking stable so far.

Yes, same here. iOS 26.4 looking stable so far. Thank you for the fixes Apple devs 🙏

Unfortunately, just got the latest 26.4 beta 3(?) that released yesterday and am again getting the problem.

iOS 26.4 (23E5223f)

I've also confirmed that the same issue occurs on 26.4 beta 2 and beta 3.

Thanks for the updates, we’re seeing the same kind of “misfire / immediate threshold reach” behavior reported by our users as well (blocked even when they haven’t used the app yet), so it’s helpful to know it’s still reproducible on the latest 26.4 betas.

Could you share how you reproduce it reliably?

  • What schedule / threshold configuration are you using?
  • Does it happen right after starting monitoring, after a reboot, or after an OS update?
  • Any pattern around downtime / always-allowed / exempt lists?
  • Device model + exact iOS build (e.g., 23E5223f) when it reproduces?

Any concrete steps would be greatly appreciated.

Unfortunately, I don't have a way to reproduce this 100% reliably, but here are the steps that most often trigger it:

  1. Set up the usage limit first — configure a usage time limit of 1 minute or more before connecting the charger.
  2. Then plug the iPhone into a charger — the issue tends to appear shortly after charging begins.

That said, it seems to only trigger once per day — I haven't been able to get it to fire a second time on the same day.

  • Device model: iPhone 16
  • iOS build: 23E5223f

Thanks a lot for confirming that this is currently investigated! Can you say when this will be addressed?

I have reported this horrible regression in iOS 26 beta 1 in June 2025. It’s kinda sad that this didn’t seem to have any priority for Apple to get addressed before the public version was released.

In 3 months this bug report will be one year old.

This is a known issue that is currently being investigated.

If you have already filed a bug report for this issue, thank you.

unfortunately, iOS 26.4 (final version) also has the bug

that's iOS 26.2, iOS 26.3 and iOS 26.4 (3-4 months) of limits automatically activating most mornings without reaching the limit, and this also affects the default Apple Screen Time

Also having this same issue.

Checking in here as we're facing this in our app as well. Would greatly appreciate if this could get prioritized! A lot of our users are frustrated

How are people doing on iOS 26.5?

So far so good, but this happened with the first 26.4 release too: it seemed to be fixed, but then (maybe) something got reverted.

iOS 26.2 RC DeviceActivityMonitor.eventDidReachThreshold regression?
 
 
Q