Real-Time Geolocation Tracking: iOS, Android, Flutter

A client launched tracking on iOS with desiredAccuracy: .bestForNavigation — the battery drained in an hour. We had to redesign the stack with an adaptive mode: in background — kCLLocationAccuracyHundredMeters, screen off — Significant Location Changes API. We are a mobile development team specializing in geolocation systems for iOS, Android, and Flutter. We help implement reliable real-time geolocation tracking, considering all platform constraints and optimizing power consumption. Errors in location manager configuration cause 80% of complaints about battery drain and accuracy loss.

Where real-time geolocation tracking problems arise

The most common mistake is not separating foreground and background modes. In foreground you can run CLLocationManager with desiredAccuracy: .bestForNavigation and distanceFilter: 5 — the user is actively looking at the map. In background, the same mode kills the battery in two hours. On Android, since Android 8, the system aggressively kills background processes. LocationManager.requestLocationUpdates() from a Service without startForeground() stops receiving updates after a few minutes. MIUI and One UI with "Battery Optimization" settings make it even faster — regardless of developer settings. As a result, accuracy drops and users lose trust.

How to ensure background geolocation accuracy?

Stack and architecture

iOS

For foreground — CLLocationManager with CLLocationAccuracy.best, callback in didUpdateLocations. For background — allowsBackgroundLocationUpdates = true + capability "Background Modes → Location updates" in entitlements. Without this flag, background updates simply don't arrive. We buffer coordinates locally (in-memory array or Core Data) and send in batches via URLSession.shared.uploadTask every N seconds or after accumulating K points. Sending individual HTTP requests per update is an anti-pattern.

To save battery we switch modes based on context:

• App active: desiredAccuracy = kCLLocationAccuracyBest, distanceFilter = 10
• Screen off: desiredAccuracy = kCLLocationAccuracyHundredMeters, distanceFilter = 50
• "Long tracking" mode: Significant Location Changes API instead of continuous monitoring

Android

FusedLocationProviderClient from play-services-location is the only correct choice. The platform's LocationManager gives less control.

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. The notification cannot be hidden as per Android 9+ requirements. When obfuscating with ProGuard/R8, don't forget to add keep rules for Room and serialization — otherwise coordinates are lost.

Flutter

geolocator for getting positions, flutter_background_geolocation (paid, but reliable) for background mode. Coordinates via Isolate are saved to Isar, synchronized through Dio with retry logic.

Why MQTT is better than WebSocket for tracking?

If you need to show positions to other users in real time, HTTP polling doesn't work. WebSocket (socket.io or native URLSessionWebSocketTask / OkHttp WebSocket) and MQTT are the main options. MQTT is lighter on traffic and handles unstable connections better. In tests with a courier service on 500 devices, MQTT with QoS 1 showed latency under 100 ms and data loss of 0.3%. For Flutter we use the mqtt_client package. Protocol comparison confirms that MQTT consumes 60% less traffic at the same update frequency.

How to deal with connection loss?

Buffering is a key element. On iOS we use Core Data, on Android — Room, on Flutter — Isar. When the network recovers, we send accumulated data via WorkManager with network type constraints (Wi-Fi only or any). In one courier project, buffering ensured 99.9% delivery of points even during connection breaks in tunnels. Additionally, we implement priority queues: urgent coordinates (status change) are sent first.

Typical mistakes in tracking implementation

• Sending each coordinate as a separate HTTP request — multiplies traffic and delays.
• Ignoring geofence on Android — leads to unnecessary triggers and battery drain.
• Lack of retry logic on sending — data loss during temporary network failures.
• Incorrect obfuscation (ProGuard/R8) — serialization collapse and app crash.

What our work includes

• Requirements analysis and tracking architecture design considering platform constraints.
• Implementation of coordinate collection on iOS (Swift) and Android (Kotlin) with adaptive tracking.
• Server-side setup (WebSocket/MQTT) for real-time transmission.
• Buffering and synchronization on connection loss.
• Testing on real devices in various conditions (subway, tunnels, poor connectivity).
• API documentation and deployment instructions.
• One month of support after delivery.

Our process

1. Analysis: we discuss tracking modes, intervals, protocols. Contact us for an initial consultation.
2. Design: architecture, stack selection, data schema.
3. Implementation: iOS and/or Android with proper service lifecycle management.
4. Server-side implementation of coordinate reception (if needed).
5. Testing: real trips, network/no-network switching, battery checks.
6. Deployment to stores and server.

Estimated timelines

From 3 to 8 working days per platform (iOS or Android), including integration with your existing server. Pricing is calculated individually after project analysis.

Experience and guarantees

Over 5 years of experience in mobile development, more than 20 completed geolocation projects, 98% client satisfaction. We use modern approaches: adaptive tracking, MQTT, secure data transmission (TLS). We guarantee stable operation of the implemented functionality for one month after delivery. Contact us for a free engineering consultation — we'll prepare a proposal tailored to your requirements. Request a project evaluation.