David Smith — the indie iOS/watchOS developer behind Pedometer++ — published a piece this week reflecting on a stretch of work that should make every product engineer pause: six years spent perfecting one feature, the maps view on Apple Watch. Pedometer++ v8 shipped in April 2026 with a fully custom SwiftUI mapping engine that Smith built from scratch, deliberately bypassing Apple’s MapKit. The HN comments section is full of people quietly shocked at the timeline. So am I — and not for the obvious reason.
What he actually built
The end product is a tile-based map renderer that runs entirely in SwiftUI on a watch processor. No MapKit; Smith said its customisation hooks weren’t deep enough for the dark-mode and topographic-detail variations he wanted. He commissioned a cartographer (Andy Allen) to design custom map tiles tuned for watchOS’s “Liquid Glass” UI layering, then partnered with designer Rafa Conde to solve the harder UX problem: how do you fit a map AND running metrics on a 41 mm screen without ending up with a settings hellscape?
The answer they landed on is a “tap-to-browse” interaction model — the metrics live as the default surface, and you tap once to swap the focus to map. No mode toggles. No nested settings. Smith says it survived hundreds of miles of his own real-world testing, which is the only kind of testing that matters for this category of app.
The contrarian choice
Most of the discussion online is anchored on “six years is a long time to ship a feature”. I think that’s the wrong frame. The interesting choice in Smith’s story isn’t the duration — it’s the decision, somewhere in year two or three, to throw out the platform’s built-in solution and build a replacement. Pedometer++ is a one-person company. Custom cartography is expensive. SwiftUI on watchOS is famously a constrained surface. He chose a path with maximum effort and zero institutional support, on a feature that 80% of his users probably take for granted.
That’s the contrarian move. The default for an indie developer in 2020 was: import MapKit, drop in a tile view, ship it, move on. Smith’s diagnosis was that “good enough” wasn’t good enough — that fitness mapping on a watch is a craft problem, not a config problem, and the platform’s defaults were optimised for general use cases rather than runners specifically. So he built his own.
What this tells you about Apple Watch as a 2026 platform
Two things, both quietly important:
- The hardware is finally fast enough. Smith explicitly says his early experiments hit walls around watch CPU and screen pixel budget. The S9/S10 generation chips changed the math. Custom tile rendering at 60fps in SwiftUI is something you couldn’t have done in 2019. Today, it’s a one-developer project.
- SwiftUI on watchOS is now load-bearing. Smith notes UIKit on watchOS was never really an option, and his entire stack rests on SwiftUI’s API surface. That’s a quiet vote of confidence that took Apple a few releases to earn.
The flip side is that custom tile cartography on a watch is still a project that requires commissioning a human cartographer. The platform doesn’t make that easier than it was in 2020 — Smith just decided to do it anyway.
What to take from this if you ship software
The default narrative in our industry is “ship fast, iterate, kill what doesn’t stick”. Smith’s story is the opposite — and it’s worth holding both of those truths at once. The lesson isn’t “spend six years on every feature.” It’s: decide which features deserve craft and which deserve speed, and don’t apologise for getting the calibration right. A calorie tracker probably deserves three weeks. A fitness map for runners — the thing your users will look at literally every time they go out — apparently deserved six years.
The second-order lesson is about defaults. When you decide to bypass a platform’s built-in API (MapKit, in this case), you commit to maintaining a parallel universe forever. Smith judged that worth it for one specific feature in one specific app. That’s defensible — but the next time you’re tempted to ditch the platform’s defaults because of a customisation limit, ask yourself if you’re really willing to spend the six years that decision will eventually cost. Most of the time the honest answer is no.
For us as readers, the takeaway is more concrete: if you’ve been quietly putting off a refactor or rewrite because it feels too long, Smith’s piece is permission to take the time. Long timelines aren’t always a failure mode — sometimes they’re what taste looks like with a deadline removed.
Source: “Six Years Perfecting Maps on watchOS” — david-smith.org. Cover photo by Omar Ramadan on Pexels.