Scheduled events reach threshold almost immediately on iOS 26.2

Question

Created 2w

Replies 2

Boosts 2

Participants 3

Hi, we are developing a screen time management app. The app locks the device after it was used for specified amount of time. After updating to iOS 26.2, we noticed a huge issue: the events started to fire (reach the threshold) in the DeviceActivityMonitorExtension prematurely, almost immediately after scheduling. The only solution we've found is to delete the app and reboot the device, but the effect is not lasting long and this does not always help. Before updating to iOS 26, events also used to sometimes fire prematurely, but rescheduling the event often helped. Now the rescheduling happens almost every second and the events keep reaching the threshold prematurely. Can you suggest any workarounds for this issue?

Answered by DTS Engineer in 875340022

@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.

Boost

Answer 1

DTS Engineer OP

Apple

2w

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.

0

Answer 2