Implementation of Real-Time Geolocation Tracking
Showing a user's location point on a map — five lines of code. Transmitting it to the server every 5 seconds with minimal battery drain while the app is in the background, correctly handling signal loss and reconnection — that's a completely different story.
Where Problems Usually Arise
The most common mistake is not separating foreground and background tracking. In foreground, you can run CLLocationManager with desiredAccuracy: .bestForNavigation and distanceFilter: 5 — the user is actively watching the map, battery is not a priority. In background, the same mode will kill the charge in two hours and cause complaints.
On Android the problem is acute: since version 8.0, the system aggressively kills background processes. LocationManager.requestLocationUpdates() from Service without startForeground() stops receiving updates within a few minutes on most firmware. MIUI and One UI with "Battery Optimization" settings make this even faster — regardless of developer settings.
Stack and Architecture
iOS
For foreground — CLLocationManager with CLLocationAccuracy.best, callback in didUpdateLocations. For background — allowsBackgroundLocationUpdates = true + "Background Modes → Location updates" capability in entitlements. Without this flag, background updates simply don't arrive, and no error appears in the console.
Buffer coordinates locally (array in memory or Core Data) and send in batches via URLSession.shared.uploadTask every N seconds or upon accumulating K points. Single HTTP requests for each update is an anti-pattern: with poor internet, the queue grows faster than it's consumed.
To save battery, switch mode depending on context:
- App active:
desiredAccuracy = kCLLocationAccuracyBest,distanceFilter = 10 - Screen off:
desiredAccuracy = kCLLocationAccuracyHundredMeters,distanceFilter = 50 - Long tracking: Significant Location Changes API instead of continuous monitoring
Android
FusedLocationProviderClient from play-services-location is the only right choice for most projects. Platform LocationManager gives less control over source fusion.
val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 5_000L)
.setMinUpdateDistanceMeters(10f)
.setWaitForAccurateLocation(false)
.build()
fusedLocationClient.requestLocationUpdates(
request,
locationCallback,
Looper.getMainLooper()
)
Background tracking — only via Foreground Service with notification. Notification can't be hidden per Android 9+ requirements. Register service via startForeground() with FOREGROUND_SERVICE_TYPE_LOCATION (Android 10+).
On connection loss — Room as local buffer. WorkManager with Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED) sends accumulated points when connection restores.
Flutter
geolocator package for getting positions, background_locator_2 or flutter_background_geolocation (paid but reliable) for background mode. Send coordinates via Isolate or FlutterEngine background service to Dart layer, save to Isar or sqflite, sync via Dio with retry logic.
Real-Time Server Transmission
If you need to show position to other users in real time — HTTP polling doesn't work. WebSocket (socket.io or native URLSessionWebSocketTask / OkHttp WebSocket) or MQTT (lighter traffic, better for unstable connection). For Flutter — mqtt_client package.
MQTT topic like tracking/{userId}/location, QoS 1 for delivery guarantee without read confirmation. Server (Node.js + mosquitto broker or AWS IoT Core) distributes updates to subscribers.
Workflow
Planning: tracking modes, intervals, buffering, transmission protocol. iOS and/or Android implementation with correct service lifecycle. Server side implementation for receiving coordinates (if needed). Testing on real trips, checking behavior when switching network/no network.
Timeline: three to eight days depending on platforms, presence of server part, and real-time display requirements.