Building a Real-Time Taxi Booking App with Live Maps
A React Native taxi booking app with live driver tracking on the map. Replacing 5-second polling with WebSockets cut location delay from 4-5 seconds to under one, and API traffic by roughly 70%.
<1s
Location delay
70%
Fewer API calls
25%
Battery savings
WhatsApp messaging gets complicated at scale.
Most taxi apps rely on continuous location updates and map rendering, which introduces serious real-world challenges. The first version of this one used REST polling: the rider's app asked the server for the driver's position every five seconds, and the server answered whether or not anything had changed. On paper that is simple. On a phone it was visibly broken. Driver movement appeared jumpy, because a marker that updates once every five seconds jumps between positions rather than travelling along a road. Location delay ran to four or five seconds, so the car drawn on the map was consistently behind the car in the street. And the app made roughly sixty API requests per minute per user, the overwhelming majority of which returned a position the rider had already seen. That cost compounds in three directions at once. Network traffic scales with the number of active riders rather than with how much anyone is actually moving, so a busy hour costs the same whether the fleet is driving or parked. The map re-rendered on every update, and redrawing the full marker set on a schedule made the whole interface sluggish to touch. Continuous GPS tracking at full accuracy kept the radio and the location subsystem working without pause, and drained the battery fast enough that riders noticed. The real damage was to trust. A rider watching a taxi app is checking one thing: where is my driver right now. A four to five second lag answers a question about the recent past, and a rider who catches the map being wrong stops believing the arrival estimate next to it. Every problem below is a version of that one.
Challenge 1
Continuous REST polling causes high network usage and visible lag
Challenge 2
Non-stop map re-renders make the UI slow and unresponsive
Challenge 3
Continuous GPS tracking drains battery quickly
Challenge 4
4–5 second location delays destroy user trust
Real-time is a property of the transport, not of the interval. Shortening a polling loop trades battery and bandwidth for latency; a persistent socket removes the trade instead of rebalancing it.
Map performance is a render problem before it is a map problem. Memoizing markers so only the one that moved re-renders is what buys 60fps, not anything inside the map SDK.
Fetch a route on a threshold, not on a timer. A Directions result stays valid for as long as the driver follows it, so the only honest trigger for a re-fetch is deviation from the route already drawn.
GPS accuracy is a dial, not a switch. Sampling rate and precision should scale with ride state, because an idle app does not need what an app mid-pickup needs.
Battery optimization is non-negotiable for any location-based mobile app. It is not a polish task at the end, it constrains the architecture from the first decision onward.
Built with technologies we trust.
Project Goals
The Outcome
We rebuilt the location layer around a persistent WebSocket connection instead of a polling loop, then optimized the map rendering and the GPS sampling around it. The result is a real-time taxi booking app where the marker tracks the driver closely enough to be worth looking at. Location delay dropped from four or five seconds to under one. API requests fell by roughly 70%. Battery consumption came down about 25%, and visible map lag went to zero. The app ships on iOS and Android from a single React Native codebase. A Node.js service holds the socket connections and fans position updates out to the riders subscribed to each ride. Google Maps supplies the map through react-native-maps, the Directions API supplies routes and arrival estimates, and the platform geolocation APIs supply the driver's position. Built in seven weeks. None of that is exotic. Every piece is a documented API used roughly the way its documentation suggests. What made the difference was choosing the right transport for the data first, and then refusing to re-render or re-request anything that had not changed.
Conclusion & Impact
"This project surfaced the real challenges of building location-based, real-time systems in mobile applications, and most of them turned out to be about restraint rather than capability. The transport decision was the one that mattered. Polling asks a question on a timer; a socket delivers an answer when there is one. Once the connection was persistent, the delay budget stopped being set by the polling interval and started being set by how fast the driver's device could report, which is where it should have been from the start. Everything after that was about not doing work. Not re-rendering markers that had not moved. Not re-fetching a route that was still valid. Not sampling GPS at full accuracy while the app sat idle. Each one is a small decision, and together they account for the battery and API numbers more than any single optimization does. The pattern generalizes past taxis. Anything that tracks a moving object on a map pays the same three costs: the transport, the render, and the sensor. Get the transport right first, because the other two are only worth optimizing once the data arriving is actually fresh."
Have a project in mind?
Let's discuss how we can help you build your next big thing.
Reach out and our team will be in touch.
Building systems that
hold up in production.
Bring up the problem others won't attempt.