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 eventDidReachThreshold immediate-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 than eventDidReachThreshold? Until a fix, is a DeviceActivitySchedule-based (wall-clock) approach the only reliable path? Is applying a ManagedSettings shield from the DeviceActivityMonitor extension 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.

I'm building a consumer iOS app that helps users be more intentional about opening distracting apps. It never hard-blocks; it only nudges. I have Family Controls (Distribution) approved and a working TestFlight build using FamilyControls / DeviceActivity / ManagedSettings. I've confirmed from testing and the forums that: ShieldActionResponse is only .none / .defer / .close (no supported way to open my main app from the shield extension — threads 719905, 793060). ShieldConfiguration is a static snapshot (no countdown/animation; FB14237883). DeviceActivityMonitor events are threshold/schedule based and cannot hook "the app was just opened," and on iOS 26 eventDidReachThreshold fires immediately/incorrectly (thread 808470). I'd like to confirm the supported approaches for these UX patterns (each = every-app-open vs on-a-schedule): On app open, present my own full-screen UI (a brief non-blocking "pause") without requiring the user to manually create a Shortcuts personal automation. Is there any supported API for this, or is a user-created Shortcuts automation the officially recommended path? On app open, deliver a local notification (rather than UI) — supported only via a user-created Shortcuts automation, or is there another way? On a schedule / at fixed intervals, automatically bring my app's UI to the foreground (e.g., re-show a screen every N minutes) — I believe this is not allowed (apps can't self-foreground); can you confirm, and is a user-tapped notification the only path? On a schedule / at fixed intervals, send repeating local notifications while a usage limit is exceeded — given the iOS 26 eventDidReachThreshold regression, what's the recommended way to reliably detect "over limit" and drive repeating reminders? Some third-party apps appear to open their main app from a shield/monitor context. Is there any supported mechanism enabling that which I may have missed? I'd rather build on a supported path than risk anything review-sensitive. Guidance (or where to file an enhancement request) is appreciated. Thank you.