Hi poolii, I have now captured a sysdiagnose while the problem was occurring, and the logs contain some interesting evidence. My app uses a named CLMonitor with BeaconIdentityCondition, not the deprecated CLLocationManager.startMonitoring(for:) API. The recorded sequence was: At 07:01:20, bluetoothd detected the configured iBeacon and logged Entered zone. Immediately afterward, CLMonitor correctly delivered a .satisfied event. No corresponding Exited zone for that beacon appeared afterward. When the app reopened the existing monitor at 08:40:35, locationd still reported: clientState: Satisfied daemonState: Satisfied newDaemonState: Satisfied At the same time, the logs showed: RegistrationResult: AllowedAlways DiagnosticMask: 0 Both monitoring conditions were still registered, the CLServiceSession was active, Always authorization was granted, and the CLMonitor event stream reported no error. This suggests that the stale state already existed inside locationd. The app and CLMonitor client were not merely displaying an outdated app-side value — the daemon itself still considered the beacon condition satisfied and therefore generated no exit transition. The issue was captured on iOS 26.6, build 23G71.

Hi! Sorry, I thought you are using CLMonitor directly. The investigation by Apple has been finished because the provided information seems to be not sufficient for a diagnose. When I deactivate the location services for my app only, it's still not working. I'll give it a try to get sysdiagnose information.

Hi, I am experiencing almost the same issue with my app, but it already appeared with iOS 26 and remains with 26.6. I filed a bug today. After resetting Location Services or restarting the iPhone it usually works again. CLMonitor doesn’t get new events out of nowhere even if the iPhone has been next to the iBeacon for hours.