Some other details: this looks to happen right when I open my device for the first time (after not using my phone for like 6+ hours)...theoretically there could be a chance that because "iOS is just waking up" (not 100% the case since the phone is on and charging) there's some odd bug where things go wrong using iOS 26.2 before RC seemed to be OK My hope is that this is just some odd side-effect due to my device state, but if it's not, it's critical for all Screen Time apps to test this & report.

same thing except for me it started happening with 18.4 or 18.5: FB17322530 iOS 26.1 seems to maybe have fixed it but there might be a new issue in iOS 26.2 RC (much worse?): https://developer.apple.com/forums/thread/809410

Also to add another data point on top: I switched my code (iOS 26) from CLMonitor to legacy CLCircularRegion and everything started working perfectly. Haven't had one issue. On the other hand, with CLMonitor I was questioning everything. I was doing deep research on what are the "hidden rules" on how quickly the enter/exit would fire, etc. CLCircularRegion just worked. (just in case: FB21142241)

Great post! Amazing detail. @parkjju If I understand what you are saying correctly, you are essentially saying that CLMonitor region monitoring in the background is not reliable? If so, I am also finding the same in iOS 26 at least. Sometimes it wakes up the app. Sometimes it does not. Similar notes here: https://developer.apple.com/forums/thread/768373?answerId=830944022&page=1#866073022

+1? does reverting to the deprecated API's helped?

for the same code (didn't change anything - just keep toggling same app code 1 minute apart): If I set alarm 1 minute later and lock the phone -> I see alarm go off and UI shows in Lock Screen with the alarm sound If I set alarm 1 minute later and do NOT lock the screen (looking at Home Screen while I wait) -> I get nothing (likely my app code is executing something though) without fail it does that behavior atm

Hi there, thank you for the response. At the moment, I am not 100% clear on what's going on so don't want to go through the process of filing Feedback. My "updated" understanding is that the alarm maybe does go off, but there's some special behavior if the phone is not locked (ex. its in "foreground") or app is in foreground while the alarm goes off. If I lock my phone, even with 1 minute differential I see the alarm go off. If I don't lock my phone, what maybe happens (at least I sometimes see it in debugger) is that the app runs to receive the "alerting" update (even if its technically in background?), but there's no UI anywhere showing that the alert is going off. Sometimes I do hear the sound (there's sound of alarm going off with no UI anywhere). I utilized open source sample code around AlarmKit and for that I do see the UI appear, where maybe it does because they implemented the custom widget? (but even their UI still shows inconsistencies depending on state of device/app) Of course I could be confused (surely am somewhat!), but my wish is that it would just always show UI (Lock Screen or "notification") / play sound, no matter what state there is.

@Engineer Ok apologies for the delay and thank you for listening to the feedback! ❤️ The feedback is: FB17108036

actually maybe its not related to "SFSafariViewController" and rather any full-screen View Controller presented on top causes this bug

(but I do want to note that thank you for continued tries at fixing FamilyActivityPicker 🙏)

Yes started in 18.4 AFAIK (not reproducible on 18.3.2)

Also if the "FamilyActivityPicker" is in a "crashed state" this does not happen.

Another example in Beta 3 (latest as we speak): ~3h screen time and it says multiple BANKING apps have 2h+ screen time at the same time. Updated feedback where maybe this is related to picture-in-picture (that being said, I did not spend 2h in all these banking apps while in Picture in Picture - just pointing out why the bug could be manifested...maybe in picture-in-picture it starts calculating everything wrong).

the youtube website is blocked as well (which is a good and intended behavior IMO) IMO given the numerous documented problems where blocking one thing accidentally blocks another (ex. blocking m.facebook.com blocks Messenger app), my vote is that we get rid of these sort of policies all together as sticking to a clear rule (doing X blocks X) is better than being ambiguous I could be wrong, but it also sounds like the root of your problem is this ambiguity. Where if it didn't exist, this wouldn't be an issue? So, if I understand correctly, there's a root issue to fix that would automatically solve this too. A very classic human/programming problem where the second-order effects of a unstable principle (blocking X also blocks Y) "exponentially" (being a little dramatic 😅) explodes to introduce new problems (exponential because you try to patch the Y problem, where then the patch can cause Z problem, etc. etc.)

Different, but similar vibe to "iOS 18.1 Screen Time shows private system resources" (FB15476753) so I assume there is some work happening around the area of screen time tracking All of this also affects the Settings > Screen Time tab too (not just third-party API)