How We Build Courier Apps That Don't Kill Background Geolocation
The courier accepted the order, set off—and the app went into background-killed state on an Android Xiaomi with MIUI. FusedLocationProvider stopped providing coordinates, the track was lost, the dispatcher can't see the vehicle. This is not a hypothetical scenario—it's a standard problem for courier apps on aggressive launchers like MIUI, OneUI, EMUI, where foreground services are killed by the battery optimization garbage collector.
Our experience of over 5 years and over 20 delivered projects for courier services allows us to guarantee stable operation even on problematic devices. We develop applications turnkey—from architecture to publishing on App Store and Google Play.
The Problem: Background Geolocation on Android
On Android, continuous geolocation requires a Foreground Service with a visible notification in the status bar. Without it, on Xiaomi/Huawei/OPPO the app will die within 5–10 minutes in the background regardless of WakeLock. But even foreground service is not a panacea: MIUI adds battery restrictions even on running services if the user hasn't manually allowed autostart.
Our Approach: Ensuring Continuous Tracking
The correct approach: on first launch, we show an Intent to the system autostart screen (for MIUI—com.miui.securitycenter, for Huawei—com.huawei.systemmanager). It's not always pretty, but it's the only way to guarantee tracking. Plus—batch coordinate sending: we accumulate points in memory and send them every 10–15 seconds in one request instead of 15 separate ones.
On iOS, problems are fewer: CLLocationManager with allowsBackgroundLocationUpdates = true and pausesLocationUpdatesAutomatically = false works reliably. However, significant-change location updates are not suitable for couriers—they trigger only on cell tower changes (~500 m accuracy), which is not good for real-time map display.
Why Build Two Separate Apps?
A courier service almost always consists of two separate apps: one for the courier and one for the client. Sometimes a third—a dispatcher web interface—is added. But the mobile part can be in one project with different flavors/schemes:
-
Android Flavors:
courierApp/clientApp—differentapplicationId, icons, permissions - iOS Targets: two targets in one Xcode project, shared code via SPM package
This allows reusing business logic (network layer, data models, geolocation module) between the two apps without code duplication. Comparison of approaches:
| Approach | Code Duplication | Maintenance Complexity | MVP Development Time |
|---|---|---|---|
| Two separate projects | 100% | High | 8–12 weeks |
| One project with flavor/target | 10–20% | Low | 6–10 weeks |
Order Assignment and Routing Logic
Order distribution logic lives on the server. The mobile client only receives the assignment via push (FCM/APNs with priority: high) and confirms acceptance. Importantly: FCM high priority on Android guarantees delivery even in Doze mode, but only if the app has RECEIVE_BOOT_COMPLETED and correctly configured FirebaseMessagingService.
The route to the recipient is built using Google Maps Directions API or OSRM (if a self-hosted solution without API call costs is needed). We do not implement turn-by-turn navigation in the app—we open Google Maps / Yandex Navigator via deep link, passing the delivery point coordinates.
ETA and Tracking for the Client
The client sees the courier on the map—this uses WebSocket or Server-Sent Events from the server to the client app. Coordinates are updated every 5–10 seconds. On the map, we use a Marker with animateCamera animation to ensure the point moves smoothly, not jumping—ValueAnimator (Android) or CABasicAnimation (iOS).
ETA is calculated on the server side via Google Maps Distance Matrix API or HERE Routing API and transmitted to the client. We do not compute ETA on the device—it doesn't have up-to-date traffic data.
How Is Delivery Confirmed?
Three most common confirmation methods:
- Photo of the package/door—
CameraX(Android) orAVFoundation(iOS) + upload to S3/GCS - PIN code known by the recipient—simple TOTP or static code from the order
- On-screen signature—
Canvas/UIBezierPath, saved as SVG or PNG
The signature code uses strokeWidth dependent on finger movement speed—it looks significantly more natural than a constant-thickness line.
What's Included in the Work?
- Architecture documentation and technology stack selection
- Android (Kotlin + Jetpack Compose) and iOS (Swift + SwiftUI) development
- Integration with your OMS/WMS via REST or GraphQL
- Push notification setup (FCM / APNs)
- Publishing to App Store and Google Play
- Staff training (2 days)
- 2 weeks of technical support after launch
Stages and Timeline
Minimum viable product—two apps (courier + client) with geolocation, order assignment, and delivery confirmation: 6–10 weeks with a team of two developers and a designer. Full platform with dispatcher module, analytics, and integration with external OMS/WMS systems: 4–6 months. Pricing is calculated individually after requirements analysis.
We guarantee stable operation on Xiaomi, Huawei, and Samsung devices. Order a turnkey development—contact us for a free project evaluation.