1. The Inquiry Hello, I have been implementing a background geofencing feature and, during testing, I found a significant numerical difference in event callback frequency between the older CLCircularRegion API and the newer CLMonitor API (CLMonitor.CircularGeographicCondition), introduced in iOS 17. My testing was strictly conducted using the "Always Allow" location permission (requestAlwaysAuthorization()). I used both APIs in parallel under identical geofencing conditions and within the same implementation environment. Since a clear difference persists in the data, I suspect this may stem from structural differences in the internal mechanisms of the two APIs rather than an implementation error on my part. 2. Environment and Implementation Details (Proof of Integrity) I have ensured that my implementation adheres to Apple's guidelines and uses modern Swift concurrency features. A. Development Environment and Permissions iOS Version: iOS 18.x and later Xcode Version: Version 17A400 (Version 26.0.1) Location Authorization: Always permission obtained. Background Mode: Location updates is configured correctly in Info.plist. B. CLMonitor Initialization and Lifecycle I implemented robust lifecycle management to ensure CLMonitor is stable and persists correctly: Initialization: I performed CLLocationManager object allocation and related service setup (e.g., CLServiceSession set to always) within the call stack frame of didFinishLaunchingWithOptions. Monitor Management: I use an Actor-based Singleton pattern to guarantee that only a single CLMonitor instance is used application-wide. Event Monitoring: Following initialization, I allocated a background Task containing the for try await event in await monitor.events loop. This Task is explicitly managed to persist in the background until the application is terminated, ensuring continuous event listening. C. Registration Limit Management I manage both APIs to ensure they never exceed the recommended maximum of 20 simultaneously monitored regions/conditions. My logic removes the oldest item (LRU) when the limit is reached. The average registration counts during the test period were highly similar: Component Average Registered Count CLCircularRegion count 7.02 CLMonitor.CircularGeographicCondition count 7.04 This confirms that registration count is not the cause of the event frequency difference. 3. Data-Based Observation The test data (bubble_test_data_for_apple_forum.csv) records the event callbacks for both APIs under identical conditions: Component Total Count Percentage of All Events (%) CLCircularRegion Delegate Total Calls 617 83.56% CLMonitor Event Total Fires 122 16.44% Overall Total Count 739 100% A. Key Findings CLCircularRegion Operability: 617 calls confirm that core implementation factors (permissions, background setup, etc.) are functioning correctly. Disparity in Frequency: Despite running in parallel, the CLMonitor event count (122) is approximately 1/5th the frequency of the CLCircularRegion calls (617). Efficiency per Registration: CLCircularRegion averaged ~0.86 calls per registered item, while CLMonitor averaged only ~0.17 calls per registered item. 4. Questions for Apple Engineering Based on the robust implementation and the data presented, I request a review of the following potential differences between the APIs: Internal Mechanism Differences: Are there structural differences in how CLCircularRegion and CLMonitor.CircularGeographicCondition process and schedule geofencing event callbacks? For instance, do they differ in terms of battery optimization priority, event batching, or internal throttling mechanisms? CLMonitor Event Ratio: Is the phenomenon where CLMonitor records a significantly lower ratio of events compared to CLCircularRegion an intended behavior, or could this be indicative of a specific environmental factor that affects the newer API differently? Thank you for your time and assistance. geofence-test-data.csv

Hello, I have a question about data deserialization using NSKeyedUnarchiver in iOS SDK development. Current Situation: Previously, we were using the NSKeyedUnarchiver.unarchiveObject(with: Data) function We have changed to using the NSKeyedUnarchiver.unarchivedObject(ofClasses:from:) method to deserialize complex objects stored in UserDefaults We need to include all types in the ofClasses parameter, including Swift primitive types as well as various custom classes and structs within the project Questions: Implementation Approach: Is it correct pattern to include all classes defined in the project in the ofClasses array? Is this approach recommended? Runtime Stability: When using this approach, is there a possibility of runtime crashes? Are there any performance issues? Alternative Methods: If the current approach is not the correct pattern, what alternatives should we consider? Current Code Structure: All model classes conform to the NSSecureCoding protocol We use the requiringSecureCoding: true parameter We use a whitelist approach, explicitly listing only allowed classes I would like to know if this structure is appropriate, or if we should consider a different approach. Thank you.

I'm currently testing the CLMonitor API and have a question about CLServiceSession management. When my app is relaunched from a terminated state in the background due to CLMonitor events, do I still need to create and maintain a CLServiceSession instance? I'm wondering if CLServiceSession is necessary even when I don't need to continuously receive GPS updates through liveUpdates. Since CLMonitor can trigger app launches for region monitoring events without requiring constant location updates, I'm unclear about whether the CLServiceSession is still required in this scenario. Any clarification on the proper implementation would be greatly appreciated. Thanks!

Hello, I have recently been using the new Power Profiler tool introduced in Xcode 26 to analyze the power consumption of my app. My app primarily operates in the background. During a profiling session of 5 hours and 30 minutes, I observed that the app was active in the background for 2 hours and 30 minutes, while it remained in a suspended state for the remaining 3 hours. While the Power Profiler allows me to identify spikes in CPU, networking, and other resource usage at specific points, it is difficult to determine whether these values are objectively considered high. For example, in my case, the total QoS Execution Time of CPU Impact recorded during the 5 hours and 30 minutes was 12.18 seconds. I am wondering whether this is considered a good metric. Could you please advise on the following points? 1. Is there a commonly accepted or recommended ratio between app active time and CPU time that developers should aim for? 2. Are there any guidelines or reference materials on how to interpret CPU usage and other resource metrics for apps that primarily run in the background? Any insights or advice would be greatly appreciated. Thank you.

Hello, I have a question regarding the new battery usage interface in iOS 26. As shown in the attached screenshot, the system displays battery usage per app as a percentage (%). I’m curious about how this percentage is calculated. From what I can tell, it doesn’t seem to reflect the actual battery consumption per process, excluding the device’s base standby power. It rather appears to be calculated as a relative percentage based on total battery drain, possibly including system idle power. Is there any way to understand or estimate the actual battery usage per app, excluding the device’s inherent standby power consumption? Thank you.

Hello, I am currently developing an iOS SDK, and I would like to clarify the allowed use of MetricKit, specifically regarding the MXAppRunTimeMetric.cumulativeBackgroundTime value. My SDK tracks app lifecycle events for analysis purposes. I am considering sending the cumulativeBackgroundTime metric to my own backend server to monitor background usage patterns across different devices. Before proceeding, I want to confirm: Is it compliant with Apple’s App Store Review Guidelines to collect cumulativeBackgroundTime via MetricKit and transmit that data to my server? I understand MetricKit is primarily intended for performance monitoring and local analysis, but since this is a runtime metric, I would like to verify whether off-device aggregation is acceptable. I would appreciate any clarification regarding policy boundaries or best practices for this scenario. Thank you in advance!

Hello, I’m currently working on migrating an existing AppDelegate-based application to use the scene-based life cycle, as recommended in the TN3187 technical note. As part of this process, I’ve been conducting some tests. After completely removing the scene-based setup (i.e., removing the UIApplicationSceneManifest from Info.plist and deleting SceneDelegate.swift), the app runs in a legacy AppDelegate-only life cycle as expected. In this case, lifecycle methods such as applicationWillEnterForeground and applicationDidEnterBackground in the AppDelegate are called properly. SceneDelegate methods are, naturally, not called—since the class is removed. However, here’s where the confusion arises: Even in this AppDelegate-only configuration, if I register for UIScene notifications via NotificationCenter, the corresponding selectors are invoked at runtime, which suggests that UIScene lifecycle notifications are still being broadcast internally by the system. Below is the test code I used, along with console output: func addObserver() { NotificationCenter.default.addObserver(self, selector: #selector(appDidEnterBackground), name: UIApplication.didEnterBackgroundNotification, object: nil) NotificationCenter.default.addObserver(self, selector: #selector(appWillEnterForeground), name: UIApplication.willEnterForegroundNotification, object: nil) if #available(iOS 13.0, *) { NotificationCenter.default.addObserver(self, selector: #selector(sceneDidEnterBackground), name: UIScene.didEnterBackgroundNotification, object: nil) NotificationCenter.default.addObserver(self, selector: #selector(sceneWillEnterForeground), name: UIScene.willEnterForegroundNotification, object: nil) } } @objc func sceneWillEnterForeground() { print("sceneWillForeground") } @objc func sceneDidEnterBackground() { print("sceneDidEnterBackground") } @objc func appWillEnterForeground() { print("appWillEnterForeground") } @objc func appDidEnterBackground() { print("appDidEnterBackground") } sceneWillForeground AppDelegate::willenterforeground appWillEnterForeground So, my question is: Even in an AppDelegate-only app running on iOS 13 or later, is it expected behavior that UIScene lifecycle notifications such as UIScene.didEnterBackgroundNotification and UIScene.willEnterForegroundNotification are still posted by the system? === Additional Question: The TN3187 note lists only four methods to migrate between AppDelegate and SceneDelegate. Are there any other lifecycle methods (beyond the four listed) that also require manual migration during this transition? Thank you in advance for your insights.

I kept CoreLocation’s startUpdatingLocation running for a full day and used Performance trace - PowerProfiler to track the power usage during that time. The trace file was successfully generated on the iOS device, and I later transferred it to my MacBook. However, when I tried to open the .atrc file, I received the following warning: The document cannot be imported because of an error: File ‘/Users/jun/Downloads/PowerProfiler_25-06-16_181049_to_25-06-17_091037_001.atrc’ doesn’t contain any events. Why is this happening? Is there a known issue with PowerProfiler in iOS 26, or am I missing something in the tracing setup? Note: The .aar file and the extracted .atrc file are not attached here, as forum uploads do not support these formats.

Issue Summary After calling startRangingBeacons, the didRangeBeacons delegate method does not receive iBeacon scan data when the device display is turned off in the background. Expected Behavior On iOS 17.2.1 (iPhone 14), beacon ranging continues in the background even when the display is turned off. The same behavior is expected on iOS 18, but it is not working as intended. Observed Behavior On iOS 18, once the display turns off, beacon ranging stops, and the didRangeBeacons method is not triggered until the display is turned back on. • Location permission is set to “Always Allow.” • Background Modes are correctly configured (Location Updates enabled). Steps to Reproduce Ensure location permission is set to Always Allow. Enable Background Modes → Location Updates in Xcode settings. Call startRangingBeacons(in:) in the app. Put the app in the background and turn off the display. Observe that didRangeBeacons is not triggered while the display is off. Additional Notes • The issue does not occur on iOS 17.2.1 (iPhone 14), where beacon ranging continues even with the display off. • This behavior change is observed on iOS 18 across multiple devices. Could you confirm if this is an intended change in behavior or a bug? If this is expected behavior, what alternative approach is recommended to maintain continuous beacon ranging when the display is off in the background?

When I set the values of notifyOnExit and notifyOnEnter to true when registering CLCircularRegion, I checked that the didExitRegion and didEnterRegion functions are called well. However, there is a problem that they are called twice in a row every time they are called. I was wondering if this is an internal bug in the API. There is also a stackoverflow report related to the above issue. I would appreciate your confirmation. stackoverflow - why the didEnterRegion called twice? Thank you.

According to WWDC sessions, the recommended approach for continuing location collection in the background with liveUpdate is by using CLBackgroundActivitySession. In the app I’m currently developing, I call the invalidate function on the backgroundActivitySession instance when the app enters a terminated state. Then, when the app is resurrected due to startMonitoringSignificantLocationChanges, it reinitializes liveUpdate to resume location collection. When initializing CLBackgroundActivitySession, I also reinitialize the liveUpdates object to ensure the CLLocation.Updates instance is refreshed. However, regardless of the order in which I refresh these two instances, location collection does not resume when the app is revived in the background. Should the originally created CLBackgroundActivitySession instance never be invalidated? Any guidance on whether I am implementing this correctly would be greatly appreciated.