Why App Blocker Limits Fire Instantly on iOS 26
If an app blocker locks your apps a few seconds after you set a daily limit, and your iPhone runs iOS 26, the app is probably not the problem. Apple’s DeviceActivity framework has an open bug that sends the “limit reached” signal almost at once. Developers have tracked it in one Apple forum thread since November 2025, and as of 4 October 2026 the original reporter still sees it on iOS 26.6 and iOS 27.
I build Sparky, a Screen Time app, and we hit this too. In June 2026 we moved Sparky’s relock off that signal and onto the clock. In three test sessions on iOS 26, it relocked about 2 seconds after the session ended. Sparky’s daily App Limits still use the signal, so Sparky is not immune.
What goes wrong when a limit fires instantly?
Apple’s tool for a usage limit is a callback. The app asks iOS to call
eventDidReachThreshold once you have used the chosen apps for a set time.
Apple defines that time as how long an app “is frontmost on the screen.” On
iOS 26 the callback sometimes arrives within seconds, before you have used
anything.
The main public report is
Apple Developer Forums thread 808470,
titled “iOS 26 regression: DeviceActivityEvent: eventDidReachThreshold called
immediately (instead of waiting till threshold is reached).” The original poster
had set includesPastActivity to false, so earlier usage should not count.
Quite often, they wrote, the callback was still “called immediately (after a
couple of seconds) instead of waiting for the threshold to be met.” They filed
Feedback reports FB18061981 and FB18927456, and one of their users filed
FB20817853. When I checked on 4 October 2026, the thread showed 17k views and
29 replies.
Why does a lock at the wrong moment matter?
The case for these apps rests on timing. In a field study by Grüning, Riedel and Lorenz-Spreen (PNAS, 2023), people closed the target app on 36 percent of their attempts when one sec’s pop-up interrupted, across 280 participants over six weeks. That pause lands at the moment of the reach. A lock that lands before any use interrupts nothing.
One caveat on that source: co-author Frederik Riedel built one sec, and the paper’s competing-interest note says “F.R. is the originator of one sec.” The finding still matters here because it is about friction at the moment you reach for an app. A limit that trips at random is not friction. It looks broken, and as we argued in app blockers vs time limits, a block that feels like it fights you tends to end in an uninstall.
Has Apple fixed the instant-firing bug?
Not for everyone, as of 4 October 2026. In April an Apple developer support engineer told the thread, “Looks like the team has updated iOS 26.5 beta 1.” In May he wrote, “I really thought the fix was on 26.5.” In August the original reporter replied: “this is still an issue we’re seeing on iOS 26.6 and iOS 27.”
The months in between are messy. One developer said the later 26.5 betas behaved, then wrote in May: “I just tested on the public release of iOS 26.5, and I experienced the issue again.” The original reporter said their analytics showed the early callback “firing a couple hundred times per day.” The thread has no accepted answer and no reply since August.
Apple’s release notes stay quiet. The iOS 27 release notes list one Screen Time fix: “Screen Time restrictions might not apply to child accounts despite being configured” (175437403). That is a different problem. The 26.5, 26.6 and 27.2 beta 2 notes do not mention DeviceActivity at all.
How can you tell the bug from a normal limit?
Timing gives it away. The iOS 26 bug fires within seconds of the limit being saved, or of the app restarting its monitor, while your usage is close to zero. A limit that trips after you really did scroll for the set time is working. Check the app’s usage number when the lock lands. Near zero means suspect iOS.
Two settings can look like the bug. The first is past activity. Apple’s
DeviceActivityEvent
has a switch, includesPastActivity, that controls “whether the system takes
into account the person’s device activity before your app starts monitoring the
event.” If an app turns it on, a 30-minute limit set at 6 p.m. counts your use
from earlier in the day. Spent 45 minutes on TikTok by lunch? It locks at
once, by design. We confirmed on a device on 11 June 2026 that it counts the
whole day’s use of the chosen apps, which is why Sparky leaves it off.
The second is a very short limit. A comment in Sparky’s code records that “DeviceActivity silently coalesces sub-minute thresholds,” so a limit finer than one minute is not measured to the second. A lock right after midnight can have other causes too, which we covered in the Habit Doom comparison.
What can you do about it today?
Three things help, and none is a cure. You can reset the app’s Screen Time access, which Apple’s engineer says clears the data iOS caches for that app. You can lean on clock-based schedules for the blocks you care about most. And you can update iOS, although the reporter still saw the bug on iOS 26.6 and iOS 27.
The reset is the workaround from the thread itself: revoke the app’s Screen Time access, open the app, and grant it again. Start in Settings, under Screen Time, where iOS 26.2 lists these apps in a section called “Apps With Screen Time Access.” The Apple engineer said a revoke “forces the daemon to drop its cached data for your app.”
The reset has two costs. The original poster found it “only holds for about two weeks though or at most until the next iOS 26 beta update is installed.” And it wipes your app choices. Apple’s FamilyActivitySelection page says that after a revoke, “any tokens that FamilyActivitySelection provided while your app was authorized are voided.” So you pick your apps again afterwards.
The schedule advice comes from the shape of the bug. Thread 808470 is about usage thresholds. Blocks that start and end at set times use a different callback, and the thread does not report problems with it. If one block truly matters, such as no feeds before 9 a.m., set it as a schedule instead of a usage limit.
How did Sparky stop trusting the threshold callback?
On 14 June 2026, we put Sparky’s relock on the clock. Sparky now arms one
DeviceActivitySchedule whose interval ends at the second your earned session
ends. In three test sessions on iOS 26, the gate
relocked about 2 seconds after that end. Sparky version 1.6 (build 30) ships
this change.
Two Apple rules shaped it. A schedule must last at least
fifteen minutes,
so the interval starts well before the relock and the short unlock rides its
tail. Both ends use hours, minutes and seconds only, because adding a day to
either end makes callbacks fire at once or never. The code lives in
AccessWindowMonitorScheduler.swift, and a comment there names thread 808470
as the reason for the switch.
Sessions in version 1.6 schedule no usage events at all. If an older build left a usage-based relock armed, the monitor ignores it unless the clock says the session is within 3 seconds of its end, or past it.
Is Sparky still exposed to the iOS 26 bug?
Yes, in one place. App Limits, a Pro feature in Sparky version 1.6, still count usage with the threshold callback, because a daily limit is about use, not the clock. If iOS fires early, Sparky gates those apps for the rest of the day, until you spend earned time. Version 1.6 has no guard against an early fire.
The clock fix has a cost too. A clock cannot tell whether you are scrolling. A Sparky session spends minutes while your gates are open, even with the phone face down, and the app says so up front: “Time runs by the clock while your gates are open.” Stop early and the unused minutes come back. Forget to stop, and they are gone.
One more quirk works in the other direction. Sparky’s code notes that when an
app restarts its monitor, iOS resets the usage count to zero. In Sparky, a
limit edited mid-day “grants the user the full new budget afresh” (from
AppLimitsService.swift). Lower a limit from 60 to 30 minutes after 45 minutes
of use, and you get 30 fresh minutes, not a lock.
Every iPhone app in our Opal alternatives list and our earned screen time guide sits on this same framework. If you report an instant lock to the developer, write down the time. Apple’s engineer said diagnostics “from the exact moment the threshold fires incorrectly” are what the engineering teams need, and the time is how a developer finds that moment.
Related reading
Sparky turns small habits into screen time you earn. Download it free on the App Store.