How background location actually works on iOS and Android
Almost every complaint about a safety app — "it stopped updating", "it said I was offline", "it didn't wake up" — traces back to the same thing: the operating system is in charge of location, not the app. This guide explains what the OS actually permits, so you can tell the difference between a broken app and a phone behaving exactly as designed.
The one-sentence version
A phone will not run a location app continuously the way a laptop runs a program. Both iOS and Android suspend, throttle and occasionally kill background apps to protect battery, and both give you an explicit permission switch that decides how much the app gets to see. An app cannot opt out of any of this. The honest goal is not "always-on tracking" — it is "updates often enough to be useful, plus a reliable way to notice when they stop."
The permission that matters most
Both platforms distinguish between location while you're using the app and location all the time. If a safety app only has the first one, it stops reporting the moment you switch apps or lock your screen — which is precisely when you need it.
- iOS: the setting is Always vs. While Using. iOS deliberately makes Always hard to grant — you often have to choose it in Settings rather than in the app's prompt, and iOS may later show a "this app has been using your location in the background" reminder and offer to switch you back.
- Android: the equivalent is "Allow all the time". On Android 11 and later, an app is not allowed to ask for this in a normal permission dialog. The app must send you to system settings to choose it yourself. An app that seems to be nagging you into Settings is not being pushy; that is the only route the platform permits.
Also worth knowing: both platforms let you grant approximate location instead of precise. Approximate is useful for a weather app and close to useless for a safety session — it can be off by a kilometre or more.
iOS: what actually keeps an app alive
iOS does not let an app say "please run forever." Instead it offers a few specific mechanisms, each with different guarantees.
| Mechanism | What it gives you | Honest limitation |
|---|---|---|
| Continuous updates during an active session | Frequent, accurate fixes while a session is running | The heaviest on battery; iOS shows a status-bar indicator |
| Significant-location change | A cheap wake-up when you move a meaningful distance | Apple documents this as roughly 500 m granularity and no more often than about every five minutes. It is a coarse trigger, not a live trail. |
| Region / geofence monitoring | A wake-up on entering or leaving a defined area | Limited number of regions; entry/exit detection has its own lag |
| Silent push from a server | A nudge to send a fresh fix | Explicitly best-effort. Apple advises sending only a few per hour and does not guarantee delivery. |
The force-quit rule that surprises everyone
If you swipe an app away in the app switcher, iOS treats that as a deliberate instruction that you do not want it running. A held silent notification is discarded, and standard and significant-change location updates will not bring it back. Region monitoring is the one location service documented to relaunch an app after termination.
Practical consequence: force-quitting a safety app during an active session is one of the few things that genuinely stops it, and no app can engineer around it. If you want a session to keep running, leave the app alone in the background. A well-built app should notice the silence and send you a visible notification asking you to reopen it — that visible nudge is the recovery, not a magic self-relaunch.
Android: foreground services and the OEM problem
Android's model is different. To keep working in the background, a location app runs a foreground service, which is why you see a persistent notification. That notification is not clutter and not optional — it is the price of the app being allowed to keep running, and it exists so that background location can never be invisible to you.
Two things routinely interfere anyway:
- Battery optimisation. Stock Android will restrict apps it considers idle. Exempting your safety app from battery optimisation is usually the single highest-impact setting you can change.
- Manufacturer battery managers. Several manufacturers ship aggressive task-killers on top of Android that will stop foreground services regardless of what the app requests. These are the most common cause of "it just stopped" on Android, they vary by brand and firmware version, and an app cannot disable them. The fix is on the phone: find the battery or app-launch settings for the manufacturer's own manager and mark the app as protected / allow auto-start.
Android will also restart a killed service in many cases, and an app can schedule a restart attempt when it detects it was swiped away — but both are best-effort. Treat them as recovery, not as a guarantee.
What this means for reading a location share
Put the two platforms together and you get one useful rule: the gap between updates is information, and a gap is not automatically an emergency. A phone in a pocket on significant-change monitoring can legitimately go five or ten minutes without a new fix while the person is completely fine. A phone that has been silent for an hour during an active session is a different signal.
This is why a well-designed safety product does not rely on the location stream alone. It pairs location with a timed check-in: the check-in turns silence into an explicit, timed question with a defined answer, instead of leaving your contact staring at a pin and guessing. We wrote about how to read a stale pin in why a location pin goes stale.
Settings worth taking two minutes to fix
- Grant Always (iOS) or Allow all the time (Android) rather than while-in-use.
- Make sure precise location is on, not approximate.
- On Android, exempt the app from battery optimisation, and check your manufacturer's own battery manager separately.
- Leave notifications enabled — a check-in prompt you never see is a check-in you will miss.
- Don't force-quit the app while a session is running.
- Remember that Low Power Mode (iOS) and Battery Saver (Android) both reduce background activity by design.