How would you use Energy Log to investigate battery drain?

WHAT THIS TESTS: Your ability to operationalize a vague user complaint into an instrumented reproducible diagnosis. The interviewer wants to see that you treat battery as a metric not a mystery and that you understand how iOS subsystems map to energy cost.

A GOOD ANSWER COVERS: Four things in order. First setup attach Energy Log in Instruments to a physical device since simulator power data is not representative and reproduce the exact user scenario while recording. Second metric triage read the Energy Impact gauge and drill into the heaviest subsystem whether that is CPU Usage Location Services Network Activity or Bluetooth. Third correlation align timestamped spikes in those metrics with app actions by cross referencing the timeline against lifecycle events background task begin or end markers or specific user flows you instrumented with signposts. Fourth validation implement a targeted fix such as reducing location accuracy batching network requests or moving work off the main thread then capture a new Energy Log to prove the energy score dropped.

COMMON WRONG ANSWERS: Three red flags appear often. One suggesting users restart the phone or blaming iOS updates without gathering evidence. Two listing optimizations generically like enabling App Nap or reducing animations without first identifying which subsystem is actually responsible. Three profiling only on the simulator or in debug builds with optimizations disabled which produces misleading CPU and network numbers.

LIKELY FOLLOW UPS: The interviewer may ask how you would investigate a drain that only happens in the background how you distinguish between a high average energy cost and a rare but severe spike or how you would use os signpost to mark app specific events directly on the Instruments timeline. They might also ask about the energy cost of specific APIs such as significant location change versus standard location updates or how push notifications versus polling affect the radio power state.

ONE CONCRETE EXAMPLE: Suppose a user reports 20 percent battery loss per hour. You record an Energy Log during a navigation session and see Location Services pinned at high power while the app is in the background. You correlate the timestamp with a background refresh task that requests precise GPS instead of coarse location. You switch to kCLLocationAccuracyHundredMeters and defer updates with allowDeferredLocationUpdates then re profile. The new log shows Location Services dropping from a constant high band to intermittent low spikes and the hourly energy score falls by 70 percent.

Source: Apple Developer Documentation