The real cost of turn-by-turn navigation

How to make a GPS navigation app: the four core systems

To make a GPS navigation app, four systems have to work together: a map renderer, a routing engine that produces turn-by-turn instructions, a location layer that reads the device GPS and fuses it with other sensors, and a data pipeline for traffic and points of interest. Only the renderer is genuinely commoditised. The other three decide your cost curve, your battery profile, and whether the app still works in a tunnel.

The market justifies the attempt. Navigation apps generated $21 billion globally in 2024, up 14.7% year on year¹, and the GPS navigation software segment alone was valued at USD 2.5 billion in 2024 with a projection of USD 5.8 billion by 2033². The incumbency problem is just as real. Google Maps holds an estimated 67% to 70% of global navigation app share¹ and has passed 2 billion monthly active users⁹. Nobody wins by shipping a better general map. Teams win by owning a job the general map does badly: fleet dispatch, last-mile delivery sequencing, campus and indoor wayfinding, off-road and marine routing, or restricted routes for hazardous cargo.

One definition to fix before the budget conversation. Turn-by-turn navigation is real-time, voice-guided routing produced by an engine that recalculates the path every time the GPS position updates. It is a different product from a map with a blue line drawn on it, and it is the piece most map SDKs do not hand you for free.

Which mapping APIs should you build on?

Choose on billing model before feature list. Mapping APIs charge in two incompatible units, and at identical usage the wrong unit can multiply your monthly run rate several times over.

Google Maps Platform bills per request. Dynamic Maps runs at $7 per 1,000 requests, Geocoding at $5 per 1,000, and Places Details between $17 and $32 per 1,000 depending on the field set you ask for³. Mapbox bills mobile usage by monthly active user, and gives you 50,000 web map loads per month plus 25,000 monthly active users before billing starts⁴.

That difference is the whole decision. A commuting or dispatch app whose users open it twice a day every working day generates heavy request volume per person and stays cheaper on monthly active user pricing. A one-time utility, such as an event wayfinder or a rental pickup locator, has many users making few calls each and comes out cheaper per request. Model both curves against your projected retention before writing a line of SDK code, because swapping the rendering layer after launch is a rewrite, not a refactor. If you are evaluating HERE or TomTom, expect enterprise agreements rather than a public price page, and get a written quote before you model anything.

Free tiers are where budgets get ambushed. Every Google Maps Platform billing account receives 10,000 free monthly events on Essentials SKUs before per-request billing begins³. That allowance resets monthly and applies per billing account, not per app, so two products under one account share it. A single misbehaving retry loop in a background service can burn a month of headroom in an afternoon.

How do offline maps work without a connection?

Offline support is not a tile download. The visual map is the easy half. What breaks first when connectivity drops is server-side route calculation, so real offline navigation needs a routing graph stored on the device: the road network as nodes and edges, carrying turn restrictions, one-way rules and speed profiles, plus a local pathfinding implementation to traverse it. Teams that budget for offline tiles and forget the offline graph ship an app that shows you exactly where you are and refuses to tell you where to turn.

The second decision is tile format. Vector tiles deliver map data as scalable geometry and style rules rather than pre-rendered images, letting the device draw, rotate and restyle the map locally instead of fetching a new picture per view. Raster tiles are pre-rendered images. Vector wins on offline storage, since one geometry set serves every zoom level and rotation. Raster wins on rendering cost, because the device is compositing images rather than running a style engine every frame. On a five-year-old mid-range Android handset, that gap is visible in both frame rate and heat.

Three practical rules follow. Scope offline packs by region rather than offering a whole-country download that nobody can store. Version the routing graph separately from the tiles so a road closure update does not force a 400 megabyte re-download. And test the handoff explicitly: the app must fall back to the local graph mid-route, without losing the current instruction, when the connection drops in a valley or a car park.

Where does navigation battery drain actually come from?

Not where most teams look first. Continuous GPS combined with map rendering accounts for 68% of total navigation-related battery drain, against 22% from screen-on time and 10% from background sync and sensors⁵.

The engineering conclusion is counterintuitive. The instinct is to lengthen the GPS polling interval, which degrades the product for a modest return. The larger share of drain sits in what happens after the fix arrives: the map re-renders, labels recalculate, the camera animates, and the screen stays lit. Cut render frequency when the vehicle is stationary or moving in a straight line at constant speed. Drop label and 3D building detail above a speed threshold. Dim the display on long motorway stretches with no upcoming manoeuvre. Then, and only then, look at location accuracy tiers. Teams that reverse this order lose route quality and keep the battery problem.

What does a GPS navigation app cost to build and run?

Treat that as the entry ticket rather than the total. Navigation app development carries an unusually heavy running cost, because the app keeps consuming paid API calls for as long as it has users. Three line items deserve their own budget row from day one.

• The API bill. Forecast it per active user per session, not per month in aggregate. A route recalculation, a search autocomplete session and an arrival geocode are separate billable events.
• Map data refresh. Offline packs go stale. Someone has to rebuild, test and ship them on a schedule, and that schedule is a product commitment your support team will be held to.
• Store compliance. Location permission rules move. Each move can force UI work, a fresh disclosure screen and a re-submission.

The reliable way to control all three is to fix scope before estimating, which is the part of the software development life cycle that navigation projects most often skip.

How do you solve the live traffic cold start?

Crowdsourced traffic has a chicken-and-egg problem: the data is only useful at density, and density only arrives once the data is useful. The comparison worth studying is engagement, not downloads. Waze users average 269 minutes per month in app, against 12 minutes for Apple Maps users⁸, and Waze reported 50.5 million average monthly users in the EU for the second half of 2024¹⁰. Deep session time is what makes passive speed reporting statistically usable.

A new navigation app should buy its traffic feed and earn its crowdsourcing, not the other way round.

In practice that means launching with a licensed traffic layer, instrumenting anonymous speed telemetry from the first release, and switching to your own data city by city, only where you have crossed a density threshold you defined in advance. Restricting geography at launch is a feature, not a compromise. Ten well-covered postcodes beat a nationwide map with nothing moving on it.

Which stack and permission choices matter most?

Background location is the single highest-risk item in the build. Both iOS and Android tightened background location rules again through 2025 and 2026, and an app requesting always-on location now needs an in-app disclosure screen that explains the use in plain language before the system prompt appears. Without it, store review rejects the build. Design that screen with the same care as onboarding, because it is onboarding.

On stack, the honest split is by layer rather than by framework. Cross-platform tooling handles the shell, the search and settings screens, and the trip history well. The navigation session itself, background location, sensor fusion, audio ducking for voice guidance and low-level rendering, is where native modules earn their cost. Most credible mobile app development plans for this category end up hybrid: a shared product surface with native cores for the location and rendering paths, rather than a purist answer either way.

Geofencing sits alongside this. A geofence fires an app event when the device enters or leaves a defined virtual boundary, which is how arrival alerts, depot check-ins and point-of-interest prompts work without keeping a continuous location subscription open. Used well, it removes work from the battery budget instead of adding to it.

How to make a GPS navigation app people keep using

Cut to a corridor, not a country. A first release that routes reliably in one metro area, works offline on the routes users actually take, and holds a two-hour drive on a half charge will teach you more than a national launch with three headline features. Ship search, a single route with turn-by-turn voice guidance, offline packs for the launch region, and arrival geofencing. Leave multi-stop optimisation, lane guidance and social reporting for release two.

Instrument before you add. Battery per navigated hour, offline fallback success rate, route recalculation latency and API spend per active user are the four numbers that should govern the roadmap. If you want a second opinion on the architecture or the run-rate model before committing, our engineering teams work on exactly these tradeoffs, and you can start that conversation here.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.