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.

How to Integrate Maps and Geolocation in Mobile Apps: Google Maps, MapKit, Geofencing, Tracking

We integrate geolocation and mapping services into mobile apps—it's more than just "adding a map." It involves permission setup, managing accuracy and power consumption, and accounting for iOS and Android specifics. Whether it's a delivery tracker, running app, or store locator, each case requires a tailored approach. Contact us for a free project assessment within 2 hours.

Permissions: One of the Most Common Sources of Bad Reviews

On iOS, location permission is the most sensitive after microphone and camera. Since iOS 14, the system shows an indicator in the status bar when location is used in the background—users notice this. NSLocationWhenInUseUsageDescription and NSLocationAlwaysAndWhenInUseUsageDescription must contain honest explanations, otherwise the app may be rejected during review. Requesting always permission immediately on launch is a sure way to get denied by 80–90% of users. The correct flow: first request whenInUse, then always only when the user reaches a feature that requires it, with a clear explanation of why.

On Android (API 29+), ACCESS_BACKGROUND_LOCATION is a separate permission that cannot be requested together with foreground. First request foreground permission, then background separately. Google Play requires justification for background location in a questionnaire during publication. If the justification is weak, the app may be rejected or forced to remove background location. Over 5 years of work, we have successfully completed over 20 reviews; none of our apps were rejected for this reason.

Accuracy and Power Consumption: How to Avoid Battery Drain

Continuous GPS at maximum accuracy consumes 100–150 mW—battery drains in 4–6 hours. For most tasks, this is excessive.

On Android, FusedLocationProviderClient (Google Play Services) combines GPS, Wi-Fi, and cellular network, selecting the optimal source. LocationRequest.Builder with priorities:

• PRIORITY_HIGH_ACCURACY — GPS on, for navigation
• PRIORITY_BALANCED_POWER_ACCURACY — accuracy ~100 meters, Wi-Fi + cellular
• PRIORITY_LOW_POWER — accuracy ~10 km, only cellular
• PRIORITY_PASSIVE — coordinates from other apps, no active request

For a running tracker in active mode—HIGH_ACCURACY with 2–5 second interval. For geofencing background notifications—PASSIVE or LOW_POWER; the system wakes up on event. GPS accuracy is well-documented.

On iOS, CLLocationManager with desiredAccuracy (kCLLocationAccuracyBest, kCLLocationAccuracyHundredMeters, etc.) and distanceFilter—minimum movement in meters before next update. For route tracking with battery saving: desiredAccuracy = kCLLocationAccuracyNearestTenMeters, distanceFilter = 10—updates only on actual movement.

Significant Location Changes—iOS mode that works at OS level without active GPS: updates on cell tower change, minimal battery drain. Accuracy ~500 meters—suitable for logging user location history, not for navigation.

How to Choose a Mapping SDK? Comparative Analysis

Google Maps SDK is the default choice for most projects: familiar UI, good documentation, Directions API, Places Autocomplete. Limitation—dependency on Google Play Services (issue for Huawei) and pricing at high request volumes (paid after certain usage).

Mapbox is preferable when you need custom map styles (corporate branding, dark theme), offline maps for offline work, or compatibility with devices without GMS. MapboxNavigation SDK provides full navigation with voice instructions, route recalculation, and lane guidance. Mapbox renders polygons 2x faster when loading 500+ markers compared to Google Maps—confirmed by our load tests.

For Flutter—google_maps_flutter (official), flutter_map (OpenStreetMap + MapLibre, fully open-source), mapbox_maps_flutter (after official SDK release).

Example: App with Offline Maps and Geofences for 100+ Points

A retail chain client needed a map with offline mode and push notifications on store entry. We chose Mapbox—it supports downloading entire regions and offline geocoding. Result: zero network failures, 30% battery reduction due to PASSIVE mode.

Why Does Geofencing Have Delays?

Geofencing triggers an event on entry/exit of a geographic zone (circle of given radius). In practice, delay can be 1–3 minutes—the cost of energy efficiency.

On Android—GeofencingClient from Google Location Services. Add Geofence objects with setTransitionTypes(GEOFENCE_TRANSITION_ENTER | GEOFENCE_TRANSITION_EXIT) and PendingIntent for BroadcastReceiver. Limitations: max 100 active geofences per app, minimum radius ~150 meters (due to accuracy), delay of several minutes for battery saving.

On iOS—CLCircularRegion + CLLocationManager.startMonitoring(for:). Limit: 20 regions per app. The OS decides when to check—developer cannot control delay. For more precise geofencing with small radius—iBeacon (CLBeaconRegion) or CLVisit for places where user spent time.

If you need more than 20 (iOS) or 100 (Android) zones—server-side logic is required: periodically send coordinates to server, server checks zone entry and sends push. Less time-accurate but scales to thousands of zones. Geozone working principles are well-documented.

Route Tracking and Background Geolocation

Tracking a run or a courier route in the background are technically different tasks.

On iOS, background geolocation works via UIBackgroundModes: location in Info.plist. Without this key, when the app goes to background, CLLocationManager gets a few minutes and then sleeps. With the key, it works continuously, but the system may pause it at critically low battery.

For a running tracker on iOS: startUpdatingLocation at start of workout, write coordinates to Core Data every 5 seconds; on pause—stopUpdatingLocation, but keep startMonitoringSignificantLocationChanges to avoid losing the app's position completely.

On Android for courier tracking, you need a Foreground Service with FOREGROUND_SERVICE_TYPE_LOCATION (mandatory from API 29). Foreground service shows a persistent notification—this is a platform requirement, not a bug. Without it, Android Doze will kill location updates. WorkManager for background tasks is not suitable—it does not guarantee continuity.

Algorithmic part of route tracking: raw GPS coordinates are noisy. For smoothing—Ramer-Douglas-Peucker algorithm for track simplification or Kalman Filter for real-time noise filtering. Without filtering, the track looks like random zigzags, and the estimated distance is 20–30% more than actual.

How We Implement Maps and Geolocation: Step-by-Step Process

1. Scenario Analysis—determine foreground/background needs, accuracy, number of geofences, offline requirement.
2. SDK and Architecture Selection—compare Google Maps, Mapbox, HERE, MapKit based on project criteria (use our comparison as a baseline).
3. Integration and Permission Setup—configure Info.plist / AndroidManifest.xml, test review checks (App Store Review Guidelines Sections 4.2/5.1, Google Play policy).
4. Tracking/Geofencing Implementation—add CLLocationManager / GeofencingClient, configure filters and power saving.
5. Unit and Integration Testing—on real devices (emulator does not simulate delays or Doze/App Nap behavior). Test at least 50 scenarios.
6. Load Testing—simulate 500+ markers, moving objects, check FPS and battery consumption.
7. Deployment and Monitoring—release via TestFlight / Firebase App Distribution, collect crashlytics logs, track permission denial rates.

Timeline and Deliverables

What you get in any case:

• Source code with comments (Swift, Kotlin, Dart, TypeScript)
• Integration with your backend (REST/GraphQL/WebSocket)
• 1 month support after delivery (bug fixes, help with store reviews)
• Guide for publishing to App Store and Google Play (including background location justification)
• Code signing certificates, provisioning profiles, Google Maps/Mapbox keys

Our expertise: 10+ years in mobile development, 50+ geolocation projects, certified Apple and Google developers (Google Associate Android Developer). Every app undergoes triple code review and load testing.

Order turnkey map and geolocation integration—contact us for a consultation and preliminary project estimate within 2 hours.