Taxi Driver Mobile App Development
Driver app for taxi — technically most complex of three clients (driver, passenger, dispatcher). Must work in background for hours, accept orders even with unstable internet, track route precisely, not drain battery during shift. Most MVP problems surface right here.
Background mode and geolocation: where it breaks
Driver doesn't hold phone constantly. App must:
- Receive new orders via push with screen off
- Continue route tracking in background
- Update server with current position every 3-5 seconds
On iOS means CLLocationManager with allowsBackgroundLocationUpdates = true, background mode location in Info.plist and separate pausesLocationUpdatesAutomatically = false. App keeps background process only while location manager active. If driver accepted order — location updates constantly. If waiting — can switch to startMonitoringSignificantLocationChanges() for battery economy.
On Android — ForegroundService with persistent notification. Without it MIUI 14, EMUI 12, Samsung OneUI 6 kill process 5-10 minutes after screen lock. FusedLocationProviderClient with PRIORITY_HIGH_ACCURACY and 3000 ms interval in trip mode, PRIORITY_BALANCED_POWER_ACCURACY with 30 second interval waiting mode. Switch modes by order status from business logic.
Accepting orders and offline scenarios
New order comes as FCM/APNs data push. Driver accepts or declines — must work even with bad connection (tunnels, parking). Right scheme: local queue of accepted/declined decisions with retry logic on WorkManager (Android) or BackgroundTasks (iOS). If response doesn't arrive in 10 seconds — retry attempt, else dispatcher considers order not accepted.
Order acceptance timeout — classic pitfall. Server gives driver 15-20 seconds. If push arrived delayed (FCM can delay minutes in Doze mode) — driver sees order, taps "accept," gets "order already assigned" error. Solution: order creation timestamp in push payload, client checks order age before showing dialog.
Navigation and route building
Maps integration — key part. Options:
| SDK | Pros | Limitations |
|---|---|---|
| Google Maps SDK + Directions API | Best route quality | Paid at high volumes |
| Mapbox Navigation SDK | Offline maps, flexible UI | Requires tile tuning |
| 2GIS SDK | Good СNG coverage | Limited API |
| HERE Navigation SDK | Real-time traffic | More expensive |
For driver app turn-by-turn with voice guidance important. Mapbox Navigation SDK for iOS and Android has ready NavigationViewController / NavigationView with customizable UI. Google Maps doesn't provide ready turn-by-turn UI — need to build self on Directions API + TTS.
Rerouting on deviation — rerouting should trigger automatically when deviating from track >50-100 meters. Mapbox has it built in, Google — need to implement self via periodic Directions API calls.
Order state machine
Driver app — strict finite state machine. States: idle → offer_received → accepted → en_route_to_pickup → arrived_at_pickup → in_trip → completed. Each transition — server request with confirmation. UI blocks buttons until response to prevent double-taps.
"Arrived" tapped twice — real problem: driver tapped, didn't respond (network lag), tapped again, both commands arrived. Server must be idempotent on transition, client — show spinner and block repeats until response.
Trip cost calculation on client
Server calculates preview price. But final price during trip must update real-time: taximeter. Distance — from accumulated GPS track points (sum distances between points via Haversine or vincenty formula), time — system timer. Local calculation important for offline scenario and so driver sees actual amount without constant server requests.
Architecture and stack
Clean Architecture with layers: presentation (ViewModel / BLoC), domain (use cases), data (repositories). For cross-platform — Flutter with native modules for location and push; for native — Swift + UIKit/SwiftUI on iOS, Kotlin + Jetpack Compose on Android.
Real-time data exchange — WebSocket or MQTT for coordinates and statuses. MQTT preferable with unstable connection: QoS 1 guarantees delivery, small overhead, reconnect support out of box.
Stages: analyze driver scenarios → design order FSM → location module → navigation → push and notifications → backend integration → test on real device fleet → publish.
Timeline: 8 to 16 weeks for full driver app. Cost calculated individually after requirements analysis.