Battery and Performance Profiling for Long-Running Mobile Features
A fitness tracking client's run-tracking feature was draining battery at roughly 18% per hour of active use, which was pushing users to complain in app store reviews and, worse, abandon tracking mid-run. We assumed GPS polling frequency was the culprit going in, but Xcode's Energy Log and Android's Battery Historian both pointed to three separate, smaller contributors rather than one dominant cause.
The first was GPS accuracy setting — we were requesting best-possible accuracy (kCLLocationAccuracyBestForNavigation on iOS) continuously, when the actual product need was accurate-enough-for-a-running-pace-line, not navigation-grade precision. Dropping to kCLLocationAccuracyBest with a distance filter of 10 meters cut GPS-related power draw by roughly 35% with no perceptible accuracy loss for the running-pace use case.
The second was a screen-wake-lock we'd added so users could glance at pace without unlocking their phone, which was keeping the display at full brightness for the entire run rather than dimming after inactivity. We replaced it with a lower-brightness always-on-style display for supported devices and let the OS's normal dimming behavior apply otherwise, which was a meaningful chunk of the drain since display is typically the single largest power consumer on a phone.
The third, and the one that took longest to find, was a background network call syncing workout data every 30 seconds during the run instead of batching. Each call was small, but the radio has to wake from a low-power state for every request, and radio wake cycles are disproportionately expensive relative to the data transferred. Batching sync to once every 5 minutes during an active workout, with a final sync on completion, removed most of that cost.
Combined, these three changes brought battery drain down to about 7% per hour, which was within the range users considered acceptable in follow-up testing. The broader lesson for any long-running background feature: battery profiling tools will point you at symptoms (radio activity, display time, CPU wakeups) but figuring out which product decision caused each one requires actually reading the feature code with power cost in mind, not just staring at the profiler output.
