How much battery drain per hour is acceptable?

For a typical consumer app, aim for less than 5% per hour during active foreground use and less than 0.5% per hour when backgrounded. Navigation and fitness apps that use continuous GPS will naturally consume more (10-15%/hr is reasonable during active tracking). Compare against competitors in your category. Check your app's ranking in Settings > Battery on both platforms, and investigate if your app appears in the top 3 battery consumers for more than 5% of users.

Should I disable features in Low Power Mode or just optimize them?

Optimize first, disable only as a last resort. Users turned on Low Power Mode to extend battery life, but they still want your app to work. Reducing sync frequency, lowering location accuracy, and simplifying animations are good optimizations that preserve functionality. Disabling background sync entirely or removing location features creates a degraded experience. Only disable features that are genuinely optional (video autoplay, analytics, background content preloading). For tracking which features users rely on most, the [mobile analytics plan](/templates/mobile-analytics-plan-template) covers feature usage instrumentation.

How do I measure battery impact in CI?

Xcode's `xctrace` command-line tool can capture energy traces during automated tests. For Android, use `dumpsys batterystats` before and after a test scenario, then analyze with Battery Historian. Neither gives you exact mAh measurements in CI, but both provide relative comparisons against a baseline. Set a threshold like "energy usage during test scenario must not increase by more than 10% vs baseline" and fail the build on regression. For deeper investigation, [usability testing](/glossary/usability-testing) with real devices in realistic conditions provides ground truth.

What is the single biggest battery drain in most apps?

Network activity, specifically frequent small requests that prevent the radio from entering sleep mode. Every network request wakes the cellular radio, which stays powered for 10-30 seconds after the request completes. Making 20 small requests over 5 minutes keeps the radio continuously active. Batching those into 2-3 larger requests lets the radio sleep between bursts, reducing energy consumption by 40-60%. This is why request coalescing and push-over-polling are the highest-impact optimizations for most apps.

Battery Optimization Template for PMs

What This Template Is For

Battery drain is the number one reason users uninstall mobile apps they otherwise like. Apple's App Store review guidelines flag excessive battery usage, and Android's Adaptive Battery system throttles misbehaving apps automatically. Yet most product teams never measure their app's energy impact until users start complaining in reviews.

This template provides a structured approach to profiling, auditing, and optimizing your app's battery consumption. It covers the five main energy consumers (CPU, network, GPS, display, and background tasks), platform-specific profiling tools, optimization strategies, and ongoing monitoring. Use it during development to set battery budgets and during production to investigate complaints.

For the full mobile performance picture, the Mobile Performance Template covers frame rates, startup time, and memory alongside energy. If you need to design background data refresh, the Background Sync Template covers sync strategies that respect battery constraints. The Mobile App PRD Template is the right starting point if you are defining the overall mobile product.

How to Use This Template

Profile your app's current battery consumption using platform tools. Get a baseline before making changes.
Identify the top energy consumers. Usually it is network requests, location services, or CPU-intensive operations.
Set battery budgets per feature area. Define acceptable energy consumption for each major subsystem.
Implement optimizations starting with the highest-impact, lowest-effort items.
Add energy monitoring to your CI and release process so regressions are caught early.
Monitor App Store / Play Store reviews and battery usage reports for user-reported issues.

The Template

Product Context

Field	Details
Product	[Product name]
Platforms	[iOS, Android]
App category	[e.g., Social, Productivity, Fitness, Navigation]
Typical session length	[X] minutes
Sessions per day	[X]
Background activity	[Yes / No. If yes, what runs in background?]
Location services	[Always / While Using / Never]
Push notifications	[Yes / No. Silent pushes?]
Current battery complaints	[X] App Store reviews mention battery in last 90 days

Energy Profiling Baseline

Run profiling on a representative device for each platform. Use the following tools.

Profiling Tools

Platform	Tool	What It Measures
iOS	Xcode Instruments > Energy Log	CPU, Network, Location, Display, Overhead per process
iOS	Xcode Organizer > Energy Reports	Field data from real user devices
iOS	MetricKit (MXDiagnosticPayload)	Aggregated energy data from production users
Android	Android Studio Profiler > Energy	CPU, Network, Location, Wake Locks per process
Android	Battery Historian	System-wide energy breakdown from bug report
Android	Perfetto	Detailed trace-level energy analysis

Baseline Measurements

Metric	iOS Value	Android Value	Target	Notes
Battery drain per hour (foreground)	[X]%/hr	[X]%/hr	< [X]%/hr	[Measure during typical usage scenario]
Battery drain per hour (background)	[X]%/hr	[X]%/hr	< [X]%/hr	[With all background features enabled]
CPU time per minute (foreground)	[X] ms	[X] ms	< [X] ms
Network transfers per hour	[X] requests, [X] MB	[X] requests, [X] MB
Location updates per hour	[X]	[X]
Wake locks per hour	N/A	[X]	< [X]	[Android only]
Background launches per day	[X]	[X]	< [X]

Energy Consumer Audit

CPU

Area	Current Behavior	Energy Impact	Optimization
App startup	[e.g., Heavy initialization on main thread]	[High / Medium / Low]	[Defer non-critical init, lazy load]
Scrolling / List rendering	[e.g., Complex cell layouts, image decoding on scroll]	[High / Medium / Low]	[Pre-decode images, simplify cells, recycle views]
Animations	[e.g., Continuous animation on dashboard]	[High / Medium / Low]	[Pause when offscreen, reduce frame rate, use GPU layers]
Data processing	[e.g., JSON parsing on main thread]	[High / Medium / Low]	[Move to background thread, use streaming parser]
Search / Filtering	[e.g., Full-text search on large dataset]	[High / Medium / Low]	[Debounce input, pre-index, use FTS]
Timers	[e.g., Multiple repeating timers at 1s intervals]	[High / Medium / Low]	[Coalesce timers, increase intervals, use tolerance]
[Area]

CPU optimization actions:

☐ Audit all repeating timers. Set tolerance on NSTimer (iOS) to allow coalescing
☐ Move heavy computation off the main thread
☐ Pause animations and timers when the app is backgrounded
☐ Use CADisplayLink instead of custom timers for UI updates
☐ Profile with Instruments to find unexpected CPU spikes

Network

Request Type	Frequency	Payload Size	Optimization
API polling	[e.g., Every 30s]	[X] KB	[Use push notifications or WebSocket instead]
Image loading	[e.g., On scroll]	[X] KB each	[Cache aggressively, use appropriate sizes, WebP format]
Analytics events	[e.g., On every action]	[X] KB each	[Batch and send every 5 minutes, or on WiFi only]
Config / Feature flags	[e.g., Every app launch]	[X] KB	[Cache with TTL, send If-None-Match]
Background refresh	[e.g., Every 15 min]	[X] KB	[Reduce to every 30 min, only on WiFi when below 20% battery]
[Request type]

Network optimization actions:

☐ Enable HTTP/2 to allow connection reuse and request multiplexing
☐ Compress all responses > 1 KB with gzip or brotli
☐ Set appropriate cache headers. Avoid re-fetching data that has not changed.
☐ Coalesce network requests: batch multiple small requests into one
☐ Use URLSession.waitsForConnectivity (iOS) / setRequiresCharging (Android WorkManager) for non-urgent uploads
☐ Disable automatic retries during Low Power Mode / Battery Saver

Location Services

Use Case	Accuracy	Frequency	Optimization
[e.g., Map display]	[Best / Within 10m / Within 100m]	[Continuous / On demand]	[Use lower accuracy when zoomed out, stop when offscreen]
[e.g., Check-in]	[Within 100m]	[One-shot on button press]	[Already optimal: request, get, stop]
[e.g., Background tracking]	[Best]	[Continuous]	[Switch to significant-change monitoring unless actively navigating]
[e.g., Geofencing]	[Region-based]	[On enter/exit only]	[Already efficient: system-managed, no continuous GPS]

Location optimization actions:

☐ Use the lowest accuracy level that satisfies the feature requirement
☐ Stop location updates when they are no longer needed (screen off, feature closed)
☐ Use region monitoring / geofencing instead of continuous tracking when possible
☐ Use significantLocationChange instead of standard updates for background location
☐ Set activityType (iOS) to help the system optimize GPS behavior
☐ Allow user control: "While Using App" vs "Always" permission

Display

Area	Current Behavior	Optimization
Brightness	[Does the app change brightness?]	[Never override user brightness unless essential, e.g., barcode scanner]
Keep screen on	[Which screens prevent auto-lock?]	[Only prevent sleep during active use: video playback, navigation, timer]
Dark mode	[Supported / Not supported]	[OLED screens save 30-50% display power in dark mode]
Animations	[Complex / Simple / None]	[Reduce animation complexity on low battery]
Refresh rate	[120Hz / 60Hz / Adaptive]	[Use adaptive: ProMotion (iOS) / Variable refresh rate (Android)]

Background Tasks

Task	Trigger	Duration	Frequency	Optimization
[e.g., Data sync]	[BGAppRefreshTask / WorkManager]	[X] seconds	Every [X] min	[Reduce scope: sync only changed data]
[e.g., Push processing]	[Silent push]	[X] seconds	[X]/day	[Minimize work: just update badge/local DB]
[e.g., Media upload]	[User action + background URL session]	Minutes	On demand	[Already efficient: system-managed]
[e.g., Analytics flush]	[App background event]	[X] seconds	Every time app backgrounds	[Batch: flush only if > 10 events queued]
[Task]

Battery Budget

Set energy budgets per subsystem. Measure with profiling tools and fail CI checks on regression.

Subsystem	Budget (% of total energy)	Current	Status
CPU (UI rendering)	[X]%	[X]%	[Within / Over budget]
CPU (data processing)	[X]%	[X]%	[Within / Over budget]
Network	[X]%	[X]%	[Within / Over budget]
Location	[X]%	[X]%	[Within / Over budget]
Background tasks	[X]%	[X]%	[Within / Over budget]
Display (keep-awake)	[X]%	[X]%	[Within / Over budget]
Total	100%	100%

Overall targets:

Scenario	Battery Drain Target	Measurement Method
1 hour active foreground use	< [X]%	[Xcode Energy Log / Android Profiler]
8 hours background (idle)	< [X]%	[Overnight test with profiling enabled]
24 hours mixed use	< [X]%	[Typical usage scenario: X min active, Y launches]

Low Battery Mode Behavior

Define how your app adapts when the device enters Low Power Mode (iOS) or Battery Saver (Android).

Feature	Normal Behavior	Low Battery Behavior
Background sync	Every [X] minutes	Disabled. Sync on foreground only.
Location updates	[Accuracy level, frequency]	Reduced accuracy, less frequent, or disabled
Animations	Full animations	Reduced or disabled
Image quality	Full resolution	Thumbnails until user taps
Video autoplay	Autoplay on WiFi	Never autoplay
Push processing	Full processing	Minimal: update badge only
Analytics	Batch every [X] min	Defer until charging or normal mode

Detection:

iOS: ProcessInfo.processInfo.isLowPowerModeEnabled + NSNotification.Name.NSProcessInfoPowerStateDidChange
Android: BatteryManager.isDeviceIdleMode() + Intent.ACTION_BATTERY_LOW

Optimization Priority Matrix

Priority	Optimization	Est. Battery Savings	Effort	Owner	Status
P0	[e.g., Replace 30s polling with push notifications]	[X]%/hr	[3 days]	[Name]	☐
P0	[e.g., Stop continuous location when map is closed]	[X]%/hr	[1 day]	[Name]	☐
P1	[e.g., Coalesce analytics network requests]	[X]%/hr	[2 days]	[Name]	☐
P1	[e.g., Add timer tolerance for background tasks]	[X]%/hr	[0.5 days]	[Name]	☐
P2	[e.g., Implement dark mode]	Display savings only	[1 week]	[Name]	☐
P2	[e.g., Reduce animation frame rate]	[X]%/hr	[1 day]	[Name]	☐

Monitoring and Alerting

Signal	Source	Threshold	Alert
Battery drain reports	iOS MetricKit / Android Vitals	> [X]%/hr for >5% of users	Slack alert to mobile team
App Store reviews mentioning battery	AppFollow / Appbot	> [X] reviews/week	Weekly digest
Background energy quota exceeded	iOS Organizer / Android Vitals	Any quota violation	Immediate investigation
CI energy regression	Automated profiling in CI	> [X]% increase vs baseline	Block release

Filled Example: Fitness Tracking App

Energy Consumer Audit (Example)

Consumer	Current Impact	Optimization	Savings
GPS tracking during workout	18%/hr (continuous best accuracy)	Switch to 10m accuracy for running, best only for hiking/cycling. Pause when stationary > 30s.	6%/hr saved
Heart rate polling via BLE	4%/hr (1s intervals)	Change to 5s intervals during warm-up/cool-down. 1s only during active intervals.	2%/hr saved
API sync every 30s during workout	3%/hr (uploads GPS + HR data)	Buffer locally, upload in 5-minute batches. Full sync on workout end.	2%/hr saved
Map rendering	5%/hr (continuous map updates)	Update map every 5s instead of every 1s. Pause rendering when screen off (audio cue instead).	3%/hr saved
Total active workout drain	30%/hr	Optimized	17%/hr (43% reduction)

Low Battery Behavior (Example)

Feature	Normal	Below 20%
GPS tracking	Best accuracy, 1s intervals	10m accuracy, 5s intervals
Map display	Live updating with route trace	Static route overview, update every 30s
Heart rate	1s during intervals, 5s otherwise	10s constant
Audio coaching	Full voice + music	Voice cues only, pause music
Post-workout sync	Immediate upload with map generation	Defer to WiFi + charging

Battery Optimization Template for PMs