Following up on my earlier thread about non-blocking interventions. I ran a clean, isolated test on iOS 26.5.2:
I start DeviceActivityCenter.startMonitoring with a single event whose threshold is 2 minutes of usage
for a selected app (includesPastActivity = false), with actions on eventDidReachThreshold. Result:
the event's recorded trigger time is +0 seconds from monitoring start (immediate), it fires without any
real usage, and after 2 minutes of actual use no notification and no ManagedSettings shield are applied.
This matches the regression discussed in Forum thread 808470 / FB18061981.
Concretely, the feature we want to build: while a user is using a selected app, deliver a repeating local
notification every N minutes of usage (e.g., every 15 minutes) whose body states how many minutes they've used
that app today (e.g., "You've used TikTok for 45 minutes today"). This is a gentle, factual awareness nudge — no
blocking. This is exactly what eventDidReachThreshold with multiple thresholds (15/30/45 min…) + sendNotification
would do, but that path is broken by the regression above.
Questions:
- Is there a fix timeline for the
eventDidReachThresholdimmediate-fire regression (iOS 26.x)? Any FB to watch? - What is the supported way to implement the feature above — a repeating notification every N minutes of
usage, containing the cumulative minutes used today for that app — without relying on the broken threshold
event? Specifically:
a. How should we obtain the cumulative usage minutes for a selection to put in the notification body? Is the
only source a
DeviceActivityReport(which renders in an extension and isn't readable as a value in the app)? b. How should we trigger every N minutes of usage if threshold events are unreliable? Is there any usage-based trigger other thaneventDidReachThreshold? - Until a fix, is a
DeviceActivitySchedule-based (wall-clock) approach the only reliable path? Is applying aManagedSettingsshield from theDeviceActivityMonitorextension expected to interrupt an app that is already in the foreground (mid-use), or only at next launch?
Our app is non-blocking by design (a brief "pause" nudge + factual usage reminders), fully on-device, Family Controls (Distribution) approved. We'd rather build on a supported path. Thank you.