Six years of refining watchOS Maps

[doggie]

Recommended App

The official Maps app for watchOS delivers the best map experience among all smartwatch platforms.
I never expected third-party map apps to be this thoughtful!

Original (Machine-translated)

Six Years Perfecting Maps on watchOS
Six Years of Refining Maps on watchOS

I love going on wilderness adventures. I am rarely happier than when I am far off into the mountains without a soul in sight. As a result, I have spent a lot of time learning how to safely explore and navigate when I’m away from civilization. The most important habit I’ve found for not getting lost is to be very regular in checking your location as you go, and the best way I’ve found to do that is to have a map on my wrist.
I love heading into the wilderness. Few things make me happier than being deep in the mountains, completely out of sight of other people. Consequently, I’ve invested significant time learning how to safely explore and navigate beyond civilization’s reach. The single most crucial habit I’ve discovered to avoid getting lost is checking your location very frequently as you move—and the best method I’ve found for doing so is having a map right on my wrist.

For more than six years I’ve been working towards creating the best possible mapping experience on the Apple Watch. With yesterday’s launch of Pedometer++ 8, I feel like this design journey has reached a meaningful destination. I would contend that Pedometer++’s watchOS mapping support is the absolute best available on the App Store.
For over six years, I’ve dedicated myself to crafting the finest possible mapping experience for the Apple Watch. With yesterday’s release of Pedometer++ 8, I believe this design journey has finally arrived at a meaningful milestone. I firmly maintain that Pedometer++’s watchOS mapping capabilities represent the absolute best mapping support currently available on the App Store.

So I wanted to walk through the journey it took to get here.
So I’d like to walk you through the path that brought us here.

Early Efforts

I have wanted a good map on my wrist since the Apple Watch launched. This wasn’t realistically possible until watchOS 6, which brought SwiftUI to the platform and, for the first time, made “real” apps possible. But in those early days, the screens were tiny, and the processors slow. I couldn’t quite get to where I wanted.
I’ve wanted a capable map on my wrist ever since the Apple Watch debuted. Yet this wasn’t realistically feasible until watchOS 6—when SwiftUI arrived on the platform and, for the first time, enabled truly functional apps. Still, in those early days, screens were minuscule and processors sluggish. I simply couldn’t quite achieve what I envisioned.

This was my very first attempt that shipped in Pedometer++. These maps were generated completely on the server, which involved sending the relevant workout data roundtrip every time I wanted to refresh the display. This system let me validate the idea, but it was never going to be practically useful for navigation or regular use, and could never work offline.
This was my very first shipped implementation in Pedometer++. These maps were generated entirely server-side, requiring a full round-trip transmission of the relevant workout data each time the display needed refreshing. While this approach validated the core concept, it was never practical for real-time navigation or everyday usage—and it could never function offline.

Custom Mapping Engine

I knew that if I wanted to make progress towards this goal, I’d need to work at a lower level, so I got to work building a fully SwiftUI-native map rendering engine. SwiftUI was the only choice because it’s all that watchOS supported, and proved to be helpful for putting maps into widgets, which also only support SwiftUI.
I realized that to advance toward this goal, I’d need to operate at a lower level—so I set about building a fully SwiftUI-native map rendering engine. SwiftUI was the sole viable option: it’s the only UI framework watchOS supports, and it turned out to be invaluable for embedding maps into widgets, which likewise support SwiftUI exclusively.

In 2021, I got this engine to a place where I could reliably and performantly render a map on watchOS. With it, I can render any tile-based maps and overlay location information on top.
By 2021, I’d refined this engine to reliably and efficiently render maps on watchOS. With it, I can render any tile-based map and overlay precise location data atop it.

Map Designs

Next came the question of how best to surface data to users. App design on watchOS is a really fun — but frustrating — challenge. You are designing for a relatively tiny screen, which must be operated one-handed. In this case, I want the user to be able to read the map and use it to navigate, while also having access to other workout-related information.
Next came the challenge of presenting data most effectively to users. Designing for watchOS is genuinely fun—but also deeply frustrating. You’re designing for an extremely compact screen, operated almost exclusively with one hand. Here, I needed users to both read and interact with the map for navigation and simultaneously access other workout-relevant information.

This began a long series of design attempts, most of which (if I’m being honest) were kinda awful.
This kicked off a long, arduous series of design experiments—most of which (to be perfectly honest) were downright terrible.

In the end, I settled on a “modal” approach where the user can switch between a map screen and a metrics screen using a button on the top-left corner.
Ultimately, I landed on a “modal” approach: users toggle between a dedicated map view and a metrics view using a button in the top-left corner.

This interface provides one context where the user can freely pan/zoom around the map and another where I can use the more standard watchOS tabbed page interface for metrics and controls. I shipped this to Pedometer++, but there was always something that didn’t quite sit right with me about it.
This interface creates two distinct contexts: one optimized for free panning and zooming across the map, and another leveraging watchOS’s familiar tabbed-page layout for metrics and controls. I shipped this version with Pedometer++, yet something about it never quite felt right.

This design felt like a compromise, and not in a good way. I felt that in order to achieve the goal of making the map interactive, I couldn’t have the map be part of any UI structure that involved swipes. As the screens on Apple Watches got larger, it felt less needed in order to give the map enough space to be useful.
This design felt like a compromise—and not a good one. To make the map truly interactive, I concluded the map itself couldn’t be embedded within any swipe-driven UI structure. As Apple Watch screens grew larger, dedicating a whole screen just to ensure usable map space felt increasingly unnecessary.

So I set about trying alternative designs. SO many designs.
So I began experimenting with alternative designs. SO many designs.

For a while, I thought that I needed to find a way to put the metrics at the bottom of the screen. However, that would lead to other problems on longer outings or for workouts that aren’t navigation-focused. So I kept iterating and came up with even more designs.
For a time, I believed the solution lay in placing metrics along the screen’s bottom edge. Yet this introduced new complications during extended outings—or for workouts where navigation isn’t the primary focus. So I kept iterating, generating even more design variations.

All of these designs suffered from the same fundamental issue: they required the app to display only a fixed set of fields at a time.
All these designs shared the same core flaw: they forced the app to show only a rigid, predetermined set of data fields at any given moment.

I could make the interface configurable, but one of the fundamental rules of watchOS design is that you should avoid any interaction that takes more than a few seconds on the watch. Any user-configurable setup is inherently fiddly, so I didn’t like this approach.
I could have made the interface configurable—but one of watchOS design’s fundamental tenets is avoiding interactions requiring more than a few seconds on the watch. Any user-configurable setup is inherently cumbersome, so I rejected this path outright.

Dark Mode, Liquid Glass, & Cartography

Around the same time I was still wrestling with the design challenges of how best to structure the app, Apple announced watchOS 26, and the arrival of Liquid Glass. One of the core design aspects of Liquid Glass is layering stacking elements on top of each other, but another is the types of colors that work best with each other.
Around the same time I was still grappling with how best to architect the app’s UI, Apple unveiled watchOS 26—and with it, Liquid Glass. A core principle of Liquid Glass is stacking layered visual elements—but equally vital is selecting color palettes that harmonize beautifully together.

I was previously using Thunderforest Outdoors as my basemap for the app. I love the content this map includes, but when I started overlaying glassy elements over it I found that it wasn’t well-suited for Liquid Glass.
I’d previously relied on Thunderforest Outdoors as the app’s base map. I adore its rich cartographic detail—but once I began layering translucent “glassy” UI elements atop it, I realized it clashed badly with Liquid Glass’s aesthetic.

So… I commissioned a custom map. Working with the incredible cartographer Andy Allan, we created a completely new basemap that would look fantastic with Liquid Glass.1
So… I commissioned a bespoke map. Collaborating with the exceptional cartographer Andy Allan, we crafted an entirely new base map engineered specifically to shine alongside Liquid Glass.1

We simplified the map visually, increased the contrast of the elements, and made the map elements more saturated to prevent them from becoming a muddy mess when shown below glass.
We streamlined the map’s visual language, boosted element contrast, and heightened saturation—ensuring map features remain crisp and legible beneath translucent glass layers, rather than dissolving into a murky blur.

With this work done, I had another opportunity: I could finally have a dark mode variant of the map tiles. While helpful on iOS, this really shines on watchOS. Andy and I really worked toward something which would be incredibly legible at arm’s length.
With this foundational work complete, a new opportunity emerged: I could now implement a true dark-mode variant for the map tiles. Though beneficial on iOS, dark mode truly excels on watchOS. Andy and I collaborated closely to craft a map that remains exceptionally legible—even at full arm’s length.

The result of these efforts is that now I have a great map for watchOS… but a design that didn’t match that greatness.

Striving for Great

I kept trying. To get me out of my design rut, I enlisted the help of the fantastic designer Rafa Conde. I needed a fresh set of eyes on this and very quickly, this partnership paid off. They proposed a variety of alternative layouts, but when I saw this one I knew it was the one.

The layering of the metrics on the top-left corner, with the map being the top page of a vertical stack, was the correct answer. This design handles interactivity by requiring a tap on the map first to enter “browse mode”.

Tweaking and Polishing

Now that I had the overall concept locked in, the real fun began—actually building the app and dialing in all the details. I fairly quickly took Rafa’s concept and turned it into a working prototype. This let me validate the idea in the field… literally. After walking a few hundred miles with it, I was confident it was the correct approach.

Next, I needed to dial in the font and make more subtle design choices.

After a bit more iteration, I arrived at the design that shipped yesterday. It is legible, useful, and (in my humble opinion) beautiful.

It feels really good to be able to cap off this six-year journey with a design I couldn’t be more proud of. This screen represents so much accumulated effort and learning. It finally gives me a design which feels native on the platform, but also novel and unique.

Here is the evolution of this design over the last six years:

Postscript: Considering MapKit

While my work on watchOS mapping massively predates the arrival of Apple’s MapKit onto the platform, it is probably worth explaining why I decided to do all of this custom work to avoid using it.

Fundamentally, I find that MapKit is great for basic uses, but doesn’t provide nearly the level of configurability and utility which I want Pedometer++ to offer. For example:

• MapKit on watchOS always shows in dark mode, which generally is a good default, but closes the door on some accessibility and user choice reasons. I needed it to be a user-selectable option.
• While MapKit on watchOS has gotten better over time in terms of what you can do with it, I still find it a bit limiting in terms of animations and overlays.
• MapKit’s coverage is improving with regards to topographic contours and trail marking, but there are far too many places where the MapKit map is essentially blank, but I know there should be more rich details available. For example, here is my map vs MapKit at the trailhead of one of my favorite hikes in Scotland.

1. I still find it so cool that my work on this allows me to say that I “commissioned a cartographer” to work on something for me.

---

Copyright © 2026 - David Smith All Rights Reserved.
I use affiliate links when linking to iTunes and Amazon.