Your Phone Is Running a Tiny Air Traffic Control Tower
You're mid-turn. The navigation app freezes. Somewhere behind the screen, a ride-share app, a fitness tracker, and a food delivery service are all pinging the same piece of hardware at the same moment: the GPS receiver, the Wi-Fi positioning stack, and the cellular triangulation layer, all bundled into one location subsystem that suddenly has three bosses.
Who gets served first is more interesting than most people realise.
Accuracy Tiers Are the Actual Queue
Neither iOS nor Android hands out location data on a strict first-come, first-served basis. Both operating systems use a tiered accuracy model, and the tier an app requests determines how much of the hardware it actually wakes up.
Three tiers, roughly. Precise location (what Google Maps or Waze needs) fires up full GPS, Wi-Fi positioning, and cell data simultaneously, accurate to within a few metres and genuinely hungry for battery. Approximate location (what a weather widget needs) uses cell towers and Wi-Fi alone, accurate to a few hundred metres, and costs almost nothing. Background location is a separate permission layer governing whether an app can query either of the above tiers when it isn't on screen.
When multiple apps request location at the same time, the subsystem doesn't serve them sequentially. It runs the hardware at the highest accuracy tier any active app has requested, then shares that single stream of fixes with every app entitled to receive it.
Think of it less like a queue and more like a radio broadcast: the transmitter runs at the strongest signal any listener needs, and everyone tunes in.
So if Google Maps is open and pulling a GPS fix every second, a step-counter running in the background that only needs approximate location gets a free ride on that high-accuracy stream. The step-counter didn't pay for the precision. Maps did.
Foreground Beats Background, Every Time
That broadcast model has one hard rule on top: foreground apps take priority over background ones, not in terms of data quality, but in terms of permission to receive data at all.
On iOS, an app without the "always on" background location permission simply stops receiving fixes the moment you leave it. It can request a re-wake via "significant location change" (triggered by a cell tower handoff, roughly every 500 metres of travel), but it won't get continuous high-frequency updates. Android handles this similarly, with a background location permission that's deliberately hard to grant and easy to revoke, plus a "while in use" restriction that mirrors Apple's approach.
Here's a worked example. Priya and Marcus buy the same phone on the same day and install the same period-tracking app. Priya granted it full background location access during setup and never went back. Marcus tapped "only while using." Priya's app receives location fixes passively all day. Marcus's app gets nothing until he opens it. Same phone, same app, completely different data exposure, all because of one permission decision made in about two seconds.
The operating system is the arbitrator here. It doesn't choose between competing apps so much as enforce the permissions each app was granted, then run the hardware at whatever level the most demanding entitled app requires.
The Caching Layer People Forget About
This wrinkle actually matters, for battery life and for privacy.
When an app requests location and the GPS hasn't fired up yet (cold start after the phone's been stationary, say), the OS returns a cached fix rather than making the app wait. That cached position can be anywhere from thirty seconds to several minutes old. A navigation app will immediately flag it as stale and wait for a fresh fix. A social media app asking for your city to serve local content? It'll happily use the cached position and never request a live fix at all.
They're reading yesterday's newspaper, basically.
For privacy, this matters more than people admit. An app doesn't need to trigger the GPS to learn roughly where you are. If Maps ran ten minutes ago, the last fix is sitting in a shared cache, and any app with location permission can read it without touching the hardware.
The Battery Drain Misconception Worth Correcting
Most people assume that more apps holding location permission means proportionally more battery drain. It doesn't work that way, and that assumption leads people to do a lot of pointless permission-revoking on apps that weren't costing them anything.
The hardware cost is almost entirely determined by the highest accuracy tier being actively requested by any foreground app. Five background apps with approximate location permission, all reading from a cache, add almost nothing. One foreground navigation app with precise location active will cost roughly 10 to 15 percent of battery per hour on its own, because the GPS receiver is one of the most power-intensive components in the phone.
A phone that starts the day at 100% and hits 20% by dinner almost certainly has a navigation or fitness app holding a continuous high-accuracy foreground lock. The culprit is almost always singular.
You can check this right now. On iOS, go to Settings, Privacy and Security, Location Services: a solid purple arrow means active use, hollow purple means used within the last 24 hours. On Android, Settings, Location, App permissions, then "Location access in the last 24 hours" gives you the same picture. If you're seeing one or two apps with solid-purple activity, you're looking at essentially all of your location-related battery drain.
The Permission You Granted and Forgot
Honestly, the arbitration logic is pretty elegant. The phone shares hardware efficiently, enforces permission tiers cleanly, and stops background apps from silently burning battery on continuous GPS fixes.
The weak point isn't the logic. It's the permission you tapped through eighteen months ago during a two-second install flow. The phone is doing exactly what you told it to do.
The question is whether you remember what you said.