I’m delighted to announce that I have brought on Stephen Hackett to help me with my apps. He will be working on customer communication, marketing and generally creating space for me to focus on the programming oriented parts of my work.

Something that’s been rattling around my mind recently is the phrase “Independent as in Freedom, not Independent as in Alone”. For so long I think I have been conflating those two ideas in my head. Which has not been serving me well.

I am extraordinarily proud of being an “indie”, it is a meaningful part of my professional identity. As such I held on too long to a sense of needing to do it all myself. But I’ve grown in this regard and I am extremely excited about what Stephen and I will be able to accomplish together.

My personal definition of being an “indie” has grown and been improved upon. It isn’t about being alone, it’s about the freedom to choose your own path and then walk it in the manner aligned to your own values. That part of the indie life I don’t expect to ever give up, but I can walk that path with others and expect the journey to be all the richer as a result.

Earlier this year I released a major update to Pedometer++ which included a complete visual redesign of the app and brought workout tracking to the iPhone. This update represented a movement towards making Pedometer++ your best companion for outdoor walking adventures.

Today I’m releasing version 5.3 which completes this movement by rounding out some of the missing features from the v5 update. Specifically this update adds Route Planning and Offline Map Management.

I am a very avid hiker. It is my favorite activity and simply put it is my happy place. Because I’ve spent so many hours hiking I’ve developed a number of very strong opinions about what features are important for hiking and how best to build them. These features are built from the perspective of how I plan and track my hikes, developed with the benefit of countless adventures.

Route Planning

While you can continue to import GPX files from external sources into Pedometer++, I wanted to also create a method for planning the routes directly in Pedometer++.

I tend to use GPX files when I am new to an area and want to benefit from other people’s experience. There are numerous hiking trail resources online which publish the best routes in an area and are a valuable way to get familiar with a location.

After walking in an area for a while, however, I find that I typically want to start striking out on my own routes and find new places and hidden gems. There are a number of ways to build a route planner but my favorite method is to boil down a hike into a few key waypoints/viewpoints and then backwards plan a route between them. This is exactly how I’ve built the route planner for Pedometer++.

You simply tap on the locations you want to visit and it will use the Mapbox Directions API to find the shortest route between them. This typically serves as a great starting point for a route. While not necessarily the ‘best’ route, these automatic routes can make it super quick to plan a hike. I’ll often then tweak the automatic route to my tastes based on terrain, access or trail popularity.

Because this planning system is so straightforward and automated it was even possible to add it into the Apple Watch app as well.

I’ve found this super helpful for when I’m actually out on a hike and want to quickly consider an alternative path. Rather than pulling out my iPhone and looking there, I can just tap “Plan a Route” on my wrist, tap a couple of waypoints and very quickly get a distance/route estimate for the possible detour. Then if I like the option I can simply save the new route and use it for the rest of hike, or until the detour is complete.

Offline Maps

Another important feature being added in this update is the ability to more widely download maps for offline use. Rather than just being able to download the map tiles for a particular route you can now download maps for a wide area before you head off on a hike.

This works great for situations where you may be entering an area with limited connectivity. The maps on your iPhone are automatically available on your Apple Watch (as long as your iPhone is within range of your watch).

Ordnance Survey Maps

In the United Kingdom Ordnance Survey maps are the gold standard for outdoor navigation. They provide rich detail for walking routes and rights-of-way. Thankfully they are offered as an API which other apps can make use of and so I’ve been able to include them in this update.

This is also available on your wrist during workouts on your Apple Watch.

Visual Refresh

Lastly I’ve also done a lot of work to improve the visual design of both the iPhone and Apple Watch apps. The old design was feeling a bit “heavy” and cumbersome. I wanted to bring forward a design which felt more modern, clean and intuitive.

On the Apple Watch side of things I had done a partial update this September to bring the app more in line with the watchOS 10 design language. This update completes that work and fully embraces the new layering and visual aesthetic of watchOS.

I hope you enjoy this update, which is available on the App Store now.

The introduction of the second generation Apple Watch brought with it the addition of a new watch face called Modular Ultra. I’m always on the look out for a new digital watch face and this one is very nice, and particularly flexible in terms of layout and look. It also includes a delightful new font showing the time with a variety of alternate heights and widths.

I had the idea for a semi-minimalist layout showing the five things I’m most regularly wanting to see on the face:

• Time
• Day
• Date
• Temperature
• Conditions

I could then put these into the four corners of the watch face and end up with a nice clean look. Here was the initial result:

Not too bad but the font shown in the complications (using Watchsmith), just didn’t fit at all with the new Ultra face showing the time.

I’ve heard that this new font used on the Modular Ultra is referred to as Zenith within Apple so I’ll use that name in this article for clarity. I have no idea if that is actually true but calling it the “New time font used in the Modular Ultra face” would be rather cumbersome, so Zenith will do…both for clarity, and also because that is just a super awesome name.

Zenith has a number of font attributes very similar to San Francisco, but looking at the font it also has a number of tweaks and adjustments which make it not match well when shown on the same watch face. I kinda wish that watchOS would have automatically rendered complications in a matching font (like they do on the other Ultra face, Wayfinder), but they don’t as far as I can tell.

So I set out to see if I could adjust regular San Francisco to match Zenith better. The first step was to create a little test app to be able to quickly compare the font rendering options.

The most obvious problem is that the numerals “6” and “9” have curly tails in regular San Francisco, rather than the straightened ones in Zenith. This I can fix by adjusting one of the optional features in San Francisco. Specifically the rather awkwardly named kStylisticAltOneOnSelector.

This leads to this rendering for the “6” and “9”.

Great, but now let’s look at the “4” numeral. Which is closed on San Francisco, but the top of the “4” in Zenith is open. This can be adjusted by kStylisticAltTwoOnSelector.

So now we have a numeral which look s like this:

Getting close but the width and weight of the font aren’t right. But thankfully variable width rendering was recently added to San Francisco so we can now adjust that too.

Leading to a look which is like this:

To my eye that is very, very close. I’m sure there are more typographically adept folks who could tweak or adjust things to make it even more of a match, but this is good enough for my ability.

The last step was in doing a full numeral test to make sure I wasn’t missing something in one of the other numerals.

That looks great to me. So I then took the font I’ve now made and loaded it up into a private build of Watchsmith, and boom…this is the result:

I love the way this face looks. It feels modern but in a way which is harmonious and friendly to me. And the best part, as opposed to some of my previous explorations into building custom watch faces, this is 100% built using the standard components so runs on my wrist without any workarounds or hacks. Delightful.

Let’s start out this week with a little brain teaser type problem.

How would you calculate the rotation angle for the minute and hour hand of a clock?

Specifically this came to mind for me because of a feature in Widgetsmith where you can specify an analog clock as one of your widgets which looks like this.

I’d encourage you to pause for a moment and actually think how you’d approach this because the result I ended up with was way more complex than I would have initially guessed and it was a good learning exercise to reason through.

The version of this feature which shipped with iOS 17 used the rotation angle calculation I had used since Widgetsmith was first created which is based on a simple method dividing a full rotation of the clock hands by the current hour/minute.

This worked fine in the old version of WidgetKit which only showed one widget at a time, but starting in iOS 17 each progressive widget refresh is now animated between the previous and next value. So now at the end of every hour you get this:

Not great, because I’m only calculating each rotation based on a single rotation around the clock face it jumps from 360° back to 0°.

OK I thought let’s adjust the minute so that it takes into account the hour of the day as well and successfully add in an additional 360° rotation at the start of each hour.

That solves the minute hand jumping around during the day, but now at midnight we have this:

Now at midnight we get a massive backwards rotation because we are again reverting to 0° at the start of each day.

So my next thought is that we need to instead try and make the rotation increase continuously (monotonically for the mathematically inclined). That way the rotation will just keep rolling around and around over time.

This was my first attempt at this type of approach where I pick an arbitrary anchor date and then calculate the number of seconds since that date and then just keep rotating based on the number of hours/minutes it has been since then.

This gets around the midnight reset problem. Though it does mean that I am now providing rotations way outside of the typical 360° range so I wanted to then check if this would eventually overflow and cause issues with the renderer. But trying it with a date far into the future seems to work just fine.

But now the next problem I face is a bit more subtle and relates to the spectre which haunts all programming work which relates to time, daylight savings. Because this approach starts its rotation at midnight on New Year’s Day and then increases linearly from there it will fall apart when the clocks change.

I’m not accounting for the fact that there can be instances where the rotation angle isn’t actually evenly increasing between each date. It needs to either jump forward or backwards when the daylight savings points are met.

My first thought for how to solve this problem would be to determine the starting angle of each day and then use that as the reference point to adjust then based on the previous hour/minute method. This way I’m determining the daily rotation based on the actual hour/minute value (2pm, 4:12am, …) and not just the time since the reference.

This approach however includes a subtle bug. Can you spot it? The issue comes from the fact that the start of each day isn’t actually a multiple of 24 hours from the start of the year…because in March when the clocks change we have a non 24 hour day. 🤦🏻‍♂️

So taking this approach I would get funny rendering bugs after March.

But I think I was on the right path by referencing the start of each day as my baseline for then adjusting a daily rotation. But instead of basing it on the number of seconds from the start of the year I need to instead determine the number of whole days and then multiply that out to get how many full daily rotations have occurred.

This is what I ended up with (code here):

Here I use the number of full rotations of each of the hands per day as the basis for my calculations (2 for the hour hand and 24 for the minute hand).

Then determine the number of whole days have past since my anchor date, and multiply this by the revolutions per day.

Now I have the correct starting point from which I can then determine how far to rotate based on the nominal hour and minute values in the current timezone. Then I’m adding these two values together to get the final rotation.

As far as I can tell this works perfectly. I’m still doing a bit more testing to be sure but here is for example what it does at the two daylight savings points:

The animation actually now involves the correct adjustment being made (either jumping forward or falling behind).

Code like this is always an interesting challenge to get right. Personally I find it very difficult to think through all the possibilities and ensure that I’m accounting for all the correct factors.

I hope this approach is right (if you see a bug in my logic please do let me know!), but either way I’ve learned a bunch for the process of thinking it through which was a great way to start out my week.

Given how young of a platform visionOS is I thought it might be a good idea to err on the side of overly documenting the processing of making Vision Pro apps. There is a whole new set of gotchas and pro-tips to learn.

Also, if I’m being completely honest I really don’t know if I’m doing things the right way so by sharing my learnings (no matter how small), if I’m on a bad path someone else could correct me and we can all learn as a result.

To that end today I’m going to walk through my experience trying to tint a “glassy” component. A relatively small design component but nevertheless useful for understanding the visionOS rendering system better.

The visionOS design language is full of instances where we UI elements are given a frosted glass look, typically with a corresponding specular highlight. These are added to views using the .glassBackgroundEffect() modifier.

This generally looks great as-in, but I ran into something where I wanted to slightly extend the default appearance. My design includes a top ornament on all my widget views which is used to toggle between the expanded and compact views of the widget. It looks like this:

As you can see the topmost ornament does pick up a bit of the color from the underlying view, but the top of it is the standard system flat grey color. I don’t really like the way that looks, it isn’t harmonious with the rest of the view. So I want to add a little bit of tint to the ornament, while still retaining the frosted, semi-transparent look.

UPDATE: Since posting this it was suggested to me that I should instead try using the .tint(color) modifier on the button itself. This works a treat and is probably the better way to go. So use that…though I would still suggest reading through the process I used to find my not quite as good solution. At times like this it is often the journey which is more helpful than the final conclusion. I learned a ton about how visionOS handles layer rendering through this experimentation.

The first step was to create a little isolated test view to work on.

My first thought was to add the tint color as the background of the button.

That retains the specular highlights around the view but looses the frosted glass look. So next let’s try putting the colored view all the way behind the .glassBackgroundEffect too.

That is getting somewhere, now have a blue tint but retain the frosted look. I can tweak the opacity of the background color to make this effect more or less dramatic:

However, this was where I learned an important lesson when working on visionOS rather than iOS. DEPTH MATTERS! By putting this background behind the glassy effect this now has all kinds of knock on effects as you move your head around.

You can see this more clearly if I remove the color from the content view.

There is now a ghostly tinted shadow which will emanate from the button. That is definitely not what I want, but I must confess I was a bit surprised to see this. I have to think carefully about Z-Hierarchy now.

So now my next idea is to instead of putting the color behind the contents, let’s try overlaying a semi-transparent color on top.

This is actually looking pretty nice. One advantage of the overlay approach is that the color is evenly tinting the entire view and so it feels more “part” of the button itself.

The only issue now is that the button symbol is now also being tinted. So I need to now overlay the symbol on top to make it actually white again.

The code to accomplish this looks like this:

And here is what it looks like in a variety of colors (to make sure it wasn’t a color dependent solution).

Alright, the visual appearance of this is looking good, but then I ran into another issue. When you go to “hover” over the button the highlight effect is incredibly weak.

This turned out to be because my call to .hoverEffect() was up towards the top of the view tree with the Button itself, it turns out that .hoverEffect really needs to be put on the top most element you want to gain the effect. So in this case I move it to the last overlaid view.

Much better, now the button correctly responds to the user looking at it.

Here is that first button I referenced at the beginning of the article compared to its appearance with the tint applied.

It is subtle, but I really like the difference. The new button now has a look which is visually harmonious with the content and feels more connected to it.