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 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 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 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.