Learn how to use the Energy Log template in Instruments to find what drains battery in your iOS app, from CPU and networking to location and the display.
Battery life is a feature users notice immediately. An app that drains the battery earns uninstalls and bad reviews, even when it is otherwise excellent.
Energy use comes from several subsystems working together. The CPU, networking, GPS and location, and the display all draw power, and an app can quietly overuse any of them.
The Energy Log template in Instruments helps you see this impact over time. It attributes energy cost to major contributors so you can target the worst offender.
The goal is not zero energy use, which is impossible. The goal is to make sure your app is not spending power on work the user did not ask for.
Energy problems often hide in background behavior, so plan a realistic test before you record. Decide whether you are testing active use, idle-in-foreground, or background activity.
A strong scenario reflects how real users behave. For example, leave the app idle on a screen and see whether it keeps the CPU or network busy when it should be quiet.
Profile on a real device for energy work. The simulator cannot meaningfully represent radio, GPS, and display power.
Make sure the device is in a normal state, neither plugged into power for charging analysis nor thermally throttled. You want everyday conditions.
In Xcode choose Product, then Profile, to create a profiling build. When Instruments opens, select the Energy Log template.
Confirm your app and device are set as the target. Then you are ready to record energy activity.
The Energy Log presents tracks for major energy contributors. You will typically see indicators for areas such as CPU, network, location, and display activity.
These tracks give you an at-a-glance sense of overall energy impact and which subsystem is responsible at any given moment.
Press record and run your planned scenario. If you are testing idle behavior, simply leave the app on screen and do nothing.
Watch the tracks as time passes. An app that is supposed to be idle but shows sustained CPU or recurring network spikes is doing hidden work.
Look for patterns. Regular bursts often indicate timers, polling loops, or animations that never stop.
Record long enough to capture the behavior you care about, since some energy issues only emerge over time. A short trace can miss a periodic wakeup.
Once you stop recording, identify which subsystem dominates the energy profile. The track that lights up most is your starting point.
If CPU is the culprit, pair the Energy Log with the Time Profiler to find the specific hot code. High CPU during idle almost always traces back to a busy loop or an over-eager timer.
If networking dominates, look for chatty requests, frequent polling, or retries. Batching requests and backing off retries can dramatically cut radio power.
If location dominates, check whether you are requesting high accuracy or continuous updates when you do not need them. Reducing accuracy and frequency saves significant energy.
Background activity is a common and sneaky energy drain. Verify that your app actually stops work when it moves to the background, rather than continuing timers or network calls.
Display-related energy can come from constantly animating views or preventing the screen from sleeping. Make sure you only keep the screen awake when genuinely required.
Wake-ups are expensive. Frequent small bursts of activity can cost more than a single batched burst, because they repeatedly wake the device's subsystems.
The overarching principle is to do work in efficient batches and then go quiet. Coalescing activity is one of the most effective energy strategies available.
Pick the single biggest contributor and make a focused change. For example, reduce polling frequency, lower location accuracy, or stop a timer in the background.
Profile again with the same scenario and compare the tracks. The subsystem you targeted should show clearly lower activity.
Be careful not to trade energy for broken functionality. Verify that the feature still works correctly after you throttle its activity.
Iterate one change at a time. Energy tuning is a balance, and confirmed, incremental improvements keep you from accidentally degrading the experience.
The cheapest energy bug is the one you never write. A few design habits prevent most of the problems the Energy Log would otherwise surface.
Prefer event-driven work over polling. Waiting for the system to tell you something changed is almost always cheaper than repeatedly asking on a timer.
Respect the app lifecycle. When your app moves to the background, wind down timers, animations, and network activity unless you have a genuine, declared reason to keep working.
For location and other sensors, request only the accuracy and frequency you truly need, and stop updates as soon as you are done with them.
Batch and coalesce network requests where you can, so the radio powers up, does meaningful work, and powers back down rather than waking constantly. None of this requires the profiler, but the Energy Log is how you confirm these habits are actually paying off in your specific app.
It also helps to test the unhappy paths. Poor network conditions, a weak signal, or a server that is slow to respond can quietly multiply energy cost as your app retries and waits. Profiling under those conditions, not just on fast Wi-Fi, gives you a far more honest picture of what real users will experience on the move.
Energy Log gives you relative insight and trends, not a perfect joule-level accounting of battery use. Treat it as a guide for finding the worst offenders, not as a laboratory-grade meter.
Real-world battery life depends on factors outside your app, including the device model, signal strength, and what else is running. Your measurements are most useful as before-and-after comparisons of your own changes.
Measure on representative hardware and avoid drawing conclusions from a single noisy run. Repeat your scenario to confirm patterns.
And as always, the Energy Log applies to compiled native apps. If your product is web output from an app builder rather than native Swift, you would first compile a true native build in Xcode before this template becomes meaningful.
No, energy profiling needs a real device. The simulator cannot represent the radio, GPS, and display power characteristics that matter for battery life.
Switch to the Time Profiler to find the specific code running during idle, which is usually a busy loop or an over-eager timer. Then stop or throttle that work when the app is idle or backgrounded.
Sustained CPU work, chatty networking, continuous high-accuracy location, and constant animations or keeping the screen awake. Batching work and going quiet between bursts helps with all of them.
It is best treated as relative guidance for finding the worst contributors, not a precise joule-level meter. Use it for before-and-after comparisons of your own changes.