We develop taxi dispatch mobile apps — not just a map with markers. It's real-time dashboards displaying dozens of drivers, order queues, and trip statuses simultaneously. The taxi driver map is updated in real-time via WebSocket. The map rendering performance requirements are higher than in driver or passenger apps, and the business logic is significantly more complex. In one project with 80 drivers, the map froze for 5 seconds on each update — we rewrote the rendering to Mapbox with a canvas layer, and the freezes disappeared. Over our work, we have implemented more than 15 projects for taxi fleets and delivery services. Taxi app development also includes robust taxi order management and real-time analytics. Our clients save up to 30% time on order processing, which translates to average monthly savings of $5,000 for a fleet of 50 drivers. Typical project costs start from $30,000.
A typical dispatch console runs on an Android tablet or iPad, where the dispatcher sees a map with clustered markers, accepts orders, and assigns drivers. The fleet app includes a dispatch module. For taxi offline mode, we cache last known state and queue updates. Dispatch notifications are sent as push alerts.
Architecture of the Taxi Dispatch App
We use MVVM with ViewModel, Repository, and UseCase layers, reactive state (StateFlow / RxSwift), WebSocket via OkHttp (Android) or URLSessionWebSocketTask (iOS), maps — Google Maps SDK or Mapbox. For cross-platform — Flutter with native plugins.
Ensuring Smooth Map Performance with 100+ Markers
Displaying 50–100 driver markers simultaneously is the first thing that breaks naive implementations. Google Maps SDK and MapKit have performance limitations when constantly updating a large number of markers. On Android, updating 80 markers every 3 seconds via marker.position = newLatLng causes noticeable freezes on budget devices. Taxi map optimization ensures smooth scrolling and clustering of markers. We reduce rendering load by up to 40% using canvas layers.
Solutions:
- Clustering — group nearby markers at low zoom levels. We use Google Maps Utility Library (
MarkerClusterManageron Android,GMUClusterManageron iOS) or Supercluster (JavaScript port via React Native Maps). Clustering can be up to 5 times faster than displaying individual markers. Zooming into a specific area breaks clusters into individual cars. - Renderer optimization — on Android use
GoogleMap.setOnCameraIdleListenerto update only the visible region. Update markers only for drivers in the currentVisibleRegion, batch the rest and update on scroll. - Canvas rendering — for aggressive scaling: Mapbox Maps SDK with native layer via
SymbolLayer— symbol positions are updated through GeoJSON source without creating/removing markers. This is fundamentally faster for 100+ objects.
For iOS we use GMUClusterManager with custom GMUDefaultClusterIconGenerator. Every 2 seconds we get the driver list via WebSocket, update GeoJSON, and call clusterManager.cluster(). Result: 100 markers displayed without freezes on iPad 6th generation.
| Method | Performance | Implementation Complexity | Custom Icon Support |
|---|---|---|---|
| Standard markers | Low | Low | Yes |
| Clustering | Medium | Medium | Yes |
| Canvas rendering (Mapbox) | High | High | Yes, with custom animations |
Order Distribution Without Conflicts
The dispatcher can work in two modes: manual assignment and automatic control. In manual mode, they see the order on the map, press "assign", and select a driver from the list of nearest (sorted by distance from pickup via Distance Matrix API or server-side calculation via PostGIS).
Conflict on simultaneous assignment: two dispatchers assign the same order to different drivers. Solution — optimistic locking on the server (version field in the order) + error message on UI suggesting to reload the list. This approach reduces conflicts by 90%.
Integration Capabilities with Existing Dispatch Systems
We connect to any backend system via REST API and WebSocket. In high-load projects we use GraphQL (Apollo) for flexible data fetching. Dispatch system integration is a key part of our taxi app development. Message queues (RabbitMQ or Kafka) guarantee event delivery even during temporary network failures. Documentation is available in Swagger.
| Single app | Integration with system | |
|---|---|---|
| Time to market | 6-8 weeks | 10-18 weeks |
| Business logic flexibility | High | Very high |
| Cost of changes | Low | Medium |
App Functionality with Poor Internet
A dispatcher in a taxi fleet may have weak Wi-Fi. WebSocket reconnect with exponential backoff is mandatory. On connection loss — show a "no connection" banner, request a snapshot of the state (all orders, all drivers) upon recovery, rather than relying on all events during the break coming through the queue.
Notifications and Sound Alerts
New order — sound alert + vibration, even if the app is in the background. On iOS: notification content extension for custom notification UI. On Android: NotificationChannel.IMPORTANCE_HIGH + custom sound via Uri resource. The dispatcher's tablet should sound like a two-way radio — no system "dings".
Real-Time Analytics
A small statistics module within the app: number of active drivers, orders in progress, average wait time. Data from WebSocket events aggregated locally. No need for a separate backend endpoint for each metric — just count from the event stream in memory. Taxi real-time analytics and map optimization are built-in.
How We Work
- Analysis — gather requirements for screens, order types, and integration with existing systems.
- Design — draft architecture, choose stack, agree on flows.
- Implementation — write code with CI/CD, code reviews, unit tests.
- Testing — load testing with 200+ markers, regression on real devices.
- Deploy — publish to App Store / Google Play, configure TestFlight and Firebase Distribution.
What's Included
- Source code in a private Git repository with commit history.
- API documentation in OpenAPI (Swagger) format.
- Instructions for deploying backend and configuring cloud services.
- Training for the dispatcher team on using the app (up to 2 hours).
- 12-month warranty support from the date of the acceptance certificate.
- Quality certificate and licensed code purity.
Timelines and Cost
Implementation time: from 10 to 18 weeks depending on integration complexity (number of clients, order types, offline mode). Cost is calculated individually — contact us with a description of your taxi fleet and current processes, and we will prepare an estimate within 2 business days. For accurate calculation, we use an hourly rate and fix the scope in the technical specification. Typical project costs start from $30,000. On average, dispatch time decreased by 40% compared to manual processes. The app handles up to 500 markers with clustering, maintaining 30 fps on budget devices. 95% of orders are assigned within 10 seconds.
For a detailed proposal, please provide your fleet size, number of dispatchers, current software, and specific requirements. We will prepare a tailored solution within 2 business days. We guarantee the app will pass App Store moderation on the first attempt (sections 4.2 and 5.1 of the Review Guidelines).







