@kgaidis That's correct. Despite implementing all the requirements for utilizing CLMonitor as outlined in WWDC sessions and official documentation, there is a significant difference in the number of geofence event occurrences compared to the legacy CLCircularRegion API. This doesn't seem to be an issue limited to iOS 26.X only, but rather appears to be a difference in the API's internal behavior regardless of OS version.

In our existing code, when classes used NSCoder for decoding objects, we were calling decodeObject without specifying the of parameter and only performing type casting through the as? operator. Through the example code you provided, I believe we can now properly implement NSSecureCoding. Thank you for your assistance.

Hello, Thank you for your detailed response to my previous question. I understand that including all classes used within the app in the ofClasses parameter is not the correct pattern. Situation Update: Following your advice, I tested by including only the root object's class in ofClasses. Class X contains nested objects Y and Z. // Including only root object and some nested objects NSKeyedUnarchiver.unarchivedObject(ofClasses: [X.self, Y.self], from: data) Problem Encountered: However, I encountered the following error: Error Domain=NSCocoaErrorDomain Code=4864 "value for key 'anotherNestedObject' was of unexpected class 'Z'. Allowed classes are: { 'X', 'Y' }" The error was only resolved when I included class Z in ofClasses as well. Current Implementation Verification: Class X properly implements NSSecureCoding In the init(coder:) method, it individually decodes nested objects using coder.decodeObject(ofClass: Y.self, forKey: "nestedObject") and coder.decodeObject(ofClass: Z.self, forKey: "anotherNestedObject") Classes Y and Z also properly implement NSSecureCoding Question: Even though each class properly implements NSSecureCoding and individually decodes nested objects, why do I still need to include all nested classes in the root-level ofClasses parameter? Is this the intended behavior of the NSKeyedUnarchiver.unarchivedObject(ofClasses:from:) method, or is there a different implementation approach needed to apply the pattern where "you only have to list the class of the root object"? Thank you.

I have called startUpdatingLocation to prevent the app from transitioning to a suspended state while running in the background. Since GPS is continuously being received, I can confirm that the app is not being suspended. func locationManager(_ manager: CLLocationManager, didRange beacons: [CLBeacon], satisfying beaconConstraint: CLBeaconIdentityConstraint) { print(beacons) } When running the above code in an iOS 18 or later environment, beacon data is received in the background as long as the screen remains on. However, when the screen turns off, the beacons array becomes empty after about 2–3 seconds. Once the screen is turned back on, beacon data starts coming in again. In contrast, on iOS versions prior to 18, beacon scanning continues in the background regardless of whether the screen is on or off. Has there been an internal API change related to this behavior, or is this a potential bug?