You started a browser-based tracker, put the phone in your pocket, ran five kilometres, and got back a recording of the first ninety seconds.
Nothing is broken. This is the mobile web working exactly as designed, and it is the single constraint that shapes every browser-based tracker there is.
What actually happens
navigator.geolocation.watchPosition() only delivers positions while your page
is alive and visible. The moment it is not:
- iOS Safari suspends the page. Callbacks stop. Not throttled — stopped.
- Android Chrome throttles background timers and location callbacks hard, and will freeze the tab entirely under memory pressure.
Lock the screen, switch apps, or take a phone call, and the fixes stop arriving. When you come back the page resumes, but the intervening minutes are simply not in the recording.
A PWA does not fix it
This is the most common wrong turn, so it is worth being blunt: installing to the home screen changes nothing here. A PWA on iOS is the same web view with different chrome around it. Service workers do not get background geolocation either — they are event-driven, woken for push and fetch, not kept alive to listen for a GPS.
The APIs that would fix it either do not exist on the mobile web or are not implemented where it matters:
| API | Status |
|---|---|
| Background Geolocation API | Not a shipping web standard |
| Periodic Background Sync | Chrome only, not for continuous location |
| Web Workers | Suspended with the page; no geolocation access anyway |
| Service Worker | No watchPosition. Not kept alive |
A native app can register for background location updates with the OS. A web page cannot. That is the entire difference, and no amount of clever engineering crosses it.
What can be done: the wake lock
The Screen Wake Lock API asks the OS to keep the display on:
const lock = await navigator.wakeLock.request('screen');
// ... recording ...
await lock.release();
If the screen never turns off, the page is never suspended, and the recording does not stop. That is the whole mechanism — it does not enable background recording, it prevents the background from happening.
Two caveats that matter in practice:
The lock is lost when the tab is hidden. Switch apps and it is released, and
it must be re-acquired on visibilitychange when you come back. A recorder that
requests it once at the start silently loses it the first time you check a
message.
The user can still lock the phone manually. The wake lock stops the idle timeout, not the power button.
What Track Me does
Three things, and the third is the one that matters most.
It requests a wake lock and shows you it has one. A small indicator, not a promise buried in a settings page.
It says the constraint out loud before you start. Screen stays on, keep it unlocked, expect battery drain. Discovering this after a ruined recording is a much worse experience than being told in advance.
It reports the gap instead of drawing across it. This is the honest part. If the recording is interrupted for more than 30 seconds, the missing stretch is marked as a gap. The route line is broken rather than continued, and the distance is not increased by a straight line between the last fix and the next one.
That last decision is worth dwelling on. Interpolating across the gap would give a nicer-looking result — a continuous line, a plausible total, no awkward message. It would also be a guess presented as a measurement. A phone that was in a pocket for four minutes might have gone 800 m in a straight line or 1.2 km around three corners, and the recording genuinely does not know which. Reporting the shortfall is worse-looking and correct.
Pocket mode
The obvious problem with "keep the screen on and unlocked" is that a screen in a pocket gets pressed by your leg for the entire run.
Pocket mode goes full screen, locks out touch input, and dims the display. The wake lock stays held, so the recording keeps running; the screen ignores contact, so nothing gets pressed; and the dimming claws back some of the battery cost. A deliberate two-finger gesture unlocks it.
It is the difference between the constraint being survivable and not.
Battery, honestly
Continuous high-accuracy GPS with the display on is roughly 15–25% of a phone battery per hour, depending on the device and screen brightness. Pocket mode's dimming helps meaningfully; nothing makes it cheap.
For an hour's run on a phone that started above 50%, this is a non-issue. For a five-hour ride, take a battery pack or use a device built for it.
How to tell whether it is working
Start a recording and lock the screen for a minute deliberately, then come back. A recorder that is being honest with you will show a gap and say so. One that shows a smooth, unbroken line across that minute is interpolating — which means every unnoticed interruption in every recording it has ever made was quietly filled in with a guess.
That test takes sixty seconds and tells you more about a tracker than its feature list does.
Where to go next
- Track your run or ride with just your phone
- Why GPS distance disagrees with your watch — the other place recorded numbers diverge