Real-Time Geolocation in Production: The My Home Delivery Build at SEM Nexus
Real-time driver location tracking is the feature that founders demo on slide 4 of their pitch deck and that breaks in week 2 of a real deployment. Battery drain. Background-mode restrictions. iOS-vs-Android divergence. Network flakiness. Permission UX. Privacy regulations. Multi-party visibility. Every one of those is a separate engineering problem, and every one of them is what kills the average "we'll figure it out" location implementation.
SEM Nexus shipped the My Home Delivery location stack clean. Customers see the driver on the map in real time. Drivers see the next job, the route, the navigation. The platform owner sees every active driver, every active job, every aggregate metric. The system has been running in production for two years without driver-side revolt or customer-side trust collapse. This is how that worked technically.
What "real-time location" actually requires
The phrase is deceptive. A real production location stack has at minimum five subsystems:
- Foreground location streaming. While the driver has the app open and is actively delivering, the device emits location updates at a high cadence (1–5 second intervals).
- Background location. When the app is backgrounded but the driver is on a job, the OS has to keep the location stream alive. iOS and Android handle this differently, both restrictively.
- Server-side ingestion + fan-out. The customer's app needs to see the driver moving in near-real-time. That means the backend has to receive each update, persist what matters, and push the rest to subscribers.
- Map rendering on the client. Customer-side map showing driver location, route progress, ETA.
- Permission UX and graceful degradation. When the user denies location, when the OS revokes it, when the driver is in a tunnel — the app has to behave correctly.
Each of these has known failure modes. Most "we'll figure it out" implementations break on at least three of them by month two.
What SEM Nexus shipped
Foreground location: native modules behind a React Native facade
My Home Delivery is React Native. For most of the app — list views, forms, payment flows, push notifications — RN's standard libraries were fine. For location specifically, we wrote thin native modules on both iOS and Android that handle the platform-specific permission and lifecycle quirks, and exposed a clean RN interface to the application code.
That decision sounds obvious in retrospect; it's not. Many React Native marketplaces ship with a single off-the-shelf location library and trip over its limitations later. We picked the cleanest abstraction layer to write ourselves because location is the kind of feature where the abstraction needs to fit the project exactly.
Background location: separate state machine per platform
iOS and Android have meaningfully different background-location stories.
- iOS allows continuous background location for apps with the appropriate entitlements (e.g.,
locationbackground mode) but throttles aggressively under low battery. The OS will pause the stream and resume it; the app has to handle the resumption cleanly. - Android requires either a Foreground Service with a persistent notification (the modern compliant approach) or careful use of the Fused Location Provider with WorkManager fallbacks.
We wrote a state machine per platform that handles app lifecycle, OS interruption, and resumption. The state machines emit identical events into the React Native layer, so the application logic above doesn't have to know which platform it's running on.
Want this level of platform-specific engineering on your project? SEM Nexus's senior engineers write the platform-specific layers themselves instead of trusting library defaults that break in production.
Server-side: lean ingestion, fan-out via subscribers
The Laravel back-end receives location updates over a lightweight endpoint. Updates are persisted to the job record (for replay / audit / dispute resolution) and pushed to subscribers via a real-time channel.
Subscribers include the customer's app (showing the driver moving on the map), the platform admin dashboard (showing all active drivers), and downstream services that compute ETAs and trigger notifications. We tuned the cadence carefully: aggressive enough to feel real-time, sparse enough to keep server costs and battery drain in check.
Map rendering: native map components, not WebViews
On the customer side, we used native map components on both platforms. WebView-based maps look fine in demos and feel sluggish in production. The customer-side experience is where founders most often cut corners on map rendering, and the corner-cutting is visible.
Permission UX
When the driver first launches the app, permission requests happen in a specific order, with custom rationale screens that explain why the app needs continuous background location. Without this, drivers tap "Don't Allow" out of habit and the entire flow breaks.
When permissions are revoked mid-job, the driver sees a clear in-app warning and a one-tap path to the OS settings page. The customer-side experience continues with a "driver location temporarily unavailable" indicator instead of a confusing silent failure.
What the prior pattern would have looked like
Most marketplaces at this stage of fund-raising hire a contractor or a stack-locked agency and ship a single off-the-shelf location library. The result by month 3:
- Battery drain complaints from drivers (off-the-shelf libraries are not tuned for delivery use cases)
- Background tracking that quietly stops working on iOS 17+ updates
- Customer-side maps that lag the driver's actual position by 30+ seconds
- Permission UX that fails for 15–25% of drivers on first install
SEM Nexus's My Home Delivery build hit zero of these in production. The location stack was treated as a first-class engineering problem in discovery, named as the hard part in the technical recommendation, and built by a senior engineer who'd shipped location-stack work before.
The architecture summary
For founders evaluating their own location-stack build:
| Layer | What we shipped | Common shortcut to avoid |
|---|---|---|
| Client foreground | Native modules behind RN | Off-the-shelf RN library |
| Client background | Per-platform state machines | "Just enable background mode" |
| Server ingestion | Lean Laravel endpoint with subscriber fan-out | Direct DB writes for every update |
| Server fan-out | Real-time channel, tuned cadence | 1-second polling |
| Customer-side map | Native map components | WebView map |
| Permission UX | Rationale screens + revocation handling | Default OS prompt only |
If your project has real-time location in v1, the engineering effort is materially higher than the demo suggests. Budget it accordingly.
Two production lessons
Tune cadence per role. Customers don't need driver position updated every second — every 3–5 seconds is fine. Drivers need their next-step navigation updated faster. The cadence we ship is role-aware, not global.
Replay matters. Every location update is persisted, not just streamed. When a dispute happens ("the driver said they were at my house, they weren't"), the platform owner can replay the route. This single capability saves the platform from being the arbitrator of every dispute.
What this signals about SEM Nexus
Real-time location is one of the technical-hard-parts categories where the difference between a good agency and a forgettable one is enormous. We shipped My Home Delivery's location stack clean because senior engineering on this category is in our bench. We could not have shipped it with junior engineers and an off-the-shelf library.
If your project has a location component — marketplace, delivery, logistics, field-service, dating, ridesharing — and you'd like the build done by people who've already shipped this exact problem to production, SEM Nexus's two-week discovery is where to start. We'll name the location stack as the hard part in writing, scope it correctly, and back the build with a fixed quote.
