The hardest part of web navigation wasn’t the map. It was the phone.

I thought “scan a QR code and walk” would be the easy version of navigation. Then I tried to make it work on real mobile browsers, with real GPS noise, and real people who don’t care why the dot is teleporting.

I built a map. Then I tried to make it guide someone.

The original idea was almost boring: a web map you can open instantly. No app install. No account. No app store drama. Scan a QR code, see the route, start walking.

That part worked. A web map is solved engineering. Tiles load. Markers show up. Routes draw clean lines. People smile. Then someone asked the obvious question: “Can it navigate?” Not “show a route.” Navigate. As in: keep the blue dot moving, keep the direction stable, and don’t lie when you’re wrong.

I said yes. Not because it was easy, but because I didn’t yet understand what “navigation” means on the mobile web.

GPS isn’t a dot. It’s a moving guess with a confidence radius.

The first time you watch a real user walk with browser-based navigation, you stop believing in clean demos. The dot drifts into buildings. It pauses at intersections like it’s thinking. It jumps to the parallel street. Sometimes it spins in place, like the map is trying to summon direction from vibes.

None of this is a “bug” in the sense you can fix with a better loop. The Geolocation API is explicit about what it is and isn’t: you get location data, but there’s no promise it’s the device’s “actual location.” The API is agnostic to the underlying signals, and accuracy depends on what the device and OS can provide in that moment. Indoors, in an “urban canyon,” near reflective glass, or in a crowded street, you’re fighting physics more than code.

Once you accept that, you stop treating each position update as truth. You treat it as a noisy stream. You look at timestamps. You look at accuracy. You assume it will be wrong sometimes, and you design for that.

If your UI acts like GPS is certain, your users will learn to stop trusting it.

This is where I started adding the unglamorous features that make navigation feel “real”: a clear “GPS is weak” state, smoothing that doesn’t hide big jumps, and logic that refuses to overreact to one bad update. The goal wasn’t perfect tracking. It was honest tracking.

The iPhone problem: permissions, sensors, and WebKit reality.

Android gave me normal problems: variable accuracy, device-specific behavior, battery optimizations, and occasional weirdness. iPhone gave me a different category of pain: rules that change based on gesture, context, and whatever Safari decided was “safe” today.

Start with permissions. The Geolocation API requires user permission, and it’s supposed to be straightforward: ask once, then you’re either allowed or not. In practice, iOS can make this feel unpredictable. Even Apple’s own developer forums have people calling geolocation permissions in Safari “a nightmare” because the state can stay “prompt” across multiple cases and doesn’t map cleanly to how you’d like to handle UX.

Then there’s heading. Real turn-by-turn guidance wants a stable direction. On the web, you typically reach for motion/orientation events and build a compass. But modern browsers gate access to motion and orientation data behind explicit permission flows, and on iOS you often need to trigger the request from a user interaction. That sounds reasonable until you try to build a flow that doesn’t feel like a pop-up obstacle course. The standards story is also clear: the device orientation spec requires express permission through requestPermission() style calls.

Finally, there’s the uncomfortable fact nobody wants to hear: on iOS, browser diversity is limited in practice because WebKit has historically been the required engine for iOS browsers. So if Safari struggles with something, “try Chrome” doesn’t necessarily save you, because you’re still living in the same engine constraints. Apple has started supporting alternative browser engines in the EU under specific conditions, but you can’t build a product assuming every user benefits from that shift yet.

This is the part where people tell you to “just implement it correctly,” as if correct code can override platform policy. It can’t. You end up building a navigation experience that is partly engineering and partly negotiation with iOS.

When the screen sleeps, your navigation dies.

The most brutal bug wasn’t a crash. It was silence. A user starts walking. Everything updates. Then their screen dims, or they switch apps, or the device decides the page is “inactive.” Suddenly your smooth loop stops receiving updates, timers drift, and you’re left pretending nothing happened.

This isn’t surprising if you zoom out. iOS is designed to suspend work in the background unless you’re a native app using a specific background mode. Apple’s own documentation is blunt: apps typically get suspended in the background, and only limited background execution modes exist. A web page isn’t going to win that fight.

So you try workarounds. You reduce update frequency. You reinitialize watchPosition() when the app returns. You detect staleness by checking timestamps. You show a banner that says “keep the screen on for live navigation,” because that’s the truth even if it feels like a regression.

Then you look at the Screen Wake Lock API. In theory, it’s exactly what you want: keep the screen awake during navigation. It exists for this kind of use case. In practice, support has been uneven across versions and modes, and installed web apps have had their own quirks and bugs, including WebKit reports where wake lock works in Safari but fails when the same site is added to the home screen. That kind of edge case is why mobile web navigation is a craft project, not a checkbox.

What finally made it feel reliable

I stopped chasing “perfect navigation” and started shipping a system that behaves like a cautious guide. It doesn’t panic. It doesn’t overpromise. It keeps moving forward, but it tells you when the inputs are weak.

The changes that mattered weren’t exotic. They were practical:

• Treat location as a stream, not a truth. Smooth small noise, but don’t hide big jumps.
• Use accuracy and timestamps. If the last fix is old or wide, say so.
• Design a “weak signal” mode that still helps: show the route, show the next landmark, stop pretending the dot is precise.
• Ask for sensor permissions in a clean moment, triggered by a deliberate user action, not a surprise modal loop.
• Plan for sleep. Assume the device will pause your page and make resuming graceful.
• Use wake lock when available, and have a clear fallback message when it isn’t.

The end result isn’t magic. It’s something better: it’s predictable (kinda). Users forgive drift if your app stays coherent. They don’t forgive a UI that confidently points the wrong way.

And yes: iPhone was the hardest platform for this. Not because it’s “bad hardware,” but because the mobile web on iOS has stricter gates, less forgiving background behavior, and fewer escape hatches (and i hate it!). Once you accept those constraints (I didn't), you can build something honest that works most of the time, and fails in a way that doesn’t insult the user’s intelligence (I will insult it!).