Scheduled events reach threshold almost immediately on iOS 26.2

Thanks for the post, I’m not in that team but your post got me very intrigued, if you are experiencing this I would like to make sure you didn’t stumbled upon a critical bug with the DeviceActivityMonitorExtension and iOS 26.2. Is there a chance to see if you can reproduce this issue in the focused sample for experts here to see if you have found an issue or there is something the documentations could resolve for you?

A few recommendations on the time based issue. Start a background timer or polling mechanism that runs frequently (every second or few seconds is probably reasonable, or even sub second). Track the actual device usage time using timestamps - start when the app is launched and monitor the elapsed time. When your DeviceActivityMonitorExtension triggers prematurely, cross-reference the observed activity with the actual elapsed usage time measured by the continuous monitor. Check on those timers and the real time. Background timers can still be throttled or killed by the OS under memory pressure. Make certain you properly handle rescheduling scenarios. Consider waiting a few seconds between rescheduling attempts, as this might lessen the chance of encountering scheduling bugs. As the first workaround, use the smallest intervals possible to test this workaround with your app.

If the times are not what you expected and you see a discrepancy, then we can focus on bug reporting, detailed logging, monitoring, and trying the mitigation approaches mentioned to manage the problem.

However I’m confident that experts of that API will be able to jump into this thread after you provide the focused sample project and help you with the issue.

Albert Pascual
  Worldwide Developer Relations.

@sergey_nikitin

we noticed a huge issue: the events started to fire (reach the threshold) in the DeviceActivityMonitorExtension prematurely, almost immediately after scheduling.

This is a known issue in iOS 26, which is actively investigated.

I encourage you to file a Feedback report of your own using Feedback Assistant, then post the Feedback ID here.

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

I encourage you to file a Feedback report of your own using Feedback Assistant, then post the Feedback ID here.

Here is my feedback report: FB18061981

Make certain you properly handle rescheduling scenarios.

Hey Albert @DTS Engineer @DTS Engineer!

Thanks a lot for your input on this!

My bug report has been updated recently (FB18061981), and I have a follow up question:

Now that the Screen Time devs have figured out the root cause of this bug, is it feasible to re-schedule the DeviceActivityEvent from within the eventDidReachThreshold(…) callback if we detect that it was called too early?

We do have a workaround in place that dismisses the eventDidReachThreshold call if we detect that it was called unreasonably early:

let timeSinceSchedulingActivity = currentTimeStamp - timeStampOfSchedulingActivity

if timeSinceSchedulingActivity < 50 {
	// do not proceed to shielding the activity because this is not a real threshold callback, this is a bug!!!
	return
}

If we now, within this if condition, try to start a new DeviceActivityEvent that replaces the previous malfunctioning one, would that work?

Or would that automatically run into the same problem again?

I’m curious, because we are of course interested in providing a workaround until the fix is out & to provide a better-working version for the users that have not yet updated. Many of our users are afraid to update their iOS versions because historically more and more Screen Time bugs were introduced with every update instead of addressing previous bugs.