Mobile Development 9 min read

iOS Diagnostics Battery Testing and Optimization Guide

This article explains how to obtain iOS diagnostics battery data on iOS 10+ and iOS 9 devices, interpret the SQLite tables to measure app power consumption, and provides practical code and performance‑optimization tips for reducing energy usage in iOS applications.

Baidu Intelligent Testing
Baidu Intelligent Testing
Baidu Intelligent Testing
iOS Diagnostics Battery Testing and Optimization Guide

For a long time iOS provided only limited battery information, and the private API used for detailed data was blocked in iOS 9, forcing developers to find new ways to retrieve power usage metrics.

What is iOS Diagnostics? iOS Diagnostics is a built‑in system that records battery‑related data in a local SQLite database, which is periodically uploaded to Apple. The database contains per‑app energy consumption, allowing precise measurement of an app’s power draw.

How to obtain the diagnostics battery database (iOS 10+)

1. Download the BatteryLife.mobileconfig profile using a developer account: https://developer.apple.com/services-account/download?path=/iOS/iOS_Logs/BatteryLife.mobileconfig and install it via AirDrop or email.

2. Let the device sit for about 30 minutes, then sync it with iTunes.

3. Retrieve the database from the computer. The file is located at:

macOS: ~/Library/Logs/CrashReporter/MobileDevice/[Your_Device_Name]/

Windows: C:\Users\[Your_User_Name]\AppData\Roaming\Apple Computer\Logs\CrashReporter\MobileDevice\[Your_Device_Name]\

The battery database files start with Powerlog_ and end with .PLSQL or .PLSQL.gz .

How to obtain the diagnostics battery database (iOS 9 and below)

Use mitmproxy to intercept the diags://123456 URL and capture the request to https://iosdiags.apple.com/ios/TestConfiguration/1.2 .

Database interpretation and analysis

The SQLite database contains several tables, for example:

PLAccountingOperator_EventNone_Nodes

records all app

noteID

s

PLAccountingOperator_Aggregate_RootNodeEnergy

records energy consumption per

noteID

PLAppTimeService_Aggregate_AppRunTime

records app runtime, sampled hourly

PLBatteryAgent_EventBackward_Battery

records overall device power metrics (voltage, current, temperature) every 20 seconds

PLIOReportAgent_EventBackward_EnergyModel

records IO‑related energy (SoC, DRAM, IPS, etc.)

PLSpringBoardAgent_Aggregate_SBNotifications_Aggregat

records push‑notification timing and count

PLLocationAgent_EventForward_ClientStatus

records location‑related information

By joining these tables you can calculate the exact power consumption of an app during a specific time window, e.g., screen, CPU, GPU, Wi‑Fi, memory, and SoC contributions.

Example calculations show percentages and convert them to milliwatt‑hours using the formula W = U × I × t , yielding values such as 493 mWh for screen usage and 64 mWh for CPU.

iOS Diagnostics battery testing workflow

Install the system‑debug certificate, run the app under test, record the scenario timestamps, extract the diagnostics database, and evaluate each scenario’s energy consumption.

Battery‑optimization recommendations

1. Reduce the use of high‑cost objects like NSDateFormatter and NSCalendar . Cache frequently used formatters:

static NSDateFormatter *cachedDateFormatter = nil;
+ (NSDateFormatter *)cachedDateFormatter {
    if (!cachedDateFormatter) {
        cachedDateFormatter = [[NSDateFormatter alloc] init];
        [cachedDateFormatter setDateFormat:@"YYYY-MM-dd HH:mm:ss"];
    }
    return cachedDateFormatter;
}

2. Avoid frequent UI refreshes and unnecessary reloadData calls.

3. Choose appropriate collections: NSArray for index‑based access, NSDictionary for key‑based lookup, NSSet for unordered fast insert/delete.

4. Minimize layer masking and corner‑radius calculations; pre‑render images with rounded corners when possible.

5. Use lazy loading for subviews.

6. Optimize image handling: match image size to UIImageView , use full‑size images to reduce CPU work, or employ CALayer / CoreGraphics / OpenGL wisely.

7. Cache network responses and expensive computation results (e.g., table‑view row heights).

8. Reduce use of transparency, which incurs extra compositing cost.

9. Rely on ARC and set properties to nil in dealloc to avoid memory leaks.

10. CPU‑level tips: avoid overly short NSTimer intervals, limit thread count, keep heavy work off the main thread, optimize loops, and disable location/Bluetooth when not needed.

Author

Huang Lei , Senior Test Engineer, Baidu Search Ecosystem Quality Department, focusing on iOS product quality assurance for Tieba.

Mobile DevelopmentPerformance OptimizationiOSDiagnosticsBattery Testing
Baidu Intelligent Testing
Written by

Baidu Intelligent Testing

Welcome to follow.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.