Courier Mobile App Development with Smart Navigation & Battery Optimization
A courier app must handle three distinct usage modes: walking, cycling, and driving. Each mode imposes different requirements on UI, navigation, and power consumption. A walking courier holds the phone in hand, a cyclist keeps it in a pocket, and a driver uses a dashboard mount. Our experience includes projects for courier services handling tens of thousands of orders per day. We guarantee stable app operation throughout an entire shift. Our courier software has been tested on thousands of shifts and helps reduce delivery time by 15%.
How the Task List Is Organized
The courier sees a queue of tasks sorted by route, not by order creation time. A map + list combination is mandatory. Tapping a task in the list centers the map on the point; tapping a marker opens task details. The task pool can change in real-time: a dispatcher may add an urgent order along the way. Updates happen via WebSocket — a new task appears in the list with an insertion animation (DiffUtil on Android / withAnimation in SwiftUI), along with a sound alert and vibration. WebSocket updates the task list 10 times faster than polling, so we use it by default.
Why WebSocket Instead of Polling?
Polling creates unnecessary load on the server and battery. WebSocket maintains a persistent connection, keeping task delivery delay under 1 second. For a courier app, this is critical: urgent orders should not wait.Navigation for Walking Couriers
For a walking courier, turn-by-turn driving navigation is useless — it routes along roads. Google Maps SDK supports a walking mode (travelMode: walking), as described in the Google Maps Platform documentation. Mapbox Navigation SDK also supports walking routes. The route will go through courtyards and pedestrian crossings, not around the block. Importantly, the courier's screen often displays the list or chat, not the map. Voice prompts via TTS (AVSpeechSynthesizer / TextToSpeech) work over any screen and allow the courier to avoid looking at the phone. According to our statistics, 78% of couriers use voice prompts.
How to Reduce Battery Consumption
A courier shift lasts 8-10 hours. During that time, a ForegroundService with GPS and an open map can completely drain the battery. Our optimizations: in standby mode (courier at a point), we reduce GPS frequency to 1 update per 60 seconds; the map in the app uses Lite Mode (Google Maps) for the list, with a full map only for navigation; screen brightness is set to auto, not forced to maximum. On Android, we do not prevent system Sleep in standby mode (only in navigation mode we hold SCREEN_BRIGHT_WAKE_LOCK). Thanks to these measures, over 90% of couriers do not report battery drain.
| Optimization Technique | Effect | Application |
|---|---|---|
| Reduced GPS frequency | 30% battery savings | In standby mode |
| Lite Mode map | 20% battery savings | On the list screen |
| Auto brightness | Up to 15% battery savings | Always |
Delivery Confirmation: Three Scenarios
| Scenario | Photo Required | Coordinates Recorded | Notes |
|---|---|---|---|
| Recipient at home | No | No | Tap "Handed over" |
| Left at the door | Yes | Yes | Photo taken from app, geo-tag from server |
| Did not meet | No (photo not required) | No | Reason from list, choose next action |
For "left at the door" photos, the app uses camera capture directly (CameraX / AVCaptureSession), and geo-tags and timestamps come from the system (not EXIF, which can be faked — they come from the server upon upload). Upload with retry: if LTE is poor in a stairwell, the photo will be sent as soon as internet is available. Electronic signature of the recipient is optional. It is implemented via UIBezierPath (iOS) or Path on Canvas (Android), saved as SVG or PNG.
Communication with the Client
Making a phone call from the app uses the tel: URI scheme, simple. But better: a masked number via a VoIP gateway (Twilio, Voximplant) — the courier does not see the client's real number and vice versa. Additionally, a chat with preset templates ("I'll be there in 5 minutes", "Can't find the intercom", "Where should I leave it?").
Typical Mistakes in Courier App Development
- Ignoring walking routes for foot couriers — leads to time loss.
- Missing background geolocation — tasks don't arrive when the app is minimized.
- Compressing photos to 50 KB — address readability on doors is lost. We recommend 200 KB.
- Not using WebSocket — task delays of up to 30 seconds with polling.
What Is Included in the Work
- Mobile app for iOS and Android (or cross-platform)
- Server side for push notifications (APNs / FCM) and WebSocket
- Integration with your CRM via REST API
- User manual for dispatchers and couriers
- Technical support for 1 month after release
Timeline: from 6 to 12 weeks for a courier client. Cost is calculated individually. Contact us to evaluate your project — get a consultation on integration with your CRM. Order app development and receive a free audit of your current processes.