Design a location-tracking feature that respects both battery life and user privacy

#Clarifying the requirements first

Before I touch a single API, I want to know what 'tracking location' actually means for this product, because the right architecture for a ride-hailing app that needs live, street-level accuracy during an active trip looks nothing like the right architecture for a fitness app drawing a route after the fact, or a retail app that only cares whether a phone entered a 100-meter radius around a store. I'd ask the interviewer: does this need to run while the app is backgrounded or fully killed? Does it need meter-level precision, or is 'which neighborhood' enough? Is it a continuous stream, or an event-triggered check-in? And — the question that actually drives the design — what value is the user getting in exchange for handing over this permission, because that's what determines both the UX and whether Apple's and Google's review teams will accept it at all.

#The core tension: battery, precision, and trust

GPS is one of the most power-hungry subsystems on a phone. Getting a fix means waking the GPS radio, correlating satellite signals, and often also querying cell towers and Wi-Fi access points for assisted positioning. Polling it continuously at high accuracy visibly drains a battery within hours, and it gets an app flagged by the OS's own background-activity heuristics — iOS's per-app battery report, Android's App Standby Buckets and Battery Historian — long before a user ever complains. At the same time, continuous location is arguably the single most sensitive stream a mobile app can collect: over a few weeks it reveals home address, workplace, place of worship, medical visits, and who someone spends the night with. That's exactly why both platforms gate the 'Always' authorization behind an explicit justification, and why regulators treat precise location as sensitive personal data with its own consent and retention rules. So the design goal isn't 'track location' — it's 'deliver the accuracy the feature actually needs using the coarsest, least frequent, shortest-lived mode that satisfies it.'

#Platform primitives I'd reach for

Both platforms give you a menu of tiers below full continuous GPS, and a senior answer leans on all of them rather than defaulting to the most powerful one. On iOS, CLLocationManager's standard service is the expensive one; the significant-change location service instead uses cell and Wi-Fi triangulation to wake the app only after roughly 500 meters of movement or a cell tower handoff, at a fraction of the power cost, and it works even if the app has been terminated by the system. Region monitoring (CLCircularRegion, up to 20 regions per app) is hardware-backed geofencing — the radio chip itself watches for boundary crossings and only wakes the app process on enter/exit, so it costs almost nothing while idle. CLVisit monitoring goes a step further and reports that the user stayed somewhere for a while, which is often all a retail or logistics app needs. On Android, FusedLocationProviderClient exposes accuracy priorities — PRIORITY_BALANCED_POWER_ACCURACY prefers network-based positioning (~100m, cheap) over raw GPS, while PRIORITY_HIGH_ACCURACY is the expensive one — and its Geofencing API (up to 100 regions) mirrors iOS's hardware-backed region monitoring. Since Android 8, any continuous background location work has to run inside a foreground service with a persistent notification, and since Android 10, ACCESS_BACKGROUND_LOCATION is a separate runtime permission the user grants deliberately in system settings, not in the app's own dialog.

#A tiered architecture

I'd default every user into a cheap idle tier — significant-change updates on iOS, balanced-power fused location on Android — that wakes the app rarely and tells it roughly where the device is. Layered on top, I'd register geofences around the handful of points of interest the feature actually cares about (a store, a delivery address, a campus), which costs nothing while the user is far away and fires an event exactly when it matters. Only when that event promotes the session to active — a trip has started, an order is out for delivery — would I switch to bounded high-accuracy GPS, and only for the duration of that session, with a visible indicator (iOS's blue background-location pill, Android's foreground-service notification) so the user always knows when the expensive tier is running. The moment the session ends, I'd drop straight back to the idle tier rather than leaving high-accuracy polling running out of convenience.

#Privacy by design, not by policy addendum

The permission dialog is the least interesting part of privacy design; what happens to the data afterward matters more. I'd request 'When In Use' by default and only escalate to 'Always' at the exact moment the feature needs it, with a plain-language explanation of what's gained — asking upfront during onboarding is the single most common cause of both permission denial and App Store rejection. On-device, I'd apply a distance and time filter so updates are only generated when the position has genuinely changed, and I'd truncate precision before anything leaves the device unless the feature explicitly needs house-level accuracy — a fitness map doesn't need to know which exam room in a hospital the user is in. Server-side, I'd set a short TTL on raw location history, aggregate or delete past that window, and give the user a real, working 'delete my location history' control rather than a support ticket. And since iOS 14 lets a user grant Approximate location instead of Precise, I'd make sure the coarse tier of my own architecture is genuinely useful under that constraint rather than treating it as a degraded, unsupported mode.

#Failure modes worth naming in the interview

A few edge cases separate a senior answer from a surface-level one. Users can revoke location permission while the app is backgrounded mid-session, so the tracking code has to handle authorization changing under it, not just check it once at launch. GPS degrades badly indoors and in urban canyons, so I'd design a fallback to the last-known-good position plus a staleness indicator rather than showing a confidently wrong pin. The OS can and will kill a backgrounded app to reclaim memory or battery (Doze mode, App Standby Buckets, iOS's background execution budget), so anything that must survive should be handed to a durable scheduler — Android's WorkManager, iOS's BGTaskScheduler — rather than a raw timer. And the 20-region cap on iOS geofencing means a feature that wants to watch more points of interest than that has to dynamically re-register the nearest N regions as the user moves, not just fail silently past the limit.

#Tradeoffs I'd surface unprompted

I'd close by naming the tradeoffs explicitly rather than waiting to be asked. Significant-change and geofencing are far cheaper on battery than continuous GPS but introduce real latency — up to 500 meters of movement before the app even wakes up — so any feature promising sub-second live tracking has to accept the cost of the expensive tier for that bounded window. Coarsening precision for privacy directly reduces the accuracy other parts of the product can rely on, so it has to be a product decision, not just an engineering default. And a silent-push-triggered one-time location fetch can replace continuous background tracking entirely for use cases that only need a fresh position occasionally, like knowing where a courier is right now, trading a small amount of staleness for a large reduction in both battery cost and privacy surface area — that's usually the first alternative I'd propose before reaching for background tracking at all.