Live location tracking that survives phones and scales to thousands

Real-time geolocation that stays alive on every phone — and does not melt your server room.

A location-tracking stack that handles both Android background kills and high-concurrency live updates — built on Go and a realtime channel designed for this exact problem.

Talk to us about this See: Custom solutions

Signs this is your problem

You will recognise yourself in at least one of these

Users complain "the app stopped tracking" after 20–30 minutes — louder on Xiaomi, Huawei, Oppo or some Samsungs than on Pixel.
Riders, drivers or field workers disappear from the live map mid-session with no error in logs.
WebSocket connections drop under load and reconnect storms make things worse.
Location updates lag by 10–30 seconds when many users are active in one area.
Polling every few seconds is hammering your database and draining mobile battery.
Reproducing the bug in your office is impossible — it only happens "in the wild".

Why it happens

The root cause, in plain language

Two problems collide. On the device, aggressive vendor-specific battery savers terminate background services without notifying the app or the user — standard Android lifecycle handling is not enough. On the backend, a pull-based, HTTP-polling design simply does not scale to many concurrent active users. Live location needs both a phone-side strategy that survives and a server-side architecture built for high-concurrency persistent connections.

Our approach

How we actually fix this

1
Audit your foreground service, WorkManager and AlarmManager usage against current Doze and App Standby rules.
2
Implement a foreground service with a sticky notification for genuinely long-running tracking.
3
Guide users through manufacturer-specific autostart and battery-protection settings the first time they need them.
4
Move from HTTP polling to a persistent realtime channel (WebSocket / gRPC streaming).
5
Build the realtime backend in Go for low-latency, high-concurrency fan-out.
6
Throttle the client smartly — send only meaningful position deltas, not every GPS tick.
7
Add reconnect-with-state and a heartbeat + remote-restart fallback so a dropped connection or a killed app recovers within seconds.
8
Build a real-device matrix (Xiaomi, Huawei, Samsung, OnePlus, Oppo) into the CI test suite.

What you can expect

Outcomes our clients see

"App stops working" reviews dropped to near zero within two release cycles.
Median session length on affected devices increased from ~25 min to full ride/shift length.
Thousands of users tracked live, in one feed, without latency spikes.
Reduced mobile battery drain compared to aggressive polling.
Backend cost stays manageable as the user base grows.

Case study

MOTO SOS — riders live on the map, end to end

A mobile app for motorcyclists where riders see each other live and can call for help in emergencies. Users were reporting friends vanishing from the live map after 20–30 minutes — the cause was specific phone brands silently shutting the app down, combined with a backend that struggled when many riders were active at once. We fixed both: the app now stays active for the full ride on every phone family, and the realtime backend (Golang) scales to high-concurrency live tracking. Store ratings recovered within two update cycles.

See more of our work →