Building Offline Maps and Location Features
For a field-services app used by technicians visiting rural sites with unreliable cellular coverage, an online-only map — standard tile fetching against MapKit or Google Maps — simply failed the core use case: technicians would arrive at a job site with zero signal and no way to see the map at all. We switched to Mapbox's offline region download, letting users pre-download a bounded map area, their service territory, while still on Wi-Fi or good signal, stored locally as vector tile packs.
Storage budgeting mattered once we saw real usage. A single detailed offline region covering a mid-sized county ran 150-300MB depending on zoom level range downloaded, which added up fast across the multiple territories some technicians covered. We capped default download zoom range to what the workflow actually needed, street-level rather than building-level detail, and gave users an explicit storage management screen to delete regions they no longer needed.
Turn-by-turn navigation offline required a separate routing engine, since standard online routing APIs need a live connection to compute directions. We used Mapbox's offline navigation SDK with pre-downloaded routing graphs for the same regions, which worked well but meant every offline region download was really two downloads — map tiles and routing data — that needed to stay in sync with each other.
Location logging while offline used the same outbox pattern we've used for offline chat: GPS breadcrumbs and check-in events get written to a local SQLite table with timestamps, then synced in batch once connectivity returns, ordered by original timestamp rather than sync order. This mattered for a client whose billing depended on accurate site-visit duration, since syncing by arrival order rather than preserving original timestamps would have shown incorrect visit durations for technicians who worked multiple offline sites in one day.
The main lesson is that 'offline maps' isn't one feature, it's map tiles, routing, geocoding and search, and location logging, each needing its own offline strategy and its own storage and sync plan. Treating them as a single 'add offline mode' checkbox item, which is how the client originally scoped the work, undercounted the effort by roughly half.
