Six Years Perfecting Maps on watchOS

I love going out on adventures into the wilderness. I am rarely happier than when I am far off into the mountains with not a soul in sight. As a result I have spent a lot of time learning how to best safely explore and navigate my way when I’m out 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.

So over the last six years I’ve been working towards creating the best possible mapping experience on the Apple Watch. With yesterday’s launch of Pedometer++ v8, 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.

So I wanted to walk through the journey it took to get here.

Early Efforts

While I have wanted a good map on my wrist since the start of the Apple Watch, it wasn’t really until watchOS 6 that it became realistically possible. This brought the addition of SwiftUI to the platform and for the first time meant that “real” apps were possible. But in those early days the screens were tiny and the processors slow. So I couldn’t quite get to where I wanted.

This was my very first attempt (which 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. These let me validate the idea but realistically weren’t going to be practically useful for navigation or regular use, and could never work offline.

Custom Mapping Engine

So I knew that if I wanted to make meaningful progress towards this goal I’d need to get lower level, so I got to work building a fully SwiftUI native map rendering engine. This had to be written in SwiftUI because that is all that watchOS supported (subsequently this was also really helpful for putting maps in widgets which also only support SwiftUI).

In 2021 I got this engine to a place where I could reliably and performantly render a map on watchOS. This engine allows me to render any tile-based maps and overlay location information over top.

Map Designs

Now that I have the ability to show maps the trouble became how can I best surface this 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, use it to navigate with, but also provide other workout related information to the user. So here began a long series of design attempts, most of which (if I’m being honest) were kinda awful.

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.

This interface allows for 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 which didn’t quite sit right with me about it.

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 which involved swipes. Also, as screens of all the Apple Watches got larger it felt less needed in order to give the map enough space to be useful.

So I set about trying alternative designs. SO many designs.

For a while I really thought that I needed to find a way to put the metrics at the bottom of the screen, but that would lead to other problems as soon as you did longer outings or did workouts that aren’t navigation-focused. So I kept iterating and came up with even more designs.

All of these designs suffered from the same fundamental issue that they required the app to only show a fixed set of fields at once. I could make the interface configurable, but one of the fundamental rules of watchOS design is that you should avoid any interaction which takes more than a few seconds on the watch. Any user configurable setup is inherently fiddly and so I didn’t like this approach.

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 and how we stack elements on top of each other. I was previously using Thunderforest Outdoors as my basemap for the app. I really like 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.

So I commissioned a custom map, working with the incredible cartographer Andy Allen to create a completely new basemap which would look fantastic with Liquid Glass.¹

We simplified the map visually, increased the visual contrast of the elements and made the map elements more saturated to not become a muddy mess when shown below glass.

Having done this I now also had another opportunity, I could finally have a dark mode variant of the map created. This was helpful on iOS, but really shines on watchOS. While I was working with Andy on the design I really pushed on something which would be incredibly legible at arm’s length.

The result of these efforts are that now I have a great map for watchOS…but still was using a design which was good, but not great.

Striving for Great

Nevertheless 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 was able to take Rafa’s concept and turn it into a working prototype. This let me validate the idea in the field. After walking a few hundred miles with it, I was confident it was the correct approach.

So now I needed to do things like dial in on the font and more subtle design choices.

A bit more iteration and I arrived at the design which shipped yesterday. This 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 even though it is now available I have decided to do all this 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.

• MapKit on watchOS always shows in dark mode, which generally is a good default but for some accessibility and user choice reasons isn’t always best. So 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.
• Also, I find that while its coverage is improving with regards to topographic contours and trail marking there are still 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.