Blog

My Home Screen - March 2025
I like to check in on my home screen periodically and see how things evolve. This is my third post containing a home screen, you can see past versions under the homescreen tag.
Main Home Screen
This is my daytime home screen. There are a few changes from last time.

Dock
Mostly my Dock is the same:
- Web browser,
- WhatsApp (the only messaging app that people I talk to actually use, sadly),
- Todoist,
- Obsidian.
But I've got a new browser. I replaced Safari with Vivaldi. There are a few reasons, which I won't go too deeply into (I have another post in the works for that rabbit hole), but to sum it up, I'm trying to avoid giving money or data to big US companies, where I can. And Vivaldi is pretty good, so I've switched over to using it as my browser on all devices.
Widget Changes
- I've removed the Carrot Weather widget, as I found I didn't actually use it much. I would usually go into the app to look at more data, so I've just replaced the widget with the app icon.
- In place of Carrot, I've moved the Albums widget up, as I still love seeing my favourite album covers decorating my home screen. And the top of the screen is harder to reach, so is better for less interactive widgets.
- I've put the calendar widget up there too, although I've stopped paying the large amount of money for Fantastical and moved over to Google Calendar, which is fine as apps go. (I'd prefer to move my calendar to a service and company based in the UK or Europe, but it's a shared family calendar so it's harder to make that switch. Similar problem to WhatsApp, services that involve others are harder to change.)
App Changes
In removing the Carrot widget, I've got a lot more space for apps, so I added another row, then kept one more row free, to avoid visual overload. Notable changes that I've made in the app icons I keep around:
- Music.app replaces Spotify. I'm using a local library, not streaming. I want to avoid giving Apple or Spotify money if I can help it. (I know Spotify is a Swedish company, but they also pay a lot of money to unsavoury podcast hosts.)
- Reeder is still there, but it's actually something I've recently come back to. I used NetNewsWire for a while, but when I set up FreshRSS for hosting, I switched back to Reeder (Classic, as it is now) because the UI is just nicer to me. I don't know how long Reeder Classic will stick around, but it works best for me for now.
- I've put Ivory on my home screen. I have used it for as long as it's been around, but I keep going through cycles of trying to cut back on social media and trying to be more social.
- I have a shortcut to access the Sure Petcare app, because the app icon, in spite of having a white background, doesn't convert to a dark mode icon.
- I've removed the Kindle app. As I've mentioned before, I want to give less money (and data) to US companies. I'm not a heavy reader, and the BorrowBox app for my local library works well enough for my liking. I'm also trying to read more physical books.
- I've also removed Slack from my home screen, as I only use it for work and don't need or want to see it constantly.
Fitness Apps
The extra row of apps on my home screen is dedicated to fitness.
- Apple Fitness is the hub of things. It's how I view my tracked activity from my Apple Watch. I don't really need quick access to it, but it brings it up to a 4th row of fitness apps.
- Awesome Habits is a habit tracker that I use to try to build better habits, like drinking less coffee, eating more fruit and veg, writing in my journal, etc. I've had it for a few years now and keep going back and forward between using the widget (see night mode) and the app icon. (Strictly speaking it's not a fitness app, but I use it mostly to manage my fitness habits.)
- Running Track is my app that I use to analyse my running data and I will definitely probably release to the public at some point some day.
- I really like Headspace's guided meditations. I find they help me to be more present and more relaxed.
- I don't use Fitbod any more, as I didn't have the time for the workouts, so didn't want to renew the subscription. It's still a great app, which I expect to come back to some day.
Night Focus Home Screen

My aim with my evening home screen is to try to make my phone calming, and less distracting. I want to use it less in the evenings, and do things like read or watch TV to wind down. When I do use my phone, I want to make it look less bright and vibrant. I love the new dark app icons and tinted icons for this.
- There are some apps I use a lot in the evenings, and having quick access to them is useful. Those are the ones I've kept around.
- Beyond that, I've tried to go to an all-black screen, to remove as much visual stimulation as I can. And anything I wasn't frequently using in the evenings, I've removed.
- Later in the night, between 10pm and 6am, I've got the app icons and widgets tinted red, to make it even less interesting to look at, and to make sure my interactions with my phone are as intentional as they can be.
- I've kept Running Track here to remind myself that I need to make a dark mode icon for it! It stands out here, in a bad way, and having the visual reminder there will nudge me to actually fix it.
- At some point I've swapped the Awesome Habits and Batteries widgets around, I don't remember why!
- I've stopped using Duolingo, as I felt like I hit my limit of learning French without actually using it in conversation. I do miss seeing the widget go completely unhinged when I reached the end of the day and hadn't completed a lesson.
- I've also stopped using the Todoist widget, because, much like Carrot Weather, I found I mostly wanted to go into the app, and the preview of a list wasn't particularly useful to me.
Watch Faces
Daytime
I try to keep my watch faces as useful as possible. I don't use it for a huge amount of stuff, so anything I do use it for should be accessible from the watch face rather than tapping into the app grid, where possible.
- The main complications here are Activity, Vitals (to help me understand how badly I slept last night...), a glanceable date, the tall Carrot 5-hour forecast, Awesome Habits, Todoist, and to fill out the last slot, Carrot's rain prediction.
- The two other uses I have for my watch are tracking runs, which I start from the action button on the left of my Apple Watch Ultra, and controlling music and podcasts, which happen from the app auto-launching when I start playing something on my phone.
Night

I have the same approach to night mode on my watch as on my phone.
- I want as little content as possible, while still being useful, and as dark as possible. So it's set to night mode, making everything red (therefore dark).
- I remove the Carrot and Vitals complications, and add the Watch's battery percentage so that I can see if I need to charge before bed.
If you liked this article, please consider buying me a coffee to support my writing.
7 March 2025
- homescreen
Hiding the Keyboard Using FocusState in SwiftUI
When you're entering text in a mobile app, it's a common expectation to tap outside of the text field to dismiss the keyboard.
I've been implementing this in a current project using SwiftUI, and was surprised to find it fairly undocumented online, so I thought I'd write up my solution.
There are articles talking about FocusState, which is available from iOS 15. This Hacking With Swift article is a great example. It shows how to use FocusState to dismiss the on-screen keyboard when tapping a button.
But I haven't seen any articles talking about how to dismiss the keyboard using a background tap. And it's a really simple addition to the description in the Hacking With Swift approach.
Just set an onTapGesture on the parent view:
```
@FocusState private var isTextFieldFocused: Bool

VStack { // or whatever your containing view is
    TextField
    ... // configure as normal
    .focused($isTextFieldFocused)
}
.onTapGesture {
    isTextFieldFocused = false
}
```
This almost feels too easy, so if you have any feedback on this approach, please let me know on Mastodon or on Bluesky.

If you liked this article, please consider buying me a coffee to support my writing.
19 February 2025
- swiftui
Timelines and RSS Feeds
There have been a couple of interesting apps in the last few months whose concept I don't really like very much. Tapestry and the new version of Reeder are both apps with great pedigree, and I like the interfaces. But the fundamental design feels like it's solving things backwards.
These apps build a chronological timeline out of RSS feeds. This is something you may be used to from social media apps, especially if you used Twitterrific, or if you still use Ivory, for example.
But a timeline is for things that need to be read in order to make sense. Mastodon and Bluesky are good examples. When I read them, it needs to be chronological, because you see things happening then you see people responding to them. And it's why I hate algorithmic timelines on text-based social networks. Reading things out of context completely ruins it for me.
RSS feeds from websites don’t fit that model though. When I read RSS, I want to be able to browse different categories of feeds (e.g. I subscribe to personal blogs, tech news, F1 news etc.). I don't want to scroll through those longer articles in a feed mixed in with short social networking posts. (I certainly don't want to mix in video and podcasts.) I want to read the posts I've subscribed to based on what's interesting me right now. Some of them (e.g. F1) contain spoilers for things I haven't seen yet. Some of them are longer and I don't have time to read them just now. Sometimes I just feel more in the mood to read about iOS development than sport.
If I were to create a smarter RSS reader, I'd go the other way. Instead of copying the chronological timeline from social media apps, copy the algorithmic timeline. Show me the things that are causing the most buzz. Show me recommended stories based on what I'm subscribed to, because it's a good way of surfacing new sources.

If you liked this article, please consider buying me a coffee to support my writing.
13 February 2025
- opinion
Some Cool Terminal Things I've Found Recently
I had the morning off work today. So I did what anyone would do, and started playing around with my Terminal setup. There are some things that have bugged me for a while, and some things that I've meant to try out for a while, and this seemed like a good chance to play around.
Atuin
I've seen Atuin mentioned a lot recently (yes, named after The Great Atuin - you'll see little easter eggs around the place if you know what to look for, and I love it). So I thought I'd give it a go. I've been a bit slow on this because I initially thought the big selling point was that it syncs your history across machines, but actually it's just an amazing tool for accessing your history.
It combines a visual list of your previous commands with fuzzy search. So you can just press Up, then start typing what you remember from the command (“it’s grep something isn’t it”), and it filters the search.
Watch the video on the homepage, it’s a great demo.
Starship
Starship is a tool for customising your shell prompt. It works with Nerd Fonts to add glyphs, colour, and useful detail to your prompt.
Honestly I just wanted an easy way to make my shell colourful. But I like it.
This preset is where I started from, though I customised it a bit more to remove runtime versions and add hostname (I use ssh a lot and it’s annoying trying to remember which machine I’m on).
I also had to move from Terminal to iTerm 2, because it supports a wider range of colours.

fzf
Searching for files in the terminal is annoying. I can never remember the proper command, and usually end up opening Finder rather than looking it up.
The fzf tool solves that. It’s a fuzzy search tool that makes it really easy to find what you’re looking for, much like Atuin’s history.
grep
Similar to fzf, I’ve been using grep to search the contents of files in a directory. I used to open VS Code quite a lot just to search for which file (especially an Xcode xcodeproj file) contains a certain string. I can do the same with grep:
```
grep -Rin term
```
The -R flag means it’ll search every file and directory in the current one. -i means it’ll ignore case, which I usually find useful. And -n will output the line number of the file where the term is found.
Oh My Zsh and its git plugin
Oh My Zsh is a really useful tool for zsh shells that I’ve been using for a few years, but I’ll include it here anyway. It’s got a great git plugin that lets you use short aliases like gst instead of git status, or grbd instead of git rebase develop. It takes a little checking at first, but it saves so much time once you learn the aliases.
Secure Shellfish
Secure Shellfish is a great iOS app for connecting to a computer via ssh. I often use it to connect to my Mac mini when I’m building this website. So I can use all the above tools on my iPhone or my iPad.

If you liked this article, please consider buying me a coffee to support my writing.
11 February 2025
- terminal
Be Careful Using SwiftUI's buttonStyle Modifier With List swipeActions
SwiftUI has a really useful swipeActions modifier on List rows - see the SwiftUI docs here. It lets you add a swipe gesture to show action buttons on that row. For example, a delete button. (You've seen this in apps like Mail, where you swipe to get actions like Move or Archive/Delete.)
When I was adding it to an app recently, I found a bit of a strange bug. I just couldn't get the swipeActions to work; the gesture did nothing.
I discovered this article about swipeActions on samwize.com and it identified my bug:
If you were to apply any button style (eg. system borderless or custom styles), then the button will NOT show up at all.
The problem is, if you set a button style on a parent view, then it'll apply to all of the buttons within that view. That's usually a great thing about SwiftUI: you can apply a style to all subviews of a view by setting the modifier at a top level view. But for swipeActions to work, you'll have to explicitly use the modifier .buttonStyle(.automatic) on your buttons in swipeActions to set buttonStyle back to the default:
```
.swipeActions {
	Button {
		// some action
	} label: {
		Label("Some Action", systemImage: "some.action.image")
	}
	.buttonStyle(.automatic)
}
```
I think I understand the source of the problem - the buttonStyle has to be .automatic for the buttons to be rendered properly in swipeActions, and if you have some custom style then it could be really awkward to render.
But I strongly disagree with the solution the SwiftUI team have gone with, where the swipeActions modifier has no effect with a custom buttonStyle. Better to make the core action work, and break the styling, than to honour the styling and make the action silently fail.

If you liked this article, please consider buying me a coffee to support my writing.
10 February 2025
- swiftui
Changing My Approach To Journaling
I keep a journal, a diary of my life, and have written in it daily since 2013.
This year I moved away from Day One as my journal app, after over a decade, to writing in a physical book.
Partly because I’m uncomfortable with storing data online, and wondering what happens to it after I’m gone. A physical book has a legacy.
Partly because there’s something nice about writing in a book.
Partly, I don’t like that Day One has platform lock-in on iOS. I can’t use any alternative phone if my journal holds me to iOS.
And partly, I don’t love that Automattic owns Day One. The Wordpress meltdown has made me reconsider what other products of theirs I use.

If you liked this article, please consider buying me a coffee to support my writing.
5 February 2025
- opinion
Quick thoughts on Bluesky, Mastodon and Threads
We’ve now got three replacements for Twitter. I’ve been trying out Bluesky recently, like the rest of the tech world. I’ve been active on Mastodon for a couple of years now. And Threads… exists.
Threads 🧵
I’ll get this one out of the way quickly: Threads feels completely irrelevant to me. I’ve had an account since it launched and barely used it. The app pushes the algorithmic timeline instead of the time-based one and I don’t like that. There’s very little interesting content there, and what is interesting is either federated to Mastodon, or cross-posted. So I don’t bother with Threads.
Mastodon 🐘
I’ve used Mastodon since the idiot with the sink sank Twitter. I like it, but it’s a very tech-focused community, unlike Twitter where I followed silliness, F1, and non-tech friends. I miss having those in my timeline. But I do enjoy the tech community, it’s been genuinely interesting and productive for me in a professional way that Twitter rarely was.
It gets some stick for UX, but I don’t really see that. Just sign up to mastodon.social and don’t overthink servers. It can be hard to find people, but it’s hard to find people on any service. You need to go looking for them. And as for the apps, It’s great that there are so many 3rd party apps, because you can tailor your experience the way you want it. I love Ivory, it’s my ideal social media app.
Bluesky 🦋
Bluesky is interesting. It’s clearly catching the desire to leave X/Twitter in a broader way that Mastodon never did. I guess that’s a combination of it only currently having a single server (even though it’s theoretically decentralised just like Mastodon), and how similar the app is to Twitter. It feels familiar and comfortable to people leaving Twitter. Whereas I never liked the Twitter app and I don’t like the Bluesky app either.
Bluesky has starter packs to find followers, which I think is another helpful feature in moving over. You can easily find a lot of people you followed before. As I touched on above, Mastodon has often had the criticism that discovery is difficult.
And in my experience, it is definitely easier to find people to follow on Bluesky. On Mastodon, I had to follow hashtags for a while, which did work, but doesn’t have that immediate satisfaction of finding a follower list when you sign up, because it relies on people posting over time, and with the hashtags you choose.
However, I also find that a lot of people are following whole starter packs and will have massive feeds, so I don’t know how they’re finding value in that. Lots of content, sure, but that’s not the same as value.
I’ve made as many followers through being in one starter pack as I have done in my whole time on Mastodon. But that’s not all good; the starter pack was for iOS developers. So now I kinda feel like I have to post more about iOS development than I naturally would. On Mastodon I feel completely comfortable posting about whatever I want.
Roundup 🥇
Overall, I like Mastodon best. I have Ivory, the perfect app; I can follow the whole timeline that I’ve curated without any algorithms or weird refresh behaviour; I feel happier posting whatever I want.
But Bluesky is really promising because of how many people are coming on to the platform. It mostly just needs a good 3rd party app.

If you liked this article, please consider buying me a coffee to support my writing.
17 November 2024
- opinion
The Kindle Paperwhite and Nintendo 3DS
I usually love the latest gadgets, but I’ve started keeping two older devices beside my bed, and using them frequently over the last few weeks. My Amazon Kindle Paperwhite from 2015, and my Nintendo 3DS (technically New 3DS XL, but that's a ridiculous mouthful of a name) from 2014. (Yes, 2014-15 is old now...)
I've been reading on my iPhone a lot in the last year or so, mostly due to the necessity of doing things one-handed while dealing with sleeping children. For the same reason, I haven't really played many games other than iPhone games for a few years. Now that I've got that bit more freedom to use both of my hands during my leisure time, I can consider other options.

Reading
The Kindle is a nice way to read a book. My Paperwhite is showing its age, in that it's pretty unresponsive now when I open it up and when I browse my library, so it takes ages to actually let me start reading. But once I do start reading, it's smooth, and it's really relaxing not to have notifications pop up. It's great not to have the draw of "oh I'll just pop out and check RSS/Mastodon". And it's more comfortable to have the bigger screen to read on, so that I'm not constantly turning pages. Overall, it just feels like a better way to read a book than my phone does. Funny, that.
Gaming
I love my Nintendo Switch, but I still find it a bit big to use in bed or to carry around. And the games I want to play on it, like Tears of the Kingdom, are big games that I feel like I want to play on the big TV to fully experience. That’s not an option often enough for me to get into the games properly.
So instead, I've been trying out my 3DS again, and it's a great device for sitting in bed, on the couch, or commuting. It's small, it's portable, and it has some really good games.
Right now, I'm finally playing through The Legend of Zelda: A Link To The Past for the first time, which I bought on the 3DS store years ago. After that, I'm probably going to play through Pokemon Yellow again, which I also bought years ago and have just left sitting on the 3DS that whole time. Pokemon games are great for jumping in and out of on mobile platforms. And I'm browsing eBay and Vinted to find other games that I didn't play at the time (e.g. I never played Super Mario 3D Land or Pokemon Omega Ruby/Alpha Sapphire), and having fun doing it. I'm excited to play games again, thanks to a 10 year old console that was never that big a hit in the first place.

Gadgets don't stop being good just because something new was released. Take another look at what you've got sitting around in drawers, you might find something useful or fun.

If you liked this article, please consider buying me a coffee to support my writing.
5 November 2024
- opinion
Git Reflog To The Rescue
I spent a lot of time hearing people talk about git reflog without actually knowing what it did or how to use it. It sounded advanced, and I didn't understand it well enough to know when it would be useful to me. So hopefully this article helps to explain when it can be useful, and how to use it.
This isn't something that I use often, and when I do use it I refer back to a note which is the basis of this post. So I thought I'd share it in the hope that it helps others in the same scenario.
tl;dr
Use git reflog to restore dropped commits. When you type git reflog in a terminal, you'll see a list of entries like this:
```
735e24f41 HEAD@{5}: commit: My clever commit message
```
Get the hash of the commit that you want to restore (it's the first column), then cherry-pick that commit:
```
git cherry-pick 735e24f41
```
And there you go, your commit is back.
One Particular Example Where I Use git reflog
This is a very specific example, due to using git rebase and squashing a merged PR into one commit in GitHub.
When I work with git, I use rebasing to keep branches in sync. The reasons why are a separate article, but suffice it to say, I broadly prefer rebasing over merging.
Here's a common scenario that I encounter: we have the main branch as the source of truth for our team's project. It's got root-commit as its latest commit. Then I create a feature branch, search-1, for the first part of the new search feature that I'm working on. Then, before my PR for search-1 gets merged, I have some more work to do, and I branch from search-1 to search-2.
```
-> main
   - root-commit
   -> search-1
      - c1
      - c2
      - c3
      -> search-2
         - c4
```
If you've spent much time in bigger teams, with multiple developers on one git repo and a bit of a queue to get PRs merged, this is probably quite familiar.
When I merge search-1, all of the commits in that branch get squashed down to one single merge commit. (Again, that's what I like, the merits of this approach are another article.)
```
-> main
   - root-commit
   - squashed-merge-commit-from-search-1
   -> search-2
      - c1 (originally in merged branch)
      - c2 (originally in merged branch)
      - c3 (originally in merged branch)
      - c4 (new to this branch)
```
So search-2 is out of sync. It still has the whole history of search-1, as well as its own commits.
When I rebase search-2 on top of main, I want to drop c1, c2 and c3, since they're part of main now, through the merge commit. So I drop them, in an interactive rebase.
And here's where we get to the point!
Sometimes, I mess up, and drop the wrong commits. It's not always as simple as this contrived example, messages aren't always clear. And you don't always have a list of which commits were in search-1 and which are new to search-2.
I just had this happen to me where I had a few commits in search-2, and dropped too many because I didn't know where the line was between search-1 and search-2, and had to look up how to use git reflog to save myself, yet again.
Restoring A Dropped Commit
So this is the whole point behind this article. I hope the example above was clear to follow, but even if not, it doesn't matter. What matters is:
If you had previously had a commit, and you've somehow deleted that commit, chances are you can still get it back!
git reflog will show you the history of the actions you've taken. Things like commits, checkouts, pulls and pushes, resets, all sorts of actions. Not just commits, like you'd find in git log.
So to restore a commit that I didn't mean to drop, I'd look for this line in the git reflog output:
```
735e24f35 HEAD@{5}: commit: My clever commit message
```
That's the commit that I want to restore. So I just cherry pick that out of the ether:
```
git cherry-pick 735e24f35
```
And then I get my commit back!
Aside
It took me an embarrassingly long time to realise it was "ref log", not "re flog". I'm not sure what I thought was being flogged again.
Reference
There's a great article on the GitHub blog: "How to undo (almost) anything with Git".

If you liked this article, please consider buying me a coffee to support my writing.
25 October 2024
- git

Previews in Xcode Playgrounds

In a project I'm currently working on, our SwiftUI Previews are broken. But rather than running the app every time I want to work on developing a view, I've been doing initial development in Xcode Playgrounds, which can also run previews.

It's really easy to set up:

import PlaygroundSupport
import SwiftUI

struct MyView: View {
    // your view here
}

let view = MyView()
PlaygroundPage.current.setLiveView(view)

For example, I want to experiment with different Toggle styles in SwiftUI. I've copied these examples from Apple's documentation for Toggle and ToggleStyle, and I can then see how they look, and tweak different properties. And it's interactive, so when I interact with one of my Toggles, it changes the state.

A screenshot showing Xcode Playgrounds running a live SwiftUI Preview.

Here's my code for the Toggles (again, all taken from Apple's documentation):

import PlaygroundSupport
import SwiftUI

struct Toggles: View {
    @State private var vibrateOnRing = false

    var body: some View {
        VStack(spacing: 16) {
            Toggle("Vibrate on Ring", isOn: $vibrateOnRing)

            Toggle(
                "Vibrate on Ring",
                systemImage: "dot.radiowaves.left.and.right",
                isOn: $vibrateOnRing
            )

            Toggle("Vibrate on Ring", isOn: $vibrateOnRing)
            .toggleStyle(.button)

            Toggle(isOn: $vibrateOnRing) {
                Text("Vibrate on Ring")
                Text("Enable vibration when the phone rings")
            }
            .toggleStyle(.switch)

            Toggle(isOn: $vibrateOnRing) {
                Text("Vibrate on Ring")
                Text("Enable vibration when the phone rings")
            }
            .toggleStyle(ChecklistToggleStyle())
        }
        .padding()
    }
}

struct ChecklistToggleStyle: ToggleStyle {
    func makeBody(configuration: Configuration) -> some View {
        Button {
            configuration.isOn.toggle()
        } label: {
            HStack {
                Image(systemName: configuration.isOn
                        ? "checkmark.circle.fill"
                        : "circle")
                .tint(.green)
                configuration.label
            }
        }
        .tint(.primary)
        .buttonStyle(.borderless)
    }
}

let view = Toggles()
PlaygroundPage.current.setLiveView(view)

If you liked this article, please consider buying me a coffee to support my writing.

18 September 2024

SwiftUI ButtonStyle

A while ago, I created a button in SwiftUI. It's a simple button, but I want to be able to use this design in lots of places in my app. It has the app's theme colours, it has a particular font, it has a pill-shaped rounded appearance.

I initially created this as a View, wrapping a Button with some customisations.

struct PurpleButton: View {
    let buttonTitle: String
    let action: () -> Void

    var body: some View {
        Button(buttonTitle, action: action)
            .frame(maxWidth: .infinity)
            .padding(EdgeInsets(top: 16, leading: 32, bottom: 16, trailing: 32))
            .font(.system(.title3, design: .rounded))
            .foregroundStyle(Color(.darkBackgroundText))
            .background(Color(.primary))
            .clipShape(Capsule())
    }
}

This gives me a PurpleButtonView, whose sole contents are a Button, styled how I want. But SwiftUI has a better way.

By using a ButtonStyle, you can customise a Button's appearance without wrapping it, avoiding creating that extra view in the view hierarchy.

struct PurpleButtonStyle: ButtonStyle {
    func makeBody(configuration: Configuration) -> some View {
        configuration.label
            .frame(maxWidth: .infinity)
            .padding(EdgeInsets(top: 16, leading: 32, bottom: 16, trailing: 32))
            .font(.system(.title3, design: .rounded))
            .foregroundStyle(Color(.darkBackgroundText))
            .background(Color(.primary))
            .clipShape(Capsule())
    }
}

You can then create a Button in the normal, simple way, and apply the style.

#Preview {
    Button("Press Me") { print("Button pressed") }
        .buttonStyle(PurpleButtonStyle())
}

You can clean this up a bit by creating an extension on ButtonStyle to define a static variable.

extension ButtonStyle where Self == PurpleButtonStyle {
    static var purpleButton: Self {
        PurpleButtonStyle()
    }
}

#Preview {
    Button("Press Me") { print("Button pressed") }
        .buttonStyle(.purpleButton)
}

The extension works really well if you have a standard style but want to provide different customisations.

extension ButtonStyle where Self == PurpleButtonStyle {
    static var purpleButton: Self {
        PurpleButtonStyle(.standard)
    }

    static var secondaryPurpleButton: Self {
        PurpleButtonStyle(.secondary)
    }

    static var cancelPurpleButton: Self {
        PurpleButtonStyle(.cancel)
    }
}

This pattern appears throughout SwiftUI. Styles are a great way to customise a component's appearance, often quite heavily, without having to wrap or try to subclass a core component.

Resources

That's quite a simple example for one button style. Here are some resources I found useful when learning about ButtonStyle:

Apple documentation on View styles
Apple documentation on ButtonStyle
Hacking With Swift
Use Your Loaf

If you liked this article, please consider buying me a coffee to support my writing.

6 September 2024

Hiding A SwiftUI View From Switch Control
I'm currently working on a project to enhance the accessibility of an app, and I'm learning a lot about how far iOS's accessibility support goes beyond a screen reader. There's a really cool technology called Switch Control that enables users to control their iPhones using an external tool, like a button, a game controller, or even a straw.
I ran into a problem with supporting Switch Control when I was building a custom View component in SwiftUI. The component is essentially a label, and shouldn't be visible to Switch Control. But it wasn't easy to find out how to hide it. Switch Control is such a vague term that I got a lot of results for custom control components called switches, and some results about using a Nintendo Switch controller too.
The solution to my problem was quite easy, once I found it. A one-line SwiftUI modifier:
```
.accessibilityRespondsToUserInteraction(false)
```
Here is the relevant part of the docs from Apple:
Explicitly set whether this Accessibility element responds to user interaction and would thus be interacted with by technologies such as Switch Control, Voice Control or Full Keyboard Access.
Find out more about Switch Control
Switch Control is a really cool technology, but not widely known or talked about. Here are some interesting articles from people using it, if you want to find out more:
- App accessibility for Switch Control from WWDC 2020.
- I Used a Switch Control for a Day.
- Switch Control Changed My World.
  
  If you liked this article, please consider buying me a coffee to support my writing.
4 September 2024
- accessibility
- swiftui
Comparing Reminders and Todoist
I was a Todoist user for the best part of the last decade. I've tracked all sorts in my to-do list there, from work tasks, to household chores, to planning my wedding. It had a great Alexa integration, and I used it extensively with my wife, to manage shared tasks and our shopping list.
Then Amazon killed the Alexa lists API and the Todoist integration ended. Our shared tasks ended up in the (absolutely awful) Alexa app, and I figured this was a great time to try out Apple's default Reminders app. It's got a lot of great features in the last few years, and is so much closer to Todoist in so many ways.
I went all-in, fully deleting a load of lists and filters in Todoist and re-creating them in Reminders. I lost a streak of completing tasks that stretched back to 2019. (I think streaks are a silly way to manage a to-do list, but I also understand that they work, because I would often check it just to feel good about my productivity, and I felt disappointed to lose the streak!)
I used Reminders for around a month, and mostly enjoyed it. It does pretty much everything I want: it has smart lists, it has repeating tasks, and honestly I quite like how it looks, with colourful titles, icons for lists, and links in task metadata. Best of all, it's free as part of the various OSes that I use.
But I also found myself playing with the EventKit API to address some shortcomings, like the fact the Apple Watch complication is just a static app icon, and the widget doesn't give any sense of progress through the day.
Over the last month or so, I also realised that my wife and I had used Todoist to plan family and household projects, and this is missing with Reminders as Reminders doesn't go beyond Apple's devices, and she uses Android.
So I moved everything back over. I really liked Reminders, but not being able to work with anyone, regardless of their phone's OS, is too much of a limitation for me. And I'm increasingly feeling that while iOS and macOS are my favourite computing platforms, I resent being tied to them by core apps and services, if I did want to move to Android.
Reminders is a great app though, and it's incredible how much you can do with it as a free service that comes with your phone.

If you liked this article, please consider buying me a coffee to support my writing.
2 September 2024
- opinion
15 Years Since Snow Leopard
Nostalgia time. It's 15 years since Apple released Mac OS X 10.6, aka Snow Leopard.
I just changed my desktop wallpaper to the old default Snow Leopard space wallpaper that Basic Apple Guy released the other day, and it's a great bit of nostalgia for a great time in computing. It makes me smile when I look at it.
My first version of OS X was technically Leopard. Mac OS X 10.5, back when I remembered all the version numbers and big cat code names.
I only used Leopard for a few weeks though, because I bought my first MacBook Pro just before Snow Leopard (Mac OS X 10.6) came out. I even got the update disc for free, because I bought my Mac after the OS update was announced, but before it shipped.
I loved my Mac and I loved Mac OS X straight away. It was such a breath of fresh air after fighting for years with getting flimsy Windows computers to do what I wanted. Snow Leopard was my OS for my first few years of owning a Mac and it was a great experience.
So much has changed since 2009. What’s now called macOS is shipped for free, as a download, not a paid disc. It’s gone from a release every 2 or 3 years to an annual cycle. Intel Macs have gone from the amazing new hotness to just the worst Macs you could be unfortunate enough to have to use. And I couldn’t tell you which random place name in California we’re on to as a version name now. (The big cats were more memorable to me, and the annual release cycle, combined with an unfamiliarity with California, has made it impossible for me to keep up, particularly when macOS versions don’t seem to have any major distinguishing features.)
But macOS is still my favourite OS, and it started with Snow Leopard.

If you liked this article, please consider buying me a coffee to support my writing.
30 August 2024
- opinion
How to run tests repeatedly in Xcode
Sometimes, unit tests don't give you the same result each time. The reasons why are beyond the scope of this quick tip, but the impact they have on developer time is immense.
Flaky tests can cause you to waste time having to re-run CI jobs. I've seen this a lot, and it costs both time and money. It delays your merges, and if you're not merging code you're not shipping features. Flaky tests also mess with the sense of security that you're meant to get from automated tests. They're meant to give you confidence that your code is behaving properly. If your tests give unreliable results, then is that a problem with the code or the test? It then costs more time to solve the problem and fix the flaky test.
Once you think you've got a solution to fix your unreliable test, how do you prove it fixes the problem and gets rid of the flakiness? Xcode has a handy tool which lets you re-run tests repeatedly: - Right-click on the test diamond beside the test name. - Select Run "testName" repeatedly.... - Choose your maximum repetitions, configure some other properties, and off you go.

I like to run tests 1000 times to prove the fix for an unreliable test. Unit tests should run quite quickly, so this isn't time-consuming. And it's easy for randomness to slip through at any amount of tests, but 1000 feels like a good amount to give me confidence in my fix.

If you liked this article, please consider buying me a coffee to support my writing.
23 August 2024
Quickly move between changes in a file in Xcode with this keyboard shortcut
One of my favourite keyboard shortcuts in Xcode: CTRL-\ lets you move quickly to the next change in a file, tracking git changes.
So if you’ve edited a few places in a large file, rather than having to scroll down manually to find the next place you edited, you can use CTRL-\ (the Control key and backslash key) to jump to the next change.

If you liked this article, please consider buying me a coffee to support my writing.
20 August 2024
- xcode
- tip
An Introduction to Swift Testing
Swift Testing is the new framework for unit testing in Swift. It is shipped as the default in Xcode 16 (now in beta), and it looks great.
Watch the session video from WWDC 2024 for the official intro from Apple.
Swift Testing is an open source framework hosted on GitHub. You can read much more about it in the main project, and also in the Vision Document.
The @Test Attribute
There are four main building blocks in Swift Testing, and the first is the @Test attribute. In XCTest you needed a test prefix on your method name to tell the framework that this method is a test. The @Test attribute does that now, so your test function can have any name.
A test can also now be global. In XCTest, tests had to belong to a subclass of XCTestCase. (Talking of which, we'll get to test suites soon.)
```
import Testing

@Test func myGlobalFunction() { // function name doesn't start with `test`
    #expect(true) // we'll get to this next
}
```
Expectations
The second building block is Expectations. These are equivalent to assertions in XCTest, but while XCTest has lots of different assertions (XCTAssert, XCTAssertTrue, XCTAssertEqual, XCTAssertNotNil etc.), but Swift Testing has just two: #expect and #require.
The #expect macro lets you specify any condition, using the standard Swift language features. If the condition evaluates to true, the test passes.
The #require macro also validates a condition, but in this case, if the condition evaluates as false, the test will terminate immediately. #require also throws an exception, so you need to call it with try.
One tool of XCTest that I use a lot is XCTUnwrap, to safely unwrap an optional, and fail the test if the optional can't be unwrapped. You can use #require the same way:
```
let unwrappedValue = try #require(myOptionalValue)
```
If the test fails, then not only will it fail, it will also generate an error message using the evaluated expression, to help you see why it failed. This is a huge difference from having to generate failure messages manually in XCTest.
Traits
The third building block of Swift Testing is Traits. Traits let you add details to a test, for example a display name, a bug ticket reference, or a condition under which the test should run (e.g. only in a certain language, or only when a certain feature flag is enabled).
This example shows enabling a test only when a feature is enabled. (It's taken directly from the Swift Testing README.)
```
@Test(.enabled(if: AppFeatures.isCommentingEnabled))
func videoCommenting() async throws {
    let video = try #require(await videoLibrary.video(named: "A Beach"))
    #expect(video.comments.contains("So picturesque!"))
}
```
Tags
You can also use Traits to organise tests into tags, and you can group tests by tag rather than suite or file in the Xcode sidebar. I love this idea for small projects that have a limited number of people working on them. I know it’ll be misused in bigger teams, with lots of different tags being semantically the same.
Parameterised Tests
It can be common to run one test multiple times, changing the parameters to test different conditions. Traits let you simplify that logic, by defining your arguments outside of the test. You can then see the different test runs in the sidebar in Xcode, and even re-run specific arguments, while only having one test defined.
Here's an example, again taken from the Swift Testing README:
```
@Test("Continents mentioned in videos", arguments: [
    "A Beach",
    "By the Lake",
    "Camping in the Woods"
])
func mentionedContinents(videoName: String) async throws {
    let videoLibrary = try await VideoLibrary()
    let video = try #require(await videoLibrary.video(named: videoName))
    #expect(video.mentionedContinents.count <= 3)
}
```
This runs the test against three different videoName values: "A Beach", "By the Lake" and "Camping in the Woods". You'll see each of these in the sidebar as different tests, but you only need to write one @Test function.
Test Suites
Test Suites still exist, and they’re the fourth building block of Swift Testing. Instead of a subclass of XCTestCase, you can keep it really simple and embed your tests in a struct. That alone creates a Suite, implicitly.
```
struct MyTests {
    @Test func myTest() {
        #expect(true)
    }
}
```
MyTests in the example above is a Test Suite. This is inferred from the presence of a @Test.
You can also use the @Suite annotation. One reason why you might do that explicitly is to apply Traits that should be inherited by all tests. For example, if you apply a Tag to a Suite, that Tag applies to all tests in the Suite.
Suites can be a struct, actor or class, but struct is encouraged. This means you get the benefit of value semantics; each test will get its own instance of the Suite. That means you don't risk sharing data between tests and corrupting the tests.
One reason you may use choose to use a class or actor, however, is if you need a deinit method. In XCTest, you had setUp and tearDown, and multiple examples of each, depending on whether you wanted it to be run on a class or instance level, or if it should be async. There's only one init and deinit in Swift Testing, and deinit isn't available in structs.
Wrap Up
XCTest isn't going anywhere any time soon. You can take any migration slowly, and use both XCTest and Swift Testing in the same test target. And Apple explicitly mentions that XCTest is still required for performance and UI testing.
But Swift Testing looks like a great improvement on unit testing, and I'm excited to try it out.

If you liked this article, please consider buying me a coffee to support my writing.
11 June 2024
Favicon
Fun little fact about the favicon on both neilmacy.co.uk and runningtrack.app.
This was the logo for my old company, Multicoloured Software, which I closed around 2016-17. The naming of the company and the choice of the icon are lost in the mists of my memory. But when I came to create this site, I wanted something distinct, and I put this in as a placeholder while I made that distinct thing.
5+ years later and that placeholder is still here!

If you liked this article, please consider buying me a coffee to support my writing.
10 June 2024
- meta
Getting Up Early
I just came across a couple of posts by Johnny Decimal and Chris McLeod about getting up early. Properly early: 5am. I've just started doing the same thing - completely coincidentally, all three of us get up at 5am - and it amazed me that other people are as ridiculous as me.
But here's the thing: it works really well.
I start work when I get up, and I get a solid 2 hours in before the rest of my family is up and about. And not all time is created equal; those 2 hours are the most productive of my whole day, by far. There's something about getting up early that fires my brain up.
I used to catch up on work after my kids went to bed, at the end of the day. And this was terrible for two reasons: I always felt like I was catching up, and if I work for 2 hours at the end of the day, I produce absolute mush.
Now, I work when my brain works best, and I get to feel like I'm ahead of things too, which gives me an extra boost through the day.
I always thought morning people were weird, but it turns out I am one.

If you liked this article, please consider buying me a coffee to support my writing.
10 June 2024
- opinion
Running Track is on TestFlight!
My new iOS app, Running Track, is now available as a beta via TestFlight. If you’re a current or aspiring runner, try it out and let me know what you think!
Download now!
What Is It?
Running Track lets you view your running data from Apple Health. It has stats, Personal Bests, and you can set goals for yourself too.
You can view your running data for free, and hopefully it’s a nice way to look back on your workouts and track your progress as a runner. Personally, I much prefer it to Apple Fitness, where I would otherwise view my Apple Watch runs.
And if you want to push yourself, set yourself a goal. I set myself an annual challenge of running 100 miles this year. You can also aim to go further in one run than you ever have, using a single-distance goal.
FAQ
- Do I need to use this to track my runs? Nope, this is just loading your runs from Apple Health. So long as your run tracking app saves your runs to Apple Health, you can load them in Running Track.
- Do I have to pay for in-app purchases? Not in TestFlight. In-App Purchase is free on TestFlight (for any app). Go ahead and try everything out.
- How can I give you feedback? I’m on Mastodon, or you can email me: running @ this domain.
  
  If you liked this article, please consider buying me a coffee to support my writing.
7 June 2024
- runningtrack
How I prepare for WWDC
WWDC is an annual, week-long event, which delivers lots of new API for developers to build on. There's a huge amount of content from that week, so it can be hard to keep up. Here's how I approach it.
You Can't Do It All
I never try to get through every session. To narrow things down, I identify two categories of session:
1. Useful to my work.
2. Most interesting to me. (I sometimes have to be harsh with this one!)
This usually helps me bring it down to around 1/3 of the sessions. I focus on what I need to learn, and what I'm most excited to discover, while accepting that there will be new things that I'll have to park for a later date. For example, this year I don't expect to watch VisionOS sessions.
The Apple Developer app is a great way to keep track of what you want to watch. I go through sessions and bookmark them in the app, then I can filter out the extra sessions that I don't plan to watch just now.
Remember You May Not Be Able To Use This For A While
It's unusual for most developers to get to support the latest OS as soon as it ships. You'll have customers who take time to upgrade. So there's a good chance you'll have to wait a year or two, depending on your scale and your user demographic, before you can use the new code. This is a great way to help yourself focus on what matters to you now.
Set Aside Dedicated Time
It's easy to try to squeeze in watching session videos around work, but often, meetings, work deadlines, and other pesky distractions will get in the way. If you work for yourself, schedule time in your calendar to watch sessions and try out new code. If you work for a company, ask for personal development time to follow along, and again, dedicate time in your calendar for it.
Write Code
Get stuck in! Even if you are just copying sample code, it's fun to get to try the new capabilities of your platform.
Make a demo app to try things out, and you might even end up with something you want to ship.
Share Your Excitement
If you see new API you like the look of it, talk about it! Share it on social media, write a blog post, do a presentation in work to tell your colleagues.

If you liked this article, please consider buying me a coffee to support my writing.
27 May 2024
- wwdc
Some DIY Tips
I recently became a homeowner for the first time. So for the last few months since we moved in to our new home, I’ve been doing lots of things like putting up shelves, mounting TVs on the wall, even installing a doorbell.
I’ve learned a few things in that time. (A euphemism for “I’ve made a lot of mistakes in that time”.)
- Always measure. Then measure again. And again. Seriously.
- Never use the wall plug that comes with the furniture.
- Always use a drill bit one size smaller than you think. You can always make the hole bigger; never smaller.
- Check if your door is hollow before trying to install hooks on it. (The internal doors in my recently-built house seem to be made mostly from heavy duty cardboard…)
- Measure again.
  
  If you liked this article, please consider buying me a coffee to support my writing.
2 May 2024
- diy
Living (Comfortably) In Apple’s Walled Garden
I've used an iPhone as my personal phone since 2009, but I've used Android alongside that, off and on, for most of time. I bought my first Android phone in 2010 (an HTC Hero that I flashed Android 2.3 Gingerbread onto because it was limited to Android 2.2 Froyo). I wrote my first Android code around the same time, just a year after I first opened Xcode. And I spent 4 years as a full-time Android developer, before I worked on iOS professionally.
But I've never fully made the switch to Android on my main phone. Periodically, I set up an Android phone for that purpose, and always last just a day or two of using it full time before I go back to my iPhone.
This isn’t a criticism of Android. It’s just my own reflections of what I like about the two platforms, and why I prefer iOS.
There are a few things keeping me on iOS. There are some apps that either aren't available on Android, or just aren't as good. There are some hardware reasons. And honestly, there's some data lock-in too.
I feel like I can't switch to Android because there are some things I can't bring with me. But I'm also perfectly content with that.
Apps
- Day One: my diary, and it's only on Apple platforms. I have a decade of history that I can't recover if I move to Android. That on its own is enough to ensure I will always want an iOS device around.
- Ivory: a brilliant Mastodon app, beautiful and powerful. I've used so many in the last year or so, on Android and iOS, and none work for me like this does.
- Awesome Habits: a habit tracking app, which I use for little things like reminding me to write in my diary and practice French.
- Working Copy: a git client, surely Android actually has better support than iOS for this?
- Textastic: surely Android has a good text editor with some basic syntax highlighting?
- Dark Noise: an app for playing white noise sounds to help me concentrate when I work.
- Noir: automatic dark mode on the web, even when sites don't support it.
- Reeder: a fantastic RSS reader.
- Mela: a recipe app. It's beautiful, and the recipe import is really clever.
- Carrot Weather: beautiful and clever weather app, which has great widget and Apple Watch support, and is incredibly customisable, so I can see exactly what I care about and ignore the rest.
- GoodLinks: this is just a dumping ground for links I want to save, so there must be something useful like this on Android.
There's also a strong indie app scene on iOS that I've just not found on Android. There are all sorts of great iOS apps like Working Copy, Crouton, FoodNoms, Awesome Habits, Dark Noise, Darkroom, Halide, Carrot Weather, which are made by small or one-person teams on iOS, and I can't find the same standard of apps on the Play Store. Please, prove me wrong, and give me all your indie Android app recommendations!
Locked the Garden Gate
Beyond just the apps and their capabilities, another reason I stick with iOS is the ecosystem around it.
- iCloud sync: another issue with many of the apps I listed above is that they use iCloud or Apple Health for their cloud sync, which obviously doesn't translate to Android. But their sync works well (unlike some cross-platform sync, in apps like Obsidian for example).
- Fitness tracking with Apple Health: I have a long history of running data, well over a decade now, and I don't want to (or even think I can) migrate all of my data to Google.
- Apple Watch: this is a huge reason. I've used other watches - Android Wear devices (I got the first models that were handed out at Google I/O 2014, and my Android-using wife has had others in the years since), Garmin running watches too. But I love the Apple Watch, whereas I barely liked the others. The hardware, the software, the way it integrates with my phone, the wrist straps I have for it. Honestly, if I can get an Apple Watch to work nicely with an Android phone, then that's a huge part of the garden wall knocked down.
If you liked this article, please consider buying me a coffee to support my writing.
1 May 2024
- opinion
Formatting Years as Strings
In date formatting, yyyy is not the same as YYYY.
Apple’s Date Formatting document describes this:
A common mistake is to use YYYY. yyyy specifies the calendar year whereas YYYY specifies the year (of “Week of Year”), used in the ISO year-week calendar. In most cases, yyyy and YYYY yield the same number, however they may be different. Typically you should use the calendar year.
You can test Swift’s DateFormatter with 2016-01-01: YYYY will tell you it’s 2015, not 2016, because it’s a Friday, at the end of 2015 by the year-week calendar logic.
If you’re working with date formatters, it’s a good idea to include 2016-01-01 in your unit tests, just to make sure you format the date as you expect.

If you liked this article, please consider buying me a coffee to support my writing.
27 April 2024
- swift
Git Rebase
I really like this description of git rebase, from this Atlassian tutorial.
rebasing is changing the base of your branch from one commit to another making it appear as if you’d created your branch from a different commit.
Rebasing is something I use on a regular basis, and I find it really useful. Much better than merging main into my branch to keep it up to date. But it’s not a commonly-used feature of git, in my experience, and that’s usually because people think it’s more complicated than merging.
This quote above describes why I think it’s conceptually really simple.

If you liked this article, please consider buying me a coffee to support my writing.
17 April 2024
- git
My Home Screen - January 2024
I’ve written before about my home screens. Find all articles at the homescreen tag. (At the time of writing there’s only one other article there, but I intend to update it now and again, as I fiddle with it constantly.)
Main Home Screen
This is my default Home Screen. I also have one that I use at night time; I’ll come on to that in a bit.

There are some visible differences from last time. For example, I’ve moved Obsidian and Todoist into the Dock, reflecting how I actually use my phone most often.
Widget Changes
- I’ve replaced the Awesome Habits widget with a bigger Carrot Weather one, because I get more value from that through the day. (Awesome Habits is still useful at night though, see later.)
- I’ve replaced the Kindle widget with Albums, because I like the album covers being the full size of the widget, and I listen to a lot more music than I read books right now.
App Changes
- GoodLinks is an app I’ve used for a while, but I’m consolidating all my Read Later usage into it rather than using Safari Reading List.
- Kindle is now an app icon because, although I don’t have space for the uninspiring widget, I still need encouragement to read more.
- I’m trying Fitbod because I need to be more active. I like the app, but I need to know I can actually fit using it into my life enough to commit to the high subscription price.
- Google Photos and Duolingo are still used, but are Night Focus apps now.
- Huckleberry is much less useful now that my children have gone past the point where we need to track their sleep.
General Usage
I still use only one Home Screen, and then a combination of Spotlight search and the App Library for finding everything else. I find the suggestions in the App Library pretty decent, and search works way better for me than browsing deep through screens or folders.
I tried again with Focus Modes and I like the setup I have now. Work mode, which I won’t share here, has my work calendar and work apps on the Home Screen, letting me get quicker access to apps that I use during work times.
Night focus lets me change my phone to reflect how I use it at night time, once my kids are asleep. Or when I’m sitting up with the younger one when he won’t go into his cot…
Night Focus Home Screen

The Fantastical widget is replaced by Todoist, to let me glance at what I still have to do this evening.
Night Focus is where Duolingo and Awesome Habits come back as widgets. I need the big visible reminders for the various habits I’m tracking, including learning French. But being realistic, I can only use them in the evening.
Similarly, Mail and GoodLinks aren’t as useful as Fitbod, which I can use much more easily in the evening, or Disney+, which I watch a lot of at 3am.

If you liked this article, please consider buying me a coffee to support my writing.
2 January 2024
- homescreen
Reviewing My 2023 Challenges
At the start of the year, I wrote my personal challenges for 2023. So obviously I’ll review them now, at the end of the year.
My challenges for 2023
- 📚 Read 20 books.
  - ❌ Nope. I’ve read 7. It’s been an abysmal year for reading.
- 🎧 Listen to at least 1 album every month.
  - ✅ This was intended to be unique albums. I listened to a lot at the of the year, hit my target, then mostly went back to ones I’d already listened to. But it’s achieved its goal, because I’m listening to lots more albums now, and fewer playlists.
- 🏃 Run at least 1 time every month.
  - ❌ I expected this to be loaded towards the latter half of the year. But it was actually evenly spread. And abysmal, again. 3 runs all year.
My daily challenges
- 🇫🇷 Practice French every day.
  - ✅ I really love doing this, and Duolingo is a great app too.
- 📓 Write in my diary every day.
  - ✅ Much like practicing French, I love doing this. Day One is great for showing you previous years’ entries too, which adds a lot to the experience. I do have a new-found draw towards paper journals, because I worry about its longevity otherwise. And I don’t like the platform lock-in from Day One being Apple-only. But the convenience of always having my journal available on my phone means it’s easy to write, and that’s meant I can keep this trend up. And I really value that.
- ✍️ Write something every day. (This can be a blog post on this site, or some progress towards the novel or the short story I'm working on.)
  - ❌ Another bad one. I’ve only written on 51 occasions all year. And I found that having this site has taken away from writing fiction, which is probably more important to me, but is harder.
Overall
The overarching theme has been that I’ve found it really hard to achieve much of what I set out to this year. That’s a reality of having two children under 3, frankly. Daytimes are very intensely focused on them, and work takes priority alongside them.
I’ve spent a lot of time watching TV, which wasn’t one of my goals. But 90+% of that was on my iPhone and AirPods, in the middle of the night, with a sleeping baby in my lap, because my younger child sleeps terribly at night.
Thanks to that sleep deprivation (I don’t use the term lightly), for both my wife and I, a lot of the rest of the day has been a very different experience to what I expected. It’s hard to run, write lots, or even read much, when you’re getting 4 hours sleep ON AVERAGE per night, over a whole year, and also have to be responsible for two small children. And those sleepy hours of being awake in the night are when you actually get a chance to do things for yourself.
Interestingly, I tried to read a lot more, but my brain just can’t handle reading in the night. TV is the only thing that’s kept me awake when my body is insisting that’s the wrong thing.
When the reality of my current lifestyle hit, I adapted my challenges, and set myself two new goals: Watch all of Star Wars: The Clone Wars and Star Wars: Rebels before Ahsoka started on Disney Plus, and watch all of the Marvel Infinity Saga movies that I hadn’t already seen (everything after the first Guardians of the Galaxy, around 10 movies). Both of which I smashed, thanks I guess to the baby sleeping so badly.
Life is what happens when you’re busy making other plans. And I wouldn’t trade my kids for anything. But I’ve learned this year that goals need to adapt when life happens.
I’m not sure what I’ll do next year yet.

If you liked this article, please consider buying me a coffee to support my writing.
30 December 2023
- challenges
Small PRs
When working with a team of developers, big or small, it's really valuable to keep your PRs as small as possible. There are plenty of good reasons for this:
- ⏩ Faster merges
- 🧑‍💻 More coding, less waiting
- 👍 Better quality reviews
- 🐛 Easier to fix or revert
Faster Merges
When you have a small PR, it's much quicker for someone to review, so it's faster for them to approve as well. That means you can merge your code more quickly. And that in turn lets you avoid issues such as frequently getting out of date with the base branch, fixing merge conflicts, etc.
It's also great because it means you can ship your code sooner; what's the point in writing code to leave it sitting in a branch for ages? Get it merged and get people using it!
More Coding, Less Waiting
Related to the speed of merging, if you split your work into separate PRs, then you can parallelise your work, saving a lot of waiting time. While your first PR is being reviewed, you can be working on writing more code that goes into your next PR. If you save it all up for one big merge, then you're sitting around waiting for a review - which takes longer because the PR is bigger!
For example, say you're working on reworking an existing feature. You might have a few things to change: text changes in the UI, renaming some variables and methods, and adding some extra functionality. You can easily do them as one big PR, but if you split them out into three distinct things, you can be working on adding your new functionality while the first two PRs get reviewed. And the reviews will happen more quickly because it's much easier to review and approve some copy changes and renaming than it is to review new functionality. And the review of the functionality is quicker because it’s clearer to see what’s changed, without the noise from copy changes and refactoring.
(I’m also a big fan of stacked PRs, which is a topic in itself.)
Better Quality Reviews
As a reviewer, when you have a smaller PR to review, it's much easier to get the full picture of what's changed. As mentioned above, when a PR is small and contains as few changes as possible, it’s harder for complexities to be hidden, and so it's easier to find and point out any issues. A smaller PR greatly reduces the risk of shipping bugs.
It's also just nicer, as a reviewer, to be able to spend less time reviewing PRs. Particularly if your team is so small that you're involved in reviewing most/all PRs, or if your team is so big that there are lots of PRs. I’ve been in both scenarios and you can spend a lot more of your day reviewing code rather than writing it. So the smaller the PR is, the better that is for the reviewer.
Easier To Fix Or Revert
If the worst happens and you ship a bug, having small PRs with atomic changes makes it much quicker and easier to identify and fix the bug. You can read the git commit history or PR history to find out what changed when - if you have lots of changes in one PR, it's easy for something to get overlooked.
It also means that if something significant went wrong and you need to back out of the change, you can just use git to revert that commit rather than having to manually change the code to how it was before.
PR Tips
So small PRs are great. And here are some other tips to make your PRs easier to review.
Review Your Own PR
Review your own PR. Seriously. It's amazing how much you can find to change just by looking back at the code in the PR view.
Keep Titles Concise
Make sure the PR title is easy to read. It should be a concise summary. It shouldn't be an explanation or a comment - leave that for the PR description. And if you find it hard to summarise, it might be a sign that your PR is doing too much - especially if you have the word "and" in there.
Make Descriptions Descriptive
Having kept the title short, you can then make full use of the PR description to explain what you've done. If you're changing UI, then Before and After screenshots are great, as are references to designs. If you've been unable to shrink it down and have had to create a particularly complex PR, then the description is a great place to try to make it less complex by summarising what's changed.
But Seriously, Review Your Own PRs
You can leave comments on your own PRs. They can really help to explain things to reviewers. Some good examples are "this is where the main change is", if the bulk of the PR is essentially wiring up that change. And "this was cut and pasted from here to here", if you've just moved code around - it really helps to make it easier to understand what's actually changed.
(Be careful only to leave comments on the PR when the comment is for the PR. If you're explaining how some non-obvious code works, for example, you might want to consider making that a comment in the code, so that it explains things to future readers of the code, rather than just the PR reviewer at that moment.)

If you liked this article, please consider buying me a coffee to support my writing.
27 November 2023
- engineering
Industrial and Independent Software
I really liked this article from Steph Ango, aka kepano on Mastodon, on the difference between industrial and independent software makers.
The whole article is a good read, and worth going through in full. But here are a few of my favourite parts.
Industrial software has a lot of critics, but it also does have its place:
Google, Apple, and Microsoft make industrial software. Like industrial jam, industrial software has its benefits — it’s cheap, fairly reliable, widely available, and often gets the job done.
But industrial software has also greatly damaged how we all value software:
Industrial software has become so incredibly cheap that most of us have lost the sense for how much value a quality piece of software can provide. We have become numb to the taste of good software and hypnotized by the idea of “free”.
I really like this comparison to grocery shopping:
I notice that I spend less on personal software than I do on groceries and many basic things.
I’m hesitant to spend on software, and will often hum and haw for weeks after using a free trial. But I’ll often try groceries on a whim, with no idea whether or not I’ll like them. No idea why that is.

If you liked this article, please consider buying me a coffee to support my writing.
23 November 2023
- software
App Defaults
I read this article about default app choices by Robb Knight and thought it sounded fun. I’ve listed all the apps I use in various categories. (This doesn’t account for work, where the answer is “insert Google product here”, when I don’t get a choice.)
- Mail Client: Mail.app
- Mail Server: Fastmail with custom domain
- Notes: Obsidian
- To-Do: Todoist
- iPhone Photo Shooting: iOS Camera
- Photo Management: Photos.app and Google Photos (family sharing)
- Calendar: Fantastical backed by Google Calendar
- Cloud file storage: iCloud Drive
- RSS: Reeder backed by iCloud
- Contacts: Contacts.app
- Browser: Safari
- Chat: WhatsApp, Slack
- Bookmarks: Safari
- Read It Later: Safari Reading List
- Word Processing: Obsidian and Google Docs
- Spreadsheets: Google Sheets
- Presentations: n/a
- Shopping Lists: Todoist
- Meal Planning: Google Docs
- Budgeting & Personal Finance: Google Sheets
- News: The Guardian, BBC News, Mastodon (via Ivory)
- Music: Spotify, and some local files synced in Apple Music
- Podcasts: Overcast
- Password Management: 1Password
  
  If you liked this article, please consider buying me a coffee to support my writing.
3 November 2023
- app-defaults
Deleting Old Simulators
When you update to a new version of Xcode, you can often be left with older versions of the simulator hanging around. You can find out which simulators are unavailable by browsing the results of this query:
```
xcrun simctl list devices
```
You might see some output like this:
```
-- Unavailable: com.apple.CoreSimulator.SimRuntime.iOS-14-5 --
    iPhone 8 (random UUID) (Shutdown)
```
You can delete any unused simulators and reclaim the space on your machine:
```
xcrun simctl delete unavailable
```
I previously linked to a great resource full of Simulator tips and tricks which is also really worth a read.

If you liked this article, please consider buying me a coffee to support my writing.
27 October 2023
Xcode 15 Bookmarks Feature
Xcode 15 has a new Bookmarks feature that looks like it will be really handy.
You can create a bookmark anywhere in code, and it’ll be tracked in a new Navigator in the left panel. I do this quite a lot just now with Breakpoints; I don’t actually want a debugger breakpoint, I just want to be able to quickly jump to certain points in the code that I’m working on. But breakpoints are really annoying because I can either stop a lot when running code, or disable breakpoints. Bookmarks are exactly what I need.
You can add notes to bookmarks, and those will be highlighted in the source editor too. Like todo comments for example. So while browsing both the navigator and the code, you can see why you bookmarked that point.
Search Results
You can also bookmark search results, effectively creating saved searches. I often find myself repeating the same two or three searches a lot in a short period of time, so having the ability to save them rather than rerunning a lot will be great.
In work, we often leave Jira ticket references in comments if we know we have some upcoming work in an area of code. For example if we’ve identified a code improvement but don’t have time to do the refactor now. Or if I am implementing a new feature in chunks, I’ll often leave some methods unimplemented because they come under a different ticket. So being able to create saved searches for those ticket references, using Bookmarks, will be a great productivity improvement.

If you liked this article, please consider buying me a coffee to support my writing.
9 June 2023
- xcode
- wwdc23
Working on Running Track for fun again
I’ve not worked on Running Track for a while. Life has been busy and time has been limited. But when I have had time, I’ve found I don’t really want to work on it.
My free time is limited, and while I love making apps, I don’t love the pressure I was putting on myself to get Running Track into a shippable state. When I finish work, and have some down time, I want to enjoy what I’m doing.
So I let myself play around with the code instead. I’ve done things I’ve always deprioritised, like playing with CI setup or moving the project over to use SwiftPM. Things that I want to do, since this is a hobby project for me.
And it felt good. It’s not got me any closer to shipping, but I feel good about playing around in the codebase again.
And I have a load of ideas from WWDC to work on too, even though I can’t ship them til September or later.
It’s nice to have fun on a side project rather than making it another job.

If you liked this article, please consider buying me a coffee to support my writing.
8 June 2023
- build in public
- runningtrack
UI Previews in Xcode 15
Apple keeps reminding us that the best way to write new apps is with SwiftUI. But for those of us who are working on existing apps, UIKit is often still the reality.
SwiftUI has had previews in Xcode from the start. It's a great feature, because it helps you see your UI code while you're writing it. You can sort of get it working with UIKit too, but it's a bit hacky and it never feels to me like it's meant to work.
Now, Previews support UIKit and SwiftUI equally well, with the new #Preview macro. (This also simplifies creating previews on SwiftUI, which makes me happy.) Here's how to create a preview of a UIViewController:
```
#Preview {
    MyViewController()
}
```
And here's how to create a preview of a SwiftUI View:
```
#Preview {
    MyView()
}
```
Really simple, and there's no difference between SwiftUI and UIKit. Really cool to see!
This code below contains two previews, a SwiftUI one and a UIKit one. You can have these side by side in the same file and it works nicely.
```
import UIKit
import SwiftUI

class MyViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()

        let label = UILabel(frame: view.bounds)
        label.text = "Hello, world!"
        label.font = UIFont.preferredFont(forTextStyle: .title1)
        label.textAlignment = .center
        view.addSubview(label)
    }
}

struct MyView: View {
    var body: some View {
        VStack {
            Text("Hello, world!")
                .font(.title)
        }
        .padding()
    }
}

#Preview("UIKit") {
    MyViewController()
}

#Preview("SwiftUI") {
    MyView()
}
```
If you liked this article, please consider buying me a coffee to support my writing.
7 June 2023
Writing Documentation For Future Me
I was working on some code in my day job recently and trying to figure out how something in a shared library worked. When I looked at the docs, it was described pretty thoroughly.
I wanted to thank whoever it was who wrote the documentation, because I had been pretty unclear on how the code worked. So I used git blame to find out who the author was.
It was me, from a year ago. I had zero recollection of this part of the codebase, and thought it was my first time working on it, til I saw that Past Me had already been there, hit the same problem I did with understanding, and added docs so that others could avoid getting stuck in the same place.
I always try to write documentation from the point of view of someone who has no idea what’s happening. It’s amazing how often that helps Future Me.

If you liked this article, please consider buying me a coffee to support my writing.
1 June 2023
- documentation
- engineering
Combine's `print` operator
This is a really useful little operator for debugging Combine code. It logs each event in your stream, and adds your given prefix to it as well. The example in Apple's docs) is a good one:
```
let integers = (1...2)
cancellable = integers.publisher
   .print("Logged a message", to: nil)
   .sink { _ in }

// Prints:
//  Logged a message: receive subscription: (1...2)
//  Logged a message: request unlimited
//  Logged a message: receive value: (1)  
//  Logged a message: receive value: (2)
//  Logged a message: receive finished
```
Or you can really simplify it, because both properties are optional. The String is a prefix for the log statement, which is nice because it makes it easy to search your output and to get context if you have multiple Combine streams. But you don't need it. And the second parameter is an output stream, which is just the console by default.
Here's how it looks when you just quickly want to throw a print in there:
```
let integers = (1...2)
cancellable = integers.publisher
   .print()
   .sink { _ in }

// Prints:
//  receive subscription: (1...2)
//  request unlimited
//  receive value: (1)
//  receive value: (2)
//  receive finished
```
Aside: I've slightly changed the example from Apple's docs
Amusingly, the commented output is slightly wrong on the docs. Clearly the range in the example was updated from 1..<2 to 1...2, because the first line of the output is wrong, and it's missing the second receive value line. A good example of what happens when you change the code and forget to update the docs!
Here's the original. Notice the difference between the ranges in the code and the comment, and the missing second receive value line compared to my output:
```
let integers = (1...2)
cancellable = integers.publisher
   .print("Logged a message", to: nil)
   .sink { _ in }

// Prints:
//  Logged a message: receive subscription: (1..<2)
//  Logged a message: request unlimited
//  Logged a message: receive value: (1)
//  Logged a message: receive finished
```
If you liked this article, please consider buying me a coffee to support my writing.
30 May 2023
My Home Screen - May 2023
I find it fascinating to read about home screens. How other people use their phones. And I love looking back at old screenshots of mine. I've kept them in Day One for years, but I think it's a cool thing to track in public too.
So here's my Home Screen as of the 4th of May 2023.

First off, I use only one Home Screen, and then a combination of Spotlight search and the App Library for finding everything else. I find the suggestions in the App Library pretty decent, and search works way better for me than browsing deep through screens or folders.
I also don't change home screens for different focus modes. I tried it for work, but I found it off putting in a way I've not been able to put my finger on. Like it made my phone feel wrong.
Widgets
I like widgets. I find myself wishing for a bigger Home Screen so that I could fit more in.
My widgets: - Fantastical to see what's happening next; - Awesome Habits to keep me on track, by seeing what I still need to do whenever I unlock my phone; - Todoist in a stack with Awesome Habits for the same reason; - Kindle because I like being able to see the cover of my current book, in lieu of actually having a physical book, and it's also a great reminder to me to read more; - and Carrot to keep track of the weather. I find this works really well because I only passively check it, but the key thing like "will it be warm, will it rain" gets into my head subconsciously.
Apps
If I have a widget, I don't also have the app icon. There's not enough space for that! And this isn't a full list of every app I use.
For example, Ivory and Knotwords are missing. I keep them off my Home Screen because they're distracting.
And Day One is one of my most used apps but I use it at a particular time of the day, and the Spotlight Suggestions always show me it, so I never need to go looking for it when it's time to write in my diary.
Apps on my Home Screen: - Huckleberry is a parenting app, for tracking sleep among other things; - Duolingo because I'm now properly trying to learn French, after been doing it off and on for a decade; - Spotify because I'm listening to more music again these days; - Reeder for RSS, which never really went away for me; - Mail because it's like the cockroach of technology; - Slack for talking to work colleagues and friends; - Obsidian for writing things like this, along with most notes; - And a folder full of tools for projects like working on this site, or my run tracking app.
Dock
These are the apps I use most. I don’t think I need a Dock as such, because I only have one Home Screen. But it’s there, and I put my most important apps in it.
I use Safari a lot. I think it might be the only app whose position has never changed since my first iPod Touch in 2008.
WhatsApp is how I talk to people.
Overcast is vital for listening to The Adventure Zone and Bring Back V10s.
And Google Photos is how I share family photos, and it’s basically become my photos app now.
Watch
I wear my Apple Watch all day every day. The biggest features for me are time and notifications, but there's some glanceable info that's useful, and a couple of apps that I use quite heavily.

The main two apps I use are Todoist and Waterminder.
I use Waterminder almost exclusively on the watch. It's a full featured app. And it's accessible and quick to just add a drink without getting my phone out.
And I use Todoist for much the same reason. I can jump in, check what's on my list, and quickly tick things off, without having to get my phone out. It's great.

If you liked this article, please consider buying me a coffee to support my writing.
4 May 2023
- homescreen
I Don't Like Ratings
Giving something a score is incredibly subjective. Whether something is worth 1 star or 5 depends on who you are, how you felt at the time, how much time and thought you were able to give it, and whether or not you'd seen other opinions before you gave your own rating.
If it's a product rather than a form of media, you can give a review after using it for one day or one month, and that experience, or lack thereof, with the product can cause very different ratings.
But someone glancing at a rating doesn't get that detail. They might, if they read a full review, but the whole point of a rating is to sum it up into a score, so that people don't necessarily have to go into the details.
The Phantom Menace is a 4 star movie
Trust your feelings, you know it to be true.
How do you know if you can trust star ratings? Are the reviewers spending enough time with the item in question? Do they have the same opinions, the same values, as me?
For example, I gave star ratings to every book I read on Kindle, for years. But I never wrote a review. And basically everything was a 4 star rating, because I only rated books I finished, and I don't see the point in finishing a book at the point when I know it's 3 stars or less. But 5 stars is basically perfect so nothing gets that, except Night Watch by Terry Pratchett).
Others however will have different scores. Some people will give Night Watch 1 star. And they're wrong, of course, but if you've never read the book, who do you trust when you're trying to decide which book to read next?
Aggregators solve this to some extent, although it creates groupthink. For example, The Phantom Menace is my favourite Star Wars prequel by far (admittedly a low bar), because it has Qui-Gon Jinn and it doesn't have that utterly unbelievable relationship between Anakin and Padmé. But almost everyone else thinks The Phantom Menace is the worst, to the point that some people exclude it completely. If I trusted others, I'd never watch it, and miss out on Darth Maul, Qui-Gon, and the whole switcheroo thing with Queen Amidala and her handmaidens. And still be stuck with the ridiculousness of Anakin Skywalker in Episodes II and III.
Anyway.
The point is, giving something a star rating is bad because it's just like, your opinion, man.
Alternatives
I read Casino Royale earlier this year. And in many ways it's a problematic book. The story is good, but the telling is often uncomfortable. How should I rate that? Instead, I wrote (briefly) about its pros and cons, and tried to think of who would like to read the book, and how else could someone enjoy what is a good story overall.
So instead of a rating, you have to read what I wrote. Which isn't as quick, if you're looking at multiple movies or multiple reviews, and that's why star ratings exist; it's a shortcut to make your decision simpler. Was this a worthwhile book or movie or not? How many stars did it get?
But I'll never trust star ratings, at least not while The Phantom Menace (6.5 stars out of 10, 51/100 on metacritic) is rated so far behind Revenge of the Sith (7.6 stars, 68 on metacritic).
(This train of thought originated from a process I recently experienced where people were given numeric ratings based on various criteria. Needless to say I wasn't enamoured by that.)

If you liked this article, please consider buying me a coffee to support my writing.
26 April 2023
- opinion
- ratings
Evolving Projects
I'm a big fan of keeping things vague and seeing how they develop. It's how I'm writing my novel and short stories, and it's how I approach other projects too.
Running Track was originally a simple tool for sharing GPX files made from my runs.
And my 2023 albums project was originally motivated by wanting to listen to more music. So it was simply "listen to 12 albums", one for each month of the year. Nice and simple.
As it's gone on though, I've realised I'm picking albums I like listening to, rather than exploring new music. I'm looking for memories and happy places. So the project is evolving that way too.
I'm really enjoying the trips down memory lane, and it makes them easier to write about too. So that's the 2023 album project now. It's found its own definition as I've worked on it.

If you liked this article, please consider buying me a coffee to support my writing.
18 April 2023
- meta
- opinion
Owning my own content
I really enjoy writing blog posts. I'm also one of those weirdos who likes writing documentation for my code. I like that it makes me think more than just superficially about a subject, like how a thing works or what my opinion on it is. If I'm going to put something in writing, I have to get it right, or at least makes it defensible. And that makes me put much more effort in to the writing, compared to a social network where content is essentially ephemeral, so quality matters much less.
So I'm trying to write more blog posts, longer posts, rather than just quickly sharing thoughts on social media. And I'm liking it.
But it's not just about writing blog posts any more. This year, I've started moving away from third party services where I can, and looking at what I can own for myself. And I really like where that process is going.
Owning the content
An important aspect of having a blog is the ownership it gives me over the stuff I produce online. I don't have any worries about changing social network, and having to migrate or export my posts. I don't worry about a service being taken over or sunsetted, and possibly losing everything. It all just lives here.
And I don't want to create content for other sites to advertise against any more either. Goodreads, Letterboxd, Twitter, Instagram, whatever else. I don't want to share those links around. I don't want to have various things living in random corners of the Internet. I want my "content" in my place. And a nice benefit of that is that nobody can get rich off of me by turning me into part of a content farm that doesn't pay its contributors but still aims for the kind of ad revenue that makes its founder a billionaire.
I want my personal site to be my source of truth. That way I can share a link wherever it's appropriate, and now I'm completely responsible for what's there. And perhaps one day I'll look at building some ActivityPub or micropub service, or integrate something like Webmentions, to embrace the Fediverse or IndieWeb and add a social layer. But what matters most to me isn't the social element, which is essentially the comments section of a blog. It's the content itself.
Owning the appearance
I love being able to style my site and my content however I want. And I'm well aware that the style is really basic at the moment. But I'm getting the opportunity to learn more about CSS, to improve the appearance and style things how I want them to look. I couldn't do that on Twitter or Letterboxd.
Owning my own projects
I love what I'm doing with my albums and books projects this year, tracking my listening and reading here. Over the years, I can build my own archive, like Last.fm and GoodReads but owned by me. Here. Rather than having some other network to contribute content to, and manage.
I can show as much content as I want, and completely control my own privacy too. I'm sharing what I want to, and don't have to worry about what else is being gathered.
And I can present the projects however I want. Make a library that covers all my favourite media, see challenges for a year, show how books and music relate to each other rather than being siloed. There are so many possibilities.
I've mentioned Instagram in this post already. I stopped posting to Instagram, in large part because I don't want to be part of that service's monetisation. But I do enjoy taking photos and sharing them, and while I don't have any photography here yet, I'm looking forward to one day working on a fun way to share them on my site, while learning about how to present them in HTML and CSS.
Owning my own vanity
I love not worrying about likes, retweets etc. I have no analytics on my blog at present. Maybe nobody reads it? That's fine! It's for me.
Related reading:
Matthias Ott: The Year of the Personal Website

If you liked this article, please consider buying me a coffee to support my writing.
21 February 2023
Running Track release: Slowly but surely!
I've spent a little while recently getting Running Track ready for release.
I've done a load of cleanup. Bug fixes etc.
And I've also added a new feature, because why not...
New goal type
I've had three goal types in mind from the start. I initially cut two of them so that I could focus on getting the total distance goal working well, but I've added another goal now: a single distance target. Set yourself the goal of running a distance in one run.
For example, some people might want to set a target of running a 10k or a marathon for the first time. In training for half marathons, I always feel like doing a 10 mile long run is a milestone, so I'll be using it for that.
Adding another goal type makes me feel better about launching with a subscription, because I want to make sure there's as much value as possible for people to pay for, and goals are a subscription feature.
UI cleanup
There's a lot I want to do with the UI, which is a blog post in itself. I restricted myself to only those things that are necessary, or especially bad, so that I can focus on shipping now. Things that might be confusing, or that are egregiously ugly. This is the painful part, because I have to be less harsh on myself and try to judge this objectively...
Code cleanup
I don't want to ship with any compiler warnings, and mostly that's fine, I clean them up as I go. But I have SwiftLint configured to generate warnings for TODO comments, and I left a few of them in as reminders to myself. So I've been cleaning them up, as well as removing some that relate to future work - they moved to Todoist, where I track all my tasks.
Bugs
I don't want to ship any known bugs. I've made a good dent on the ones I've found myself during testing, and after I complete that list I'll open up to TestFlight to see what others might find.
Getting there
I have four known bugs left, and then I can finally feel comfortable with getting a TestFlight build out to people. The rest of the code and marketing materials are in a good place for a first launch.
It's getting there, slowly but surely!

If you liked this article, please consider buying me a coffee to support my writing.
17 February 2023
- build in public
- runningtrack
Software struggles on slow networks
Andy Bell experienced a power cut, and thought he'd check the UK Power Networks website to find out. But they forgot they were making a website for people who might reasonably be expected not to have Wifi, thanks to a power cut...
In this video, I tried to load the site. It took just under a minute to show any content, and then I ended up giving up completely after watching it load for 3 minutes. 3 minutes. Obscene.
There's a laziness among some web and app developers around performance on slow networks. They just assume your internet connection won't be slow. Because who even has slow internet these days anyway, don't we all have fibre?
I recently moved house, and spent two weeks tethering on my phone because our internet connection was slow to be transferred. Being an old house, I had terrible mobile signal, so I often found myself with websites and apps that behaved really badly.
The app we use to track our baby's sleep has a really slow and unreliable sync engine, so that became a disaster for two weeks. Plenty of websites would load headers and UI chrome, but fail to load any content for minutes. Apple's App Store was particularly slow, often with no loading UI. And I even found a game that wouldnt let me play until it had finished whatever API calls the developers thought were important enough to block play, even though levels were worked fine when offline completely.
There's no excuse for only building your product for people with fast internet connections. In the two examples here, Andy and I experienced downgraded network quality. And there are still a huge number of people for whom this is normal.

If you liked this article, please consider buying me a coffee to support my writing.
17 February 2023
- opinion
Annual Challenges
For a few years I've set myself a reading challenge. Usually something like "read 20 books a year". And I've read a lot more this way than I otherwise would, as I proved to myself last year when I didn't set a challenge and hardly read anything. So I've set one again this year and I expect I'll do it for the foreseeable future.
I've also been feeling lately that I don't listen to enough music any more, and wanted to change that. So I've also set myself a music challenge.
And I've fallen out of running in the last six months or so, mostly because a new baby really takes over your life. As the baby gets older, I want to run again, but that's a challenge to start working at later in the year, so the number is set deliberately low.
My challenges for 2023
- 📚 Read 20 books. (I've beaten this number every year since 2015, except for last year when I didn't set a challenge.)
- 🎧 Listen to at least 1 album every month. (Not a high bar, as I'll come on to later.)
- 🏃 Run at least 1 time every month. (On average, since I think it'll be loaded towards the latter half of the year. But 12 runs this year feels like a nice round number, and while it sounds low, I've not ran since last September, and only twice since the start of June.)
My daily challenges
- 🇫🇷 Practice French every day.
- 📓 Write in my diary every day.
- ✍️ Write something every day. (This can be a blog post on this site, or some progress towards the novel or the short story I'm working on.)
Apps
- Gola is how I'm tracking my annual challenges. It's great, you should download it if you're going to try this approach
- Awesome Habits is how I track my daily challenges. There are plenty of alternatives in this space, like Streaks or Productive, which I've also used over the years. I really like the UI of Awesome Habits, especially the iOS widget.
- I use Duolingo to practice French, and have had a streak going for over a year at this point.
- Day One is a great diary app, and I now have an archive going back almost a decade.
It's a hack
Annual challenges are a little hack that work for me. I think it triggers the reward part of my brain - I feel like I've achieved something, however arbitrary it is. And if I set the target low, and complete it early, I don't stop there; I find it even more rewarding to keep going and smash past the original target.
It's a silly hack, considering these are things that I want to do, and shouldn't need to trick myself into doing. But it does work, because it makes me spend at least some of my time doing that thing instead of browsing social media or playing a quick mobile game.
What about resolutions?
New Year's resolutions are a terrible idea. The resolution version of these would be something like "listen to more music", "read more", "learn French". Vague ideas that are impossible to measure, and therefore hard to achieve.
The ultimate aim here is to listen to more music, read more, learn French. But leaving it at that is setting yourself up for failure.
My challenges are designed to be easily measurable, so that I can really clearly see my progress. And I've found that they build into habits over time (part of the marketing of Awesome Habits, in fact). I've been writing in my diary for years, and practicing French every day for a year. I've been writing a lot more in the last couple of months too.
And something else that I think is important: I'm very forgiving with myself, because a) I don't want these things to become a chore, and b) any progress counts towards building a habit. Some days I'll do lots, some days I'll barely have time for anything. Doing more of something I want to do is a good thing, however much I'm actually doing. The challenges are a prompt for change, not important in themselves.

If you liked this article, please consider buying me a coffee to support my writing.
31 January 2023
- challenges
- opinion
Bypassing Twitter
I don't use Twitter any more. But sometimes I want to reference a tweet. Maybe it's a useful tip that was shared in the Before Times. Maybe it's news, or maybe you want to make fun of Space Karen's most recent idiocy. Enter nitter.net.
Nitter scrapes Twitter and matches the URL format, so if you ever need to refer to a tweet or a profile, just replace twitter.com with nitter.net.
Even better, it publishes an RSS feed for profiles, so I've added some accounts to my RSS reader.
Most of F1 Twitter has remained there, much as I wish everyone would move to Mastodon. And there are insights and news that I want to stay connected to.
So I just subscribed to the RSS feeds for those people I want to follow. And I can keep up with Twitter without my profile adding to the number of active users or tweet view count.
🖕 Space Karen.

If you liked this article, please consider buying me a coffee to support my writing.
29 January 2023
- twitter
Blogs are dead, long live blogs
I don't remember when Google Reader was killed off. I vaguely remember the cries of the death of blogging and RSS, and the plethora of new services that launched to completely disprove those obituaries. Feedly. Feedbin. FeedWrangler. Etc etc. But by that point, a shift had happened for me which kind of justified Google's lack of interest in Reader.
Google Reader
I discovered Google Reader sometime around 2009, give or take a year or two. I was in uni, studying computer science, and I was just starting to really get into the tech news world. Engadget, TechCrunch, The Register, that sort of thing. I heard about Google Reader, and decided it sounded like a cool place to get my news from, rather than jumping between sites I had bookmarked.
Then I started seeing repeated mention of the same bloggers, like Gruber, Kottke, Marco. So I subscribed to them as well, and discovered how fun it was to follow individuals as well as bigger sites.
I checked in on Reader multiple times a day. Whenever I was at a computer, really. Combined with the advent of the iPhone, my personal switch to using the Mac, and the related rise of tech podcasting (👋 TWiT and 5by5), it all shares a very special place in the nostalgic part of my memory. It's when I really got into this corner of the Internet.
But over time, that Reader time moved to Twitter. I started using Twitter in 2009 as well, and what started as a bit of a social novelty eventually became a combination of social site and news source. After a few years, Twitter was where I found blogs to read, not Reader. And it had the added benefit of conversations happening in the same place, linking all these blogs and bloggers together with the readers.
Comments Off
It's funny that I liked the conversations on Twitter because I have always hated comments on blogs. It seemed like a place for trolls to go to start arguments. I felt like the noise of all that negativity spoiled anything good in the comments section. So I just ignored them.
Twitter fading
But on reflection, Twitter being a news source and social site is basically just the comments section of a site, with occasional reference to the main article. The comments are the main event there. And that was fun for a while. But it stopped being fun, and it's taken me a while to realise what was missing. The actual articles. In-depth thought, and replies on other people's blogs which had the same depth. Not hot takes and trolling that could all be spat out while sitting on the toilet.
Twitter's algorithm doesn't reward deep thought or considered nuance. It rewards opinions that will generate a reaction, and a negative reaction is much easier to achieve. So lots of negative sentiment gets rewarded, and that in turn makes it less enjoyable to be part of. Over there last few years, I've noticed lots of previously active Twitter users becoming less engaged, often blaming negativity, trolling, and worse.
And that's the Twitter that we had before it was bought. Lots of hot takes, lots of negativity being algorithmically rewarded. Far less civil conversation or nuanced thought.
Blogs are cool again
Then the changes happened at the end of last year, and that felt like the final straw for a lot of people. Lots of people stopped using Twitter, often moving to Mastodon but also reviving the old idea of blogging. I'm seeing so many more interesting blogs in my RSS feed now. And I'm more motivated to write too.
And I love it. It's so cool to read articles instead of tweets. Long may it continue.
Links
- Here's an OPML file with my current subscriptions.
- An article on The Verge, of all places, about personal blogging.
- Bring Back Blogging is a site dedicated to bringing back personal blogging, surprisingly enough, with a large directory of blogs to explore.
- Paul Stamatiou, an ex-Twitter employee, takes a deep dive into Mastodon and owning our own content.
  
  If you liked this article, please consider buying me a coffee to support my writing.
27 January 2023
- opinion
- blogging
Xcode File Navigation Shortcuts
Two of my most-used keyboard shortcuts in Xcode must be ⌘-Shift-O (Open Quickly) and ⌘-Shift-J (Reveal in Project Navigator).
I love being able to search for any file or type or even method, and open it immediately. Open Quickly is a great underrated feature of Xcode.
Reveal in Project Navigator is really useful because it lets me quickly browse related files, rather than having to navigate the directory structure manually.
A really cool website for little snippets of Xcode goodness like this is xcode.tips. Here are the related entries for these two features:
- Open Quickly
- Reveal in Project Navigator
  
  If you liked this article, please consider buying me a coffee to support my writing.
17 January 2023
- xcode
- tip
Accessibility Affects Everyone
I've had the text size on my phone set as small as possible for as long as I can remember. For one simple reason: to maximise the available space. My close-up vision has always been fine, so this has worked for years now.
A couple of years ago my wife and I had our first child. And my sleep went from 8 regular hours a night, to maybe 6 interrupted hours.
And then we had our second child last year. Now I get maybe 4 hours of interrupted sleep. (Nobody ever talks about how badly children can affect your sleep. It's not just newborn babies!)
What's this got to do with my eyesight? Well, a little while after my first child was born, I started getting occasional headaches. When I spoke to the doctor, they said they often see this kind of migraine due to stress, and lack of sleep. Two things which come with a newborn!
When my second was born, it started happening a lot more often. Sleep and stress are hard factors to control in this situation, so I started looking for anything else which might be connected. And I realised that, when I was more tired, I was straining my eyes more to see my phone screen.
I've since changed my default text size by bumping it up a couple of notches. No more straining my eyes to read when I'm tired. And more importantly, no more headaches.
People often think things like Dynamic Text on iOS are for a minority of users. Accessibility is often an afterthought in apps. But accessibility tools are useful to everyone, in all sorts of unexpected circumstances.
Here's an example of just how different 2 steps in test size can look (tap/click to open in a new tab):

The image on the right gives me headaches. That's not even about ease of use, that's a health issue.
Make sure your apps support Dynamic Text, VoiceOver, and any other accessibility frameworks that are relevant on whichever platform you're working on.

If you liked this article, please consider buying me a coffee to support my writing.
11 January 2023
- accessibility
My Internet Usage With Poor Connectivity
I recently moved home and haven't had fibre connected yet, so I'm exclusively using my phone service for the Internet.
Which sucks, because it's an old house with terrible signal. There are patches where I get a reasonable connection, some where I get a very slow one, and lots of dead zones.
Slow Internet is definitely worse than no Internet. I can spend a LOT of time staring at my phone screen waiting for something to load. If I didn't have the hope of a connection, I'd use my time a lot more effectively than waiting for a loading screen to disappear!
How Am I Internetting Now?
But it's been interesting to step back and see how my web use has changed with less immediate access. With a normal connection, I'd usually open Ivory to check Mastodon, and Reeder to check RSS feeds. With an unreliable one, I haven't opened Ivory in days. I (subconsciously) prioritise spending a bit of time waiting for Reeder to sync, then fall back to the Kindle app to read a book instead.
With less immediate access to information, I'm preferring longer-form reading. That may be because my book is immediately available offline, so I don't have to wait around to see if I get a quick enough connection to sync, but it's also quite enjoyable.
And when I do browse, I think it's telling that I would rather refresh RSS feeds than Mastodon. That's my priority now. At the time of writing, I haven't checked Mastodon at all for 2 days and I don't miss it at all. I spend so much time waiting for Reeder to sync that I don't get round to thinking about Mastodon! But in recent years I would definitely have gone the other way; waiting ages for Tweetbot to refresh my Twitter timeline rather than reading RSS or a book.
Why Am I Reading More And Doomscrolling Less?
I think there are a couple of elements to this. The first is that I'm just enjoying reading more in the last few weeks, so I may well have gone to the Kindle app more often anyway.
But the other is that I'm enjoying reading blogs with an RSS reader again. There's much more of a conscious choice involved, rather than just doomscrolling through a feed. I quite like that I'm reading things in a random order of my own choosing, rather than a strict chronological timeline or an algorithmic timeline that's configured to keep me hooked.
And I like getting to read a slightly longer thought than can be fit into a tweet or a toot. It lets people reason more, fill in context. I've subscribed to a lot of personal blogs recently, and I really like the format compared to microblogging.
Subscribing via RSS also allows for other types of writing; for example, one of the feeds I'm subscribed to is Matt Gemmell's RSS feed, which contains a short story every Monday. Not a tech hot take, just some enjoyable fiction.
I like this approach to using the Internet, although I'm interested to see how it changes when I have a reliable connection again, having experienced this.

If you liked this article, please consider buying me a coffee to support my writing.
10 January 2023
- opinion
Quick Tip: Xcode Keyboard shortcut CMD-J
I love working with code files side by side in Xcode. It's handy because I'm usually focused on two or three related files, so the ability to split them across the monitor is really useful.
I also love using the keyboard to control my computer, rather than my mouse. It's so much quicker than having to move my hand to the mouse and move the mouse cursor around to get to where I want to go.
CMD-J lets you switch between those side by side file editors, using just the keyboard. Press it and Xcode asks which open editor you'd like to move focus to.
Great when you're frequently going between two files.

If you liked this article, please consider buying me a coffee to support my writing.
3 January 2023
- xcode
- tip
Balancing Many Projects
I have a couple of very different projects on the go just now. I’m working on releasing an iOS app, and also working ona novel. The reason for that combination is about 50/50 between my current circumstances and my scatterbrain personality.
Personal circumstances dictate that I can’t spend a huge amount of time using a computer, outside of work hours. Luckily, I had an app almost ready to release that I’ve wanted to ship for years. So my perennial itch to work on a personal app can be scratched by doing a lot of the non-Xcode side of shipping an app: setting up a website, registering domains, writing marketing copy… All of that is really doable on a phone. But you need Xcode to write apps, and that’s where I’ve hit a bit of a brick wall recently. I have no new features to build for release, but lots of little refinements to make, little bugs to fix.
The other thing that I can do on my phone is write. I have all sorts of text editors set up to help me capture ideas: Apple Notes, Obsidian, 1Writer and Runestone are the main ones I go between just now. Having so much time to think, having lots of ideas, and being restricted to my phone, mean writing is an obvious thing to do.
So I've changed things around a little, from heavily concentrating on the app to being much more focused on writing. (That includes blog posts and short stories as well as the novel, though.)
What's important for me is to know I have options. There are times when I can't open Xcode, so working on Running Track is impossible. But there are also times when I just don't want to work on an app. That's my day job too. And I love the fact that I have other options for creative outlets when I only have my iPhone.
The downside to this is that it means I will have more projects progressing slowly forward, rather than fewer projects thundering ahead. That means I'm slower to actually finish things, which is frustrating because I want to get people using my apps. I want to get people reading my stories. I'm going to have to deal with that though.

If you liked this article, please consider buying me a coffee to support my writing.
1 January 2023
Running Track's beta version number is now meaningfully meaningless
I don't really care about version numbers
I've long thought that version numbers are unimportant. The Semantic Versioning structure of major.minor.patch is useful for shared code like libraries and frameworks, but for a client application, while it's still common, it's overkill. Who benefits from knowing if you're on v1.2.3 or v6.9 or v12.0? Famously Google Chrome doesn't bother with Semantic Versioning. Every release is just a new number and it's gone past version 100 now.
The version name is useful of course. It's meaningful for customer support, so that you know if a bug has been patched already, or a feature released, and in which version. It's useful for feature flagging, if you only enable certain features on certain app versions. But that can be any version number, it doesn't have to be x.y.z.
Setting version numbers is harder than it sounds
If you follow Semantic Versioning, you have to spend time deciding on what makes you go from v1.x.x to v2.0. What changes count as major or minor in a client application? And what's the marketing impact of that?
I've worked in companies that shipped code as a major change to the version number, but because everything was feature flagged off, we couldn't talk about the changes. So going from v1 to v2 of an app looked like a damp squib. Marketing didn't like that.
I've worked in teams that have spent hours discussing whether a version should be a major update or a minor update. Hours. People have opinions! I'd much rather remove opinions from the equation.
My initial solution for Running Track
Ubuntu, as well as plenty of other projects now, uses year and month in release names, such as 22.10. That format appeals to me, because it makes it easy to set without any discussion.
Automating the changing of release names also speaks to me. It's nice not to have to think about about these things. Just build the app, and the version gets set based on the current date, without having to think about it.
I had that set up for Running Track. The build I had approved for TestFlight was 22.11.17, because that's the date on which I compiled the build. It matches my approach for automating tagging of builds in git, which seemed useful.
You may have already spotted my mistake...
Testing builds need to be reviewed for TestFlight whenever the version changes. However if you do a new build for the same version name, you don't need another review. So if I make a new app version when the day changes, I'll need to go through TestFlight review again, every day I submit a build. Not appealing!
Meaningfully meaningless
So I've got rid of the automation and I'll be setting the version manually for now. While Running Track is in beta, I'll just keep that random version name. So every beta tester will know when the first build was cut. Meaningless, but with a hidden meaning. Kind of fun, no? Then I'll move to a year.month format like 23.1 in future.
Top tip: don't get too clever and automate too much too soon!

If you liked this article, please consider buying me a coffee to support my writing.
26 November 2022
- build in public
- runningtrack
First release of the RunningTrack marketing website
runningtrack.app
I've published the first version of the website for Running Track. It’s available at runningtrack.app. It's a very early design, I have lots that I want to tweak, but this is a site that will evolve, not a placeholder.
It's built using Publish (just like this site). It's a static site generator built with Swift, which helps keep it quick and easy for me to work with. I build the site with GitHub Actions and deploy the generated HTML and CSS to Cloudflare Pages to host. So I can make changes to the content from anywhere, even my phone.
I'm planning to tidy up the very wordy landing page a lot, and I'll also add a blog there for release notes. But other than that, I don't expect to do anything significant to the site, because it's the app that's important!

If you liked this article, please consider buying me a coffee to support my writing.
26 November 2022
- build in public
- runningtrack
Major Milestone: TestFlight
I’ve just had approval from App Review, so Running Track is now ready for beta testing on TestFlight!
If you’re a runner, get in touch if you want to help test the app.
This is a really exciting milestone in shipping! Getting any approval from Apple’s App Review team isn’t a guarantee, and rejection can cause a lot of problems. It’s awesome to know I can start getting this app into other people’s hands now.

If you liked this article, please consider buying me a coffee to support my writing.
17 November 2022
- build in public
- runningtrack
The Shipping Mindset
A month or so ago I gave myself a clear instruction for Running Track. No new features. It's time to ship something.
Why? I've always believed it's not worth shipping something if it's not ready. Be proud of your work and make the best thing you can. To that end, forcing myself to release something that I don't think it's ready feels wrong. But I'm doing it anyway.
There are three reasons.
1. You're never ready
The first is that a product is never finished. I have lots of features planned, and I'll never get to the end of that list. So I have to release sometime, before I feel ready.
Many of my planned features are niceties. Not valuable. But there are definitely valuable features on my roadmap. So I had to ask myself if the app would suffer for their absence. I think it'll be much better when they're present. These features will really help justify people's investment in the app. But they're not vital. Which ties directly into my second point.
2. Feedback informs direction
I don't know how people will use the app. Or if they even will! So I'd rather be able to get feedback to help steer me in the right direction. If nobody uses it, I can build what I want. If something unexpected comes up, like a really common feature request, I can prioritise that. I want to make this an app that adds value to people. So if I've missed something that lots of people want, I'd like to catch that first.
3. Get the admin out of the way
My third and final reason to ship now is that there's so much busywork around the initial release. Sorting out a business model and committing to it in the code. Setting up a domain, support email etc. Not to mention getting the App Store Connect account set up properly, signing tax agreements, getting through App Review...
I once built an app, years ago, which got repeatedly rejected by App Review before my initial release. It's worth making sure you can clear that barrier before you invest too much time in too many features!
By getting these things out of the way, it'll be much quicker to build and release features in the future. I can focus on features rather than admin.
Ship it
So I'm planning to ship to TestFlight really soon. That's the first App Review hurdle to pass.
I've got a website ready to go, and I'll have that live when I submit for TestFlight review at runningtrack.app. (You can read about how I set that up in my earlier post.)
All the admin stuff is sorted out in places like App Store Connect.
I'll open up TestFlight for a while to make sure I don't let anything stupid slip through. And then it'll be on to the full release!

If you liked this article, please consider buying me a coffee to support my writing.
15 November 2022
- build in public
- runningtrack
Leaving Twitter
The world’s town square. That’s a common metaphor used to describe Twitter. The new owner describes it as such. #JoinTheConversation is a common hashtag to see around the world. The world’s conversations happen on Twitter. Or they used to.
I think that’s a good metaphor. But another is the world’s playground. Lots of fun has happened on Twitter over the 15 years or so it’s existed. Lots of friendships have formed. Lots of entertainment and games. Wordle spread through Twitter, for example. So many comedians have built careers there. And remember the dress? Or Laurel and Yanny? Twitter has been a lot of fun.
There has also been a lot of harassment, bullying, and threats of violence) over the years. A playground will have varying levels of that. You’ll never avoid it, but how the playground is managed by the adults in charge makes a big difference.
Sadly, Twitter’s new owner, supposedly the adult in charge, is one of them. A bully. He will happily criticise his staff in public, and then fire them for disagreeing with him when replying in kind. He will happily make fun of people who wear face masks, as a response to them asking a fair question about them quality of his work. He thinks calling someone a paedophile in front of millions of people is a fair response to feeling insulted. He claims to be a free speech absolutist, yet he blocks or fires (publicly!) those people who disagree with him. He’ll often retweet those people first with some silly comment designed to entertain his legion of fans first though, because he wants to think he’s funny. And will happily engage in this at others’ expense. He claims comedy is legal on Twitter again, as part of his free speech agenda, then suspends accounts engaging in parody, all because they’re pointing out his errors. Our fire someone for drawing humorous cartoons of which he is the butt of the joke.
It’s a classic playground bully persona. You couldn’t write a kids’ TV show with a more clearly defined bully than him. Thin skinned. Can dish it out but can’t take it. Plays to the crowd of sycophants. Punches down.
So do I want to hang out in a playground that’s run by a bully? Nah. It’s his ball. He can play his game. But I’m going home.
—-
Side Notes
- I’ve deactivated my account and removed all links to it from this site.
- I plan to use a mix of RSS, Mastodon, Instagram (which I’m not mad about either, but it’s cleared my ethical bar for now…), and Discord a lot more, to replace Twitter. Four services to replace one!
- I’ve deliberately not included any links to Twitter in this article. So there are no references for the behaviour I’m accusing the new owner of. So be it. I don’t want to persuade anyone. I’ve seen enough for myself. And I don’t want to drive any traffic there; even one click is too much. A quick Google search will show plenty.
  
  If you liked this article, please consider buying me a coffee to support my writing.
14 November 2022
- opinion
What Am I Actually Selling?
I have a premium tier in Running Track. But I added it later; I first built a lot of features, intending the app for personal use only. Then when I decided to release it, I spent some time figuring out a business model, before deciding on making the core features free, and charging for some extra ones. But which extra ones?
What am I actually selling?
I settled on two main categories:
- Bonus features
- Power user features
You can use the app perfectly well without ever paying for it. I want to make sure it stays like that. The core of the app, helping you understand stats about your running, is free to use.
And then there are extra niceties you can pay for, none of which I actually have yet. Things like widgets, custom app icons, custom colour schemes, a watch app, all fall into this category. They’ll enhance the app without being fundamental. I’m planning to add all of these features after the initial launch. Some of these I would make free, or partially free, as a way of making the app more fun for everyone.
Then there are features that most people won’t need, like exporting GPX files or editing PBs. But for the people who would use those features, they’re valuable enough to pay for.
I struggled for a while with one feature. Goals are really valuable for improving your running. But they’re not niceties, or a power user feature. They’d be great for everyone. This is where the pricing model comes in.
I think Goals are a really valuable feature to have. But not fundamental to the app. So I wanted to include them in the paid tier. But how do I convince people that they’re great if they can’t use them? Free trials.
I’m going to make the paid tier a subscription. (I don’t think this is controversial any more.) But every subscription is a commitment, and I want people to be comfortable making that commitment. I don’t want people to drop after a month or year. I don’t want refund requests. So a free trial seems a great way of letting people try the subscription out.
The Running Track Run Club
I’m calling my paid subscription the Running Track Run Club. Run clubs have a real world equivalent. I like the idea that you’re paying a membership fee, rather than a subscription. And I think it’s valuable to feel like you’re part of a club, a group of runners, even if you run alone. At the moment it’s just a name, but I want to try to honour this name with some additional features that I have planned. (But not another social feed!)
It’ll cost £0.99 a month, or £9.99 for a year, with a 1 week free trial, to make sure you like it before committing any money. Figuring out prices and trial periods is hard! But I think I’ve come up with reasonable answers.
The paywall screen in the app is one last challenge that I’ve had. How do you design a screen that encourages someone to sign up? I’ll write about that another time, although I’ll say now that I have definitely spent a lot more time on that than any other part of the code.
(One last thing I liked: I’ve called the code for the paywall “Turnstile”. Really getting that old school stadium feel. I love a good project code name.)

If you liked this article, please consider buying me a coffee to support my writing.
13 November 2022
- build in public
- runningtrack
Working with the iOS Simulator
Andy Ibanez has a great resource for working with the Xcode Simulator on the command line. It includes how to use tools like taking screenshots and videos, sending push notifications, opening URLs, customising the status bar, adding media into Photos.app...
There's a huge amount you can do with the Simulator that isn't exposed in the UI. This is a really great guide.
- Link
  
  If you liked this article, please consider buying me a coffee to support my writing.
11 November 2022
- xcode
- terminal
Novel update: Science or Fiction?
One interesting part of planning my novel is figuring out how much technical accuracy to go for, as opposed to how much to just make up. It’s a story that has a scientific and even political element, it’s about climate change having a catastrophic impact on the world. But it’s also about the characters in the book, it’s a work of fiction, and there are plot points that I want to happen regardless of how realistic they are.
So I’m spending a lot of time reading articles and scientific papers. And I’m also spending a lot of time “playing” a game called The Quiet Year, which is a world building game that I’m using to set up the back story to my actual novel. Planning out the world, and working out the backstory has been a long and exciting process, and I’m enjoying figuring out how my story gets set up, how the characters and settings get into the state they end up in. I’m surprised by how much I’ve enjoyed this as opposed to getting the main story down. (It may be a procrastination technique, who knows!)

If you liked this article, please consider buying me a coffee to support my writing.
6 November 2022
- the novel
- build in public
Setting up a static site for Running Track was really easy
Yesterday I set up a static site for Running Track on my phone, in half an hour, while holding a sleeping baby. As someone who’s used to having to use Xcode for anything, this was really exciting!
I initially planned to go for the really simple option and forward the domain here, at least at first, because that’s just a case of adding a link at my domain registrar. I didn’t want anything complex for the first release; there’s plenty of time to iterate on a proper website if I find it would be valuable.
But then I discovered you can’t easily do that for .app domains. So I figured I’d set up a small 1-page site.
It was amazing how simple it was. I:
- created a GitHub repo on my phone;
- stuck some HTML in the repo, using Runestone to edit it and Working Copy to push to GitHub;
- tested it locally, on my phone, using WorldWideWeb;
- set up Cloudflare Pages to deploy the contents of the GitHub repo;
- even set up the custom domain name in Cloudflare.
All in half an hour, with one hand, on my iPhone. It’s amazing what you can do with the right apps.
Check it out at runningtrack.app. (The content is very much unfinished, I have a draft of the real page to add in at some point, probably when I’ve finished the screenshots.)

If you liked this article, please consider buying me a coffee to support my writing.
6 November 2022
- build in public
- runningtrack
Building In Public
I'm currently working on a couple of projects. An iOS app called Running Track and an as-yet untitled novel.
My Projects page has an overview of the current status of all my projects, and I’ll keep that up to date as they evolve.
Approach
Neither of the current projects are finished, and I have no timelines for them. I’m working on these for my own entertainment, and I have young children to look after, so progress is slow!
My current approach is to work on things in snatched 10-20 minute chunks, which takes a lot of planning, in order to be ready to just sit down and do something without trying to first figure out what I should be doing, and figure out where I left off.
The book is years away from being finished. The app has a clear runway to the initial release now, but I have no deadline in mind for when I expect to release it.
I’m mostly sharing this to see how it affects my motivation for the two projects. I’m usually quite secretive about things I’m doing. But I find when I don’t talk about things in public, I lose motivation once I’ve done the fun part of the work, then I feel disappointed when I haven’t shipped it. So maybe talking about things will help me to focus on finishing up and shipping something. I’ve already found it’s helped me to focus rather than constantly starting something new.
I plan to write about my progress with working on these projects here, using the tags “build in public”, “runningtrack” and “the novel”.
The App: Running Track
- Main page
Running Track is an app for tracking your running, and your progress towards goals that you set yourself. It’s as much a test bed for things that I want to use, but can’t yet use in work, like Combine, SwiftUI, that sort of thing.
The app has been shippable, essentially, for years, but I never quite got around to releasing it because it was never quite in a state I wanted anyone else to see. It’s still like that, frankly, but I’m more comfortable with the idea of iterating now, rather than shopping something perfect from the start.
I have a clearly defined MVP, and a clear path to release, so hopefully updates will come quickly. But I’ve also thought that at various points over the last few years(!) and I’m doing this for fun, so if something else fun comes up, I’m not pressuring myself to work on this.
The good news is I’m working on the marketing website, screenshots, that kind of thing. The code doesn’t need touching before I ship (which I keep reminding myself almost daily). Let’s see when I release!
The Novel
- Main page
I’m still very much in the phase of research and world-building. It’s fiction, set in the near future after an apocalyptic climate event takes place. Very 28 Days Later meets The Day After Tomorrow.
I’ve loved creative writing since I was a kid but I’ve never quite believed writing something was possible until recently. Then I figured I might as well start writing down ideas, and those turned into plots and scenes, and here I am. I have no expectations for this project, but I’m enjoying writing something which I eventually want to share with other people.

If you liked this article, please consider buying me a coffee to support my writing.
5 November 2022
Making SwiftUI Buttons with Equal Widths
I've been writing some SwiftUI recently for my run tracking app and I hit a really annoying problem.
It's really common to have two buttons, one above another, and to have those buttons be the same size. However, when I tried to do this by laying out Buttons in a VStack, they wrapped to the smallest width needed to fit the labels. That meant that every button was a different width.

I wasn't especially surprised about this. It makes sense for the default behaviour to be for the Button s to take up as much space as they need and no more. But I knew my use case was pretty common, so I went looking for ways in which I could make it work. And there are a few, it turns out. It's a common use case, but not one especially well-supported in SwiftUI...
My first ports of call were the articles on exactly this subject on Swift by Sundell and Hacking with Swift. I trust these two sources to have good solutions, and I usually find they have something that works cleanly.
Then I saw that there are all sorts of solutions to this, including using GeometryReader and even PreferenceKey! Seems a bit messy. But I knew one of the solutions would work, right?
Nope.
I tried every option and got no further forward. My Buttons were even clipping in some cases so that they lost their rounded edges. Clearly SwiftUI was trying to do something, because it seemed like the Buttons were being sized up then cut back down to their original sizes, losing the rounded edges in the process. But it wasn't doing what the articles suggested.

So I went back to Google. And I found this article by Sarun Wongpatcharapakorn. In it I found something interesting:
[W]e need to apply .frame(maxWidth: .infinity) before we apply a button style.
I'd been using that approach, setting the frame on the Button as described in the quote, then setting .fixedSize(horizontal: false, vertical: true) on the containing VStack. So this seemed relevant to my problem.
But when does the button style get applied? I wasn't explicitly applying a style, but as someone fairly new to SwiftUI I assumed that it wouldn't matter in which order I applied modifiers to my views. Turns out that was naive! And I don't understand the logic of my solution either.
Here's my first Button code, which clips the images:
```
struct PurpleButton: View {
    let buttonTitle: String
    let action: () -> Void

    var body: some View {
        Button(buttonTitle, action: action)
            .font(.system(.title3, design: .rounded))
            .padding(EdgeInsets(top: 16, leading: 32, bottom: 16, trailing: 32))
            .foregroundColor(.white)
            .background(.purple)
            .frame(maxWidth: .infinity)
            .clipShape(Capsule())
    }
}

// Preview, where I generate the images in the screenshots throughout the article.
// The `fixedSize` modifier is used in here for an example.
struct PurpleButton_Previews: PreviewProvider {
    static var previews: some View {
        VStack {
            PurpleButton(buttonTitle: "Hello I am a button", action: {})
            PurpleButton(buttonTitle: "Hello I am a button with a longer title", action: {})
            PurpleButton(buttonTitle: "Hello", action: {})
        }
        .padding()
        .fixedSize(horizontal: false, vertical: true)
    }
}
```
And here's the fixed Button: I moved the frame(maxWidth: infinity) modifier before the .background modifier gets applied.
```
struct PurpleButton: View {
    var body: some View {
        Button(buttonTitle, action: action)
            .font(.system(.title3, design: .rounded))
            .padding(EdgeInsets(top: 16, leading: 32, bottom: 16, trailing: 32))
            .foregroundColor(.white)
            .frame(maxWidth: .infinity)
            .background(.purple)
            .clipShape(Capsule())
    }
}
```
That generated what I wanted! But why?

That's still after the font and foregroundColor are applied, so which styling modifiers count towards "applying a button style"?
In the final version of the code, at the bottom of this article, I've moved the frame and padding to be set first, then the colour and style modifiers afterward, to group things more logically.
I've written this up so that I have a solution when I come to do this again, and hopefully to help anyone else who hits this same problem. But also in the hope that I can follow this up with a better explanation of why this happened! If you understand what I was doing wrong here, and why the order of the modifiers mattered in such a strange way (some styling modifiers got in the way of the layout system but others were fine?) then please let me know!
I am enjoying using SwiftUI a lot of the time, but when you hit things like this which just make no sense it really does make me question learning it.
Code Snippet
Here's the final working code for my custom Button, and a preview that shows it:
```
import SwiftUI

struct PurpleButton: View {
    let buttonTitle: String
    let action: () -> Void

    var body: some View {
        Button(buttonTitle, action: action)
            .frame(maxWidth: .infinity)
            .font(.system(.title3, design: .rounded))
            .padding(EdgeInsets(top: 16, leading: 32, bottom: 16, trailing: 32))
            .foregroundColor(.white)
            .background(.purple)
            .clipShape(Capsule())
    }
}

struct PurpleButton_Previews: PreviewProvider {
    static var previews: some View {
        VStack {
            PurpleButton(buttonTitle: "Hello I am a button", action: {})
            PurpleButton(buttonTitle: "Hello I am a button with a longer title", action: {})
            PurpleButton(buttonTitle: "Hello", action: {})
        }
        .padding()
        .fixedSize(horizontal: false, vertical: true)
    }
}
```
Update

Sean Heber explained to me on Mastodon what’s happening here. His thread explains it really well, so I won’t try to paraphrase it, other than to say that the order of modifiers matters because they don’t actually *modify* the `View`s, they create new ones…

Here’s the link to his thread. Thanks Sean!

If you liked this article, please consider buying me a coffee to support my writing.
1 November 2022
- swiftui
GitHub Action to block a PR from merging
This is really handy. If you have an open GitHub PR that you don't want to merge yet, you can use a combination of labels and GitHub Actions to block the PR from merging:
```
name: Do Not Merge

on:
  pull_request:
    types: [synchronize, opened, reopened, labeled, unlabeled]

jobs:
  do-not-merge:
    if: ${{ contains(github.event.*.labels.*.name, 'do not merge') }}
    name: Prevent Merging
    runs-on: ubuntu-latest
    steps:
      - name: Check for label
        run: |
          echo "Pull request is labeled as 'do not merge'"
          echo "This workflow fails so that the pull request cannot be merged"
          exit 1
```
Using this Action, you just apply a label containing the text "do not merge" to your PR, and the PR will be blocked until the label is removed.
(This was copied directly from Jesse Squires's article on label-based GitHub Actions. There are other cool examples of actions on his site too. This version of the Action came from Ben Asher.)
Why?
There are a few good reasons not to want to merge a PR immediately. Maybe you want feedback but know you want to make changes before merging. Maybe you're holding off on meeting a big feature because of an impending release, or because of external dependencies that aren't quite ready, such as server side functionality.
You can always just avoid pressing the Merge button. But it's easy to press accidentally. And some teams have a proactive attitude towards merging. Sometimes a label can simply be missed, in spite of best intentions.
A label alone is a good indicator that something shouldn't be merged. But having a tool to enforce this is even better.

If you liked this article, please consider buying me a coffee to support my writing.
30 May 2022
- ci

Property Wrappers in Swift

It's really easy to make a property wrapper in Swift to automatically modify a property.

Here's an example, with tests to show how it works.

`@NonEmpty` Example

Say I want to ensure an optional String can't be empty - it's either nil, or it's got a value, but that value can't be "" (because then it's got the same meaning as nil, and I don't want to have to check both values when I'm using it). I can create a @NonEmpty property wrapper which makes sure a String matches that requirement.

Usage in Code

@NonEmpty var myString = "" // gets changed to `nil`
@NonEmpty var myString = nil // keeps its value as `nil`
@NonEmpty var myString = "Killie won the Championship in 2021/22" // 🏆 - keeps its original value

The Code

@propertyWrapper public struct NonEmpty {
    public var wrappedValue: String? {
        didSet {
            wrappedValue = getNonEmptyStringOrNil(from: wrappedValue)
        }
    }

    public init(wrappedValue: String?) {
        self.wrappedValue = getNonEmptyStringOrNil(from: wrappedValue)
    }

    private func getNonEmptyStringOrNil(from inputString: String?) -> String? {
        if let inputString = inputString, !inputString.isEmpty {
            return inputString
        } else {
            return nil
        }
    }
}

The Tests

class NonEmptyPropertyWrapperTests: XCTestCase {
    func testNonEmpty_givenNilString_returnsNilString() {
        @NonEmpty var testString = nil
        XCTAssertNil(testString)
    }

    func testNonEmpty_givenEmptyString_returnsNilString() {
        @NonEmpty var testString = ""
        XCTAssertNil(testString)
    }

    func testNonEmpty_givenWhitespaceString_returnsOriginalString() {
        @NonEmpty var testString = " "
        XCTAssertEqual(testString, " ")
    }

    func testNonEmpty_givenNonEmptyString_returnsOriginalString() {
        @NonEmpty var testString = "Test"
        XCTAssertEqual(testString, "Test")
    }
}

Links

There's usually a Swift By Sundell link for anything Swift-related and this is no different. Here's a great example of how to make a @Capitalized wrapper for a String, a generic @UserDefaultsBacked wrapper, and much more info on how it works:

Property wrappers in Swift

If you liked this article, please consider buying me a coffee to support my writing.

25 May 2022

List Sections in SwiftUI
I'm aware that I'm very late to this party. But this is still really cool.
In SwiftUI, if you want to create a table view (which is actually called a List, in SwiftUI terminology) section, you can just pass in a view for the header and footer, and list the views that should be inside it. In UIKit, this is multiple lines of calls to the UITableViewDelegate. In SwiftUI, it's all just a handful of lines of code!
```
List {
	Section(header: Text("My Section").bold(), footer: Text("Footer information about my section")) {
		Text("Row 1")
		Text("Row 2")
		Text("Row 3")
	}
}
```
If you liked this article, please consider buying me a coffee to support my writing.
22 April 2022
- swiftui
Cloning Only Part of Your Git Repo
The iOS project that I work on is a few years old and has over 14,000 commits in its commit history. That's a lot of code. The step in our Bitrise workflow that clones the repo takes around 2-3 minutes to clone all of it. But I recently discovered that it doesn't need to. Git supports something called "shallow clones", which let us only clone the part of the repo that we actually need.
How Bitrise Lets Us Use Shallow Clones
By setting the clone_depth in the git-clone step (see the Bitrise docs here), you can tell Bitrise to only check out a certain number of commits.
For example, we have a workflow that runs our UI tests nightly. It only needs the current commit to run those tests, it needs no history. By setting the clone_depth to 1, we can avoid cloning the unnecessary history and save around 2 minutes on average.
I recently added a load of scripts to help us automate our release process. These scripts do various things on the latest commit on our main branch, and we run them with Bitrise workflows. The longest step by far in most of these workflows is git-clone, since they usually don't actually build the app. As they only need the current commit, they can also be sped up quite considerably by not cloning the whole repo, cutting them down from over 4 minutes on average to under 2 minutes.
Shallow and Partial Clones
This isn't just a Bitrise thing though, it's part of git itself. The clone_depth property tells the git-clone Bitrise step to use a "shallow clone". This means that if you give a depth of 1, it only checks out the latest commit and completely ignores anything else.
Here's an interesting read from Derrick Stolee at GitHub, comparing blobless, treeless and shallow clones: Get up to speed with partial clone and shallow clone. (Don't worry, he explains what those three types of clones mean really well.)
And if you want to RTFM, here's the git documentation for shallow clones and partial clones.

If you liked this article, please consider buying me a coffee to support my writing.
7 April 2022
- ci
- git
Preparing for future minimum OS versions
Let's say you have an app that supports iOS 13 and above. There will be some code that you can't use until iOS 14 is your minimum supported version. For example, using UIActions with UIButton is only available on iOS 14 and up; in iOS 13 you need to use the old target/action approach.
To handle this, you might have alternative paths in your code. For example:
```
if #available(iOS 14.0, *) {
    let button = UIButton(primaryAction: { _ in buttonPressed() })
} else {
    let button = UIButton(type: .sytem)
    button.addTarget(self, action: #selector(buttonPressed), for: .touchUpInside)
}
```
When you update to using iOS 14 as your minimum OS version, you can delete the code in the else block, and delete the version check.
Marking your own code as deprecated
Writing code for the old and the new API can become complicated. Sometimes, it's just better to only use the old API, until your minimum OS version goes up.
When you update your minimum version, you often get warnings from Apple's APIs stating that code has been deprecated. You can use the same approach, to remind yourself that you can use the new API now.
To get a warning when you update the minimum OS version, you can add the @available annotation to your property, method or type:
```
@available(iOS, deprecated: 14.0, message: "Replace this method with the new UIAction API.")
func createAButtonUsingTargetAction() -> UIButton {
    let button = UIButton(type: .sytem)
	button.addTarget(self, action: #selector(buttonPressed), for: .touchUpInside)
	return button
}
```
This creates a warning when you compile with iOS 14 as your minimum OS version. That means you get a reminder to go back and update the old code, now that you can use the new API instead.

If you liked this article, please consider buying me a coffee to support my writing.
16 March 2022
- swift
Setting Up A New Mac With Dotfiles
I got a new laptop for work recently. I used to enjoy setting up a new computer, but as I get more and more into customising and automating and scripting etc, I find it harder and harder to get the thing back to the way I like it.
A few years ago I half-heartedly made a "dotfiles" repo. So named because it is a repo containing all those config files that start with a ., like .gitconfig, .zshrc etc. I forgot about it until recently, and realised when I rediscovered it that this is exactly what I want.
You can find my dotfiles repo here.
I can store all the config I have tweaked over the years, without having to jump between computers to figure out what's different. I've modernised the dotfiles themselves a lot (e.g. moving from bash to zsh), and updated the install script so that with one command I can install a load of dependencies.
The Brewfile is a particularly cool part of this. You can install Homebrew packages, applications and even Mac App Store apps through this one file.
So now, running a single script installs my settings, and gives me Homebrew, Oh My ZSH, Xcode command line tools, and a load of applications.
This goes along with my recent XcodeTheme repo. I'm always looking for ways to avoid repeating work, even if it's something I only have to do every few years!
There's also a cool dotfiles site on GitHub that I'm going to be using to tweak my scripts even more. I think there's a lot more that I can do to make setting up a new machine a nice one-step process. Feel free to share any ideas you have too!

If you liked this article, please consider buying me a coffee to support my writing.
7 February 2022
- terminal
- automation
Installing Xcode Themes
I use a customised version of Panic's palette as my Xcode theme. This was originally shared by the company as a tweet a few years ago and I've used it ever since. I love the colour scheme.
Every time I get a new Mac, I install it, then modify it very slightly to my preferences. I figured I'd save myself the trouble of hunting down that tweet every time, and changing fonts, and just store my local file in a git repo. You can find it here.
I've set it up to be easy to add new themes to the repo, using the theme/ directory, although I've only got the Panic Palette theme in there just now.
I've also written a simple install script, which just creates the FontAndColorThemes/ directory in ~/Library/Developer/Xcode/UserData/ if required, and then copies the theme file(s) from theme/ to it.
It's easy to fork if you want to use this too, just add your own theme files to the theme/ directory.

If you liked this article, please consider buying me a coffee to support my writing.
4 February 2022
- xcode
- automation
SwiftUI State Links
I've been playing around with SwiftUI recently. It's been fun to learn in many ways, but managing state is one of the more confusing aspects of it.
There are many property wrappers for managing state in SwiftUI. When do you use @State, @ObservedObject, @EnvironmentObject etc?
Here are a few links to blog posts that can explain it pretty well:
- The obligatory Swift By Sundell post.
- The obligatory Hacking With Swift post.
- This article from Jared Sinclair is another cool guide.
  
  If you liked this article, please consider buying me a coffee to support my writing.
25 January 2022
- swiftui

A Small Improvement To UIView and UIStackView

I write a lot of UI code in UIKit, and in particular in code rather than using Interface Builder.

Quite often I'll want to add multiple subviews to a UIView, or multiple arranged subviews to a UIStackView. And I end up with code like this:

view.addSubview(subview1)
view.addSubview(subview2)
view.addSubview(subview3)

stackView.addArrangedSubview(subview1)
stackView.addArrangedSubview(subview2)
stackView.addArrangedSubview(subview3)
stackView.addArrangedSubview(subview4)
stackView.addArrangedSubview(subview5)

Which isn't amazing to read. It's a lot of duplication, and makes it slower to create new views. I almost always end up writing these extensions:

extension UIView {
    func addSubviews(_ subviews: [UIView]) {
        for view in subviews {
            addSubview(view)
        }
    }

    func addSubviews(_ subviews: UIView...) {
        for view in subviews {
            addSubview(view)
        }
    }
}

extension UIStackView {
    func addArrangedSubviews(_ subviews: [UIView]) {
        for view in subviews {
            addArrangedSubview(view)
        }
    }

    func addArrangedSubviews(_ subviews: UIView...) {
        for view in subviews {
            addArrangedSubview(view)
        }
    }
}

I create both versions because sometimes you can have an array of subviews to add, so it's nice to be able to just call view.addSubviews(myArrayOfViews). But usually I have a scenario like the one above, so I can use the variadic function and replace the 8 lines of code with these 2:

view.addSubviews(subview1, subview2, subview3)

stackView.addArrangedSubviews(subview1, subview2, subview3, subview4, subview5)

If you liked this article, please consider buying me a coffee to support my writing.

11 January 2022

Search Your Terminal History
Ctrl-R is one of my favourite terminal commands. Type it, and you can search the history of commands you've typed without having to remember the command.
For example, I often use it with git. I can never remember the command to force-push a branch after rebasing, but I know it contains the word "force". So I type Ctrl-R, the "force", and it brings up the command I want: git push --force-with-lease.
Note that I didn't have to type "git"; you can search for any part of the command that you remember, even something in the middle, and the whole command will be suggested. And if you don't want the first result, you can keep pressing Ctrl-R to cycle through the search results. When you find the command you want, just type Enter to run it.

If you liked this article, please consider buying me a coffee to support my writing.
8 January 2022
- terminal
Tags As An Organisation Method
I think tags are simultaneously the best and worst organisation method for my brain. If I have a clearly defined, and limited, set of possible tags, then it's great for organising related things, and being able to have multiple tags is useful for things that really do belong in multiple places at once. But if I have an unlimited set of tags, it's basically impossible to keep things organised.
I used to use Bear for notes. It uses tags instead of folders. And I frequently found myself having multiple tags on things for no reasons. I was basically just adding any keyword I could think of, but I was classifying it at the time. It was useless for search, and I ended up with a ridiculously long sidebar that had lots of duplication. It just made the "organisation system" way to heavy to actually help me organise things. Since I switched over to using Apple Notes instead, I've found my notes are much easier to organise.
Another example is in banking apps. Monzo lets you set categories for transactions. There is a limited set of categories you can choose from, and they are all pretty clearly distinct from each other. I use it to keep track of how I'm spending money, and I never find myself wondering which tag I should choose, or wishing another tag existed. It's a great, and helpfully limited, set.
Tags On This Site
Which brings me to this site. The template that I used from Publish had tags enabled for the post previews. (You'll see them on my homepage, in the list of blog articles.) And I started off writing random tags, which ended up being pretty unhelpful. The idea is great; you click a tag, and can browse all articles on that topic. But if I have one article tagged "tests" and the other tagged "testing" then you don't get all relevant articles under one tag. And that's really easy to do with an unlimited set of tags!
I've tweaked my current posts and come up with the following set: - uikit - ux - localisation - tests - engineering - opinion - meta
I'll definitely refine these over time, as I get a larger data set to work with, because some only have one article and the tag might not make sense soon enough. And I'll certainly add more tags, as I write about more topics. But they'll always be listed on the tags page of the site, to make it easy to browse the topics I've written about. And I'll be holding myself to the artificial constraint of only introducing a new tag if the article doesn't fit into any existing ones.
If you have a nice way of managing tags, let me know! They're very popular, I just can't make them work for me without introducing artificial constraints.

If you liked this article, please consider buying me a coffee to support my writing.
7 January 2022
- meta
- opinion
Checking If A UI Test Is Running
When you write a UI test, you will often find you need to get the app into the right state to perform the test.
For example, you may have an onboarding flow that always runs on the first use after installing, but you want to test a different part of the app. You don't want to have to go through the onboarding flow every time you run an unrelated UI test flow. So you would want to skip this onboarding flow in your UI test, and focus on the specific flow that you're testing.
Your app probably has some logic like this already, to handle when this optional flow is shown:
```
if firstRun {
    showOnboardingFlow()
}
```
Are You Running Under UI Test Conditions?
When you start running your UI tests, you'll use UIApplication to launch the app. You can set its launchEnvironment to indicate UI tests:
```
let application = XCUIApplication()
application.launchEnvironment = ["UITests": "true"]
```
Then you can check the value:
```
let isUITesting = ProcessInfo.processInfo.environment["UITests"] == "true"
```
launchEnvironment is a dictionary of type [String: String], so the value doesn't have to be "true", it could be anything. So you can just check that some value is present for that key:
```
let isUITesting = ProcessInfo.processInfo.environment["UITests"] != nil
```
The key thing is not to set anything for "UITests" in this case when running normally!
Using This In Your App
To make sure you don't show your onboarding flow in UI tests, you can now add this value to your condition:
```
if firstRun && !isUITesting {
    showOnboardingFlow()
}
```
If you liked this article, please consider buying me a coffee to support my writing.
6 January 2022
- tests
Mock Data and Dates
If you're going to use mock data when building your app, for example to mock API responses, make sure that the data you use will stand the test of time.
If you use a date that you expect will always be in the future, and it's only set to be a year or two in the future, it'll come back to bite you in just enough time for you to have completely forgotten about it.
I experienced this in work this week. When the year changed to 2022 a few days ago, we suddenly had tests start failing on us. We had some mock data that was set to 2021-12-31, but our app expected that date to be in the future. And the logic that relied on this was just convoluted enough to obscure the problem (a separate problem but one no less bad). So it took a while to diagnose an issue that should never have come up.
Set your dummy dates well into the future. I changed this one to be 1000 years in the future, which will only be a problem for me if we figure out that Futurama head-in-a-jar technology before I die.

If you liked this article, please consider buying me a coffee to support my writing.
5 January 2022
- tests
Accessing Views In UI Tests Using `accessibilityIdentifier`
When you're writing a UI test, you often want to check that a view is on-screen. If it's a label or a button, you can access it using the text of that label or button. But if that text is long, dynamic, or if you're using some other view, setting an accessibilityIdentifier to look up is usually a better approach.
Set the property on whichever view you want to access. In this example it's a UITextField but this works for any UIView:
```
textField.accessibilityIdentifier = "myTextField"
```
Then in the UI test you can look up the view by that identifier:
```
let textField = app.textFields["myTextField"]
textField.tap() // do whatever you need to now
```
accessibilityIdentifier is only used in code, it's not presented to the user of your app, even in VoiceOver. So it's safe to use for your tests without worrying about how a user might experience it.
References
Paul Hudson has written a great cheat sheet for UI testing your iOS app. There are loads of tips like this one in the brilliant Hacking With Swift article.
Apple’s documentation for accessibilityIdentifier can be found here, and interestingly, explicitly calls out using it for automation.

If you liked this article, please consider buying me a coffee to support my writing.
4 January 2022
- tests
How I Build This Website
Over the last year or so I've found myself using my phone far more often than my iPad or Mac. For a while this was mainly for the inevitable Twitter doomscrolling. But I wanted to move away from that. As well as improving what I was reading, I wanted to write things that are more thoughtful than tweets. I already had this site, and I realised I had the chance to play with some mobile apps that could help me to publish posts from my phone.
I use GitHub to store the source code for this website. After some research into how I could use my phone to write for the site, I realised I could also experiment with GitHub Actions, a newish (well, from 2018) CI option available in GitHub that I hadn’t really looked at yet, to deploy it.
Apps
I often start by jotting down random ideas in Apple Notes, but I start writing the actual posts in Markdown using Obsidian. I really like it because it keeps the writing process really simple. It's just great for writing Markdown, and I like that it shows me the raw file rather than trying to make it look nice with auto-formatting. While I keep most of my personal notes in Apple Notes, I really like Obsidian for writing.
Once an article is ready to be published, I upload it using the Shortcuts app. I have a nice shortcut that lets me share an article from Obsidian, add the metadata that my site needs to render the article preview, and pushes it to the project's repo on GitHub.
I have the website's git repo stored locally in Working Copy. Working Copy is a good enough git client. It has great support for Shortcuts, but the UI is a bit muddy for my liking. I’d rather have a command line interface for git, but in the absence of that on iOS, I'd prefer a GUI that was less awkward to navigate. Fork, Tower and GitHub Desktop, for example, are all good desktop git clients, and for my liking, Working Copy doesn't match up. But it's the best I've found and it does work.
Publish
The site is built on Publish, John Sundell’s static website builder. It uses Swift and Markdown to generate the site. Now that I have the template for the site set up, I never touch any traditional web language like HTML or JavaScript for this site. (My only complaint is that it doesn't support Markdown footnotes. Paradoxically, this comment would have been better as a footnote. But if it was possible, this comment wouldn't exist.)
GitHub Actions
I use two repos on GitHub to publish the site. The main one stores the source code for the project, and the other stores the generated output - the actual static website code. But I never touch the output repo directly. When I want to post something, I write the Markdown file in Obsidian, and push it to the main project, using Shortcuts. When I push to a particular branch, a GitHub Action is triggered that uses Publish’s deploy mechanism to build the site, and pushes that code to the second git repo. The Shortcut that I use is configured to push to that branch by default.
Digital Ocean Apps
The final step is getting the static site from the second git repo onto a webserver somewhere. I was previously hosting it on a Digital Ocean droplet, and I had thought to write a script to pull updated code from my output repo and deploy it for me. Luckily, Digital Ocean Apps launched a little while ago, which saves me all of that trouble.
For a static site like this one, Digital Ocean Apps is incredibly useful. I just connected Digital Ocean with my GitHub account, and was given a drop down list of my repositories. I chose the site output repo, and it was recognised as a static site. Digital Ocean did all the work of setting up the server, I just had to set up a CNAME record on my DNS server to be able to use my domain.
The Full Flow
1. Write the article as a Markdown file in Obsidian.
2. Run a Shortcut to save that Markdown file in my site's main git repo, and push it to GitHub, using Working Copy.
3. Run a GitHub Action to recompile my static website whenever the main repo is updated, and push that compiled website to the output repo.
4. Digital Ocean Apps updates my site whenever the output repo is updated.
What’s Missing
So I can now write for my website, build it, and deploy it, using my iPhone. What I can’t do yet is run a local webserver to test it before deploying, and this is the main reason why I still only use my Mac for bigger changes to the site, like structural changes or CSS changes. If you have any tips for running a local webserver on an iPhone, or working around that somehow, let me know!
Appendix
These should have been footnotes, but Publish doesn't support them. I briefly considered replacing Publish, but that would render this post pointless as I'd need to completely change my process for publishing this site, and footnotes aren't that important to me!
A(nother) Problem With Publish
One undocumented part of the process of generating a site with Publish is the generate step itself. This, as you can tell from the name, takes the Swift and Markdown code and generates the HTML website. When you run Publish run locally to test the site, the generate step runs implicitly, before it’s deployed to a local webserver. And of course, when I was doing this all on my Mac, I would run locally before deploying, so I never came across this issue. So when I only ran the deploy stage in my GitHub Action, I ended up with an empty output repository because nothing was being compiled. Not ideal! Simply running the generate step before the deploy step fixed things though.
A Problem With GitHub Actions
Pushing the compiled code to my second, output, repo, wasn’t quite as simple as I'd hoped it would be. Connecting my GitHub Action up to the output repo required generating a deploy key for the output repo, since the push isn’t happening on a server with my ssh key. Given the GitHub Action is running under my GitHub user, and moving code between two of my GitHub repositories, it was a bit surprising that I had to generate a deploy key, but once that was set up it worked with no more issues.

If you liked this article, please consider buying me a coffee to support my writing.
3 January 2022
- meta
UITableView backgroundView as an Empty State
If you have a UITableViewController which can be empty, it's helpful to have some kind of empty state, rather than just an empty screen.
For example, if you have a to-do list app that's got no tasks, you might have a message telling the user that the list is empty. You could even have a button that allows them to create a task.
You can create an empty state with UITableView's backgroundView property, which can be any UIView.
For example, I have this line in my run tracking app:
```
tableView.backgroundView = runs.isEmpty ? NoRunsErrorView() : nil
```
It's expected that someone using the app would have at least one run in the list (otherwise why use a run tracking app?). So if they don't, I consider it to be an error state, and I have a custom view that I show in that case, with a prompt to check that the app has been granted the right HealthKit permissions.

If you liked this article, please consider buying me a coffee to support my writing.
3 January 2022
- uikit
- ux
The 2020 Mac mini
The new Mac mini with the Apple M1 chip is an incredible machine to use. It’s also finally hit the minimum standard we should expect from computing devices.
It just does what you ask, and is the first traditional computer to do so. This is one of the features that made the iPhone so impressive from the start, back in 2007; it’s immediately responsive to your actions. It feels great, then almost immediately it feels normal, and makes everything else feel slow instead.
For example, apps launch straight away. It shouldn’t be remarkable that the user in the linked video can just keep opening apps without it being an issue, but it is.
I like to edit photos in Lightroom. On the iPad, that’s always been a fairly smooth experience: I adjust a slider, and the image on screen changes as I slide it. On the Mac, that was never the case. I’d always be waiting for the image on screen to catch up with my changes. Until now, because on my Mac mini with the M1 chip, performance is just as snappy as it is on my 2016 iPad Pro.
On the one hand, that feels like a low bar. Seriously, the Mac has finally caught up with an iPad from 2016? I’m comparing it’s responsiveness to the 2007 iPhone?! But on the other hand, it’s a massive change. My top of the line, 16” MacBook Pro from 2020 couldn’t perform like this. One thing that people have always loved about iOS is how smooth it is, how natural it feels to use. You ask it to do something, and it does it. That’s been a problem with PCs for decades. And now it’s not.
This is the baseline now; the minimum standard that we should ask of our computers. It should, to use an overused phrase, just work.

If you liked this article, please consider buying me a coffee to support my writing.
2 December 2020
- opinion
Built-in Localisation in iOS
This is a fairly small thing, but really handy if you need it.
Localisation (in this case, translating your UI into another language, although localisation can also apply to things like changing layouts or images to suit a particular country) can add some overhead to your development process. You need to set your app up to use NSLocalizedStrings in the UI; you need to send those strings to someone who actually knows the language you're translating into; you need to test your changes in all supported languages to make sure the translation worked correctly, and makes sense in the context of the UI. (For more detail on how to localise strings, see this handy article on Hacking With Swift.)
There are little things baked into iOS which can help with this a little. One is UIBarButtonItem, which has an initialiser that takes a UIBarButtonItem.SystemItem parameter, which will let you specify the type of button without having to think about the actual text. For example, .done will use a translation of the word "Done" which is baked in. This means you get it with no extra effort, and it's also consistent across apps.
Another great example is in Locale. Locale has various methods whose name start with localizedString, for example localizedString(forRegionCode:). You can use this to get a translation of a country name. To see for yourself, paste this code into a new Playground:
```
func localisedName(for regionCode: String, using locale: Locale = Locale.current) -> String? {
    return locale.localizedString(forRegionCode: regionCode)
}

print(localisedName(for: "us") ?? "unknown country") // "United States"

print(localisedName(for: "fr", using: Locale(identifier: "de")) ?? "unknown country") "Frankreich"
```
So long as you know the region code for a given country, you can translate its name into the correct name for the system's current locale, or any other of your choice. And Locale even provides a list of all region codes: Locale.isoRegionCodes (although documentation is lacking; try printing it in a Playground). Wikipedia has a handy list of these ISO3166-2 codes, mapped to their English names.

If you liked this article, please consider buying me a coffee to support my writing.
10 July 2020
- localisation
The Importance of Taking Breaks
I just added interval splits to Running Track, and vastly improved the map view too. I started working on both several months ago, but after struggling to get them working how I wanted, I got frustrated and left them alone for a long time. Yesterday, I decided to go back and look again, and both were done in a matter of hours.
Splits, in particular, were awkward to calculate. However, a couple of weeks ago I added logic to calculate your best time for a given distance. After spending time working with lower-level run sample data, it became really easy to see how I could use a similar approach to break a run up into chunks and calculate split times.
The run map has been bothering me since I first started working on it, over a year ago, as the scaling on it was terrible. Back then, I found it really awkward to find a nice way to translate the coordinates of a run into something that MapKit could use to present the route. So the route was tiny in the middle of the map, and you had to zoom to be able to get any value from it. But when I went back to the problem, it felt like the solution was staring me in the face. And again, it was work I'd done in another area that just helped to clarify my thinking.
It’s funny how easy the things that feel difficult can turn out to be, when you just take a break from the problem and go back to them. It's important to recognise when you're hitting a wall with a problem, and to go and find something else to work on instead, or even something completely different to do. Sometimes you'll learn something new that makes the original problem much simpler. Sometimes you'll just see something from a different perspective, because you've stopped focusing so intently on one part of the issue. Most of my problem-solving happens when I'm running or cleaning, because my mind is in a completely different place, then it drifts back to what's been bothering me.
PS: A bonus fix yesterday (I had one of those really productive days that probably comes along once a month) was getting heart rate calculations down from 10 seconds to 0.1 seconds, because I was needlessly sorting them. I only thought to check the query because I accidentally introduced a similar problem elsewhere in the app, realised what it was straight away, and wondered where else I'd made the same mistake. I’d previously just accepted that querying heart rate data was slow. As well as a good example of how answers can come to you when you're not actively looking for them, it's also a good lesson to keep questioning things that you aren't happy with.

If you liked this article, please consider buying me a coffee to support my writing.
19 May 2020
- engineering
Dequeuing Custom UITableViewCells and UICollectionViewCells
When you want to use a UITableViewCell or UICollectionViewCell subclass, you need to go through a few boilerplate steps to register and dequeue it.
Usually in an initialiser or in the containing UIViewController's viewDidLoad method, you register a UITableViewCell or UICollectionViewCell subclass that can be dequeued with a unique identifier String:
```
tableView.register(MyCustomCell.self, forCellReuseIdentifier: "cell")
```
Then, you implement a UITableViewDataSource or UICollectionViewDataSource which contains the cellForRowAtIndexPath or cellForItemAtIndexPath method. In this method, you ask the table or collection view to dequeue the reusable cell that can be used for the current item in the data source, based on its reuseIdentifier:
```
let cell = tableView.dequeueReusableCell(withIdentifier: "cell", for: indexPath) as! MyCustomCell
```
The Problems
Using the Reuse Identifier in multiple places
You have to specify the reuse identifier twice - once when registering and once when dequeuing. But you could accidentally mismatch cell types and reuse identifiers, or make a spelling error in one place which means the correct cell doesn't get dequeued, or forget to update the dequeue call after changing the reuse identifier in the register call. (This can be mitigated by declaring a constant for each reuse identifier, but if you have multiple cell types, it can become a bit of a list.)
Casting
The bigger issue is that the cell that you're given back when dequeuing is of the base class type, UITableViewCell or UICollectionViewCell, and you have to cast that to the custom type that you explicitly registered.
So you then get the choice of using an optional cast with as?, and adding some handling for dealing with optionals, or force casting to your custom type using as!, as shown in the example above, and letting the app crash if it gets the wrong type back.
This shouldn't cause any problems if you do everything perfectly all the time, but if you changed the cell type for that reuse identifier when dequeuing, and forgot to change the cast after registering, your app will either show a broken UI, or crash, just because the type of cell needs to be declared in two separate places.
The whole approach is messy. Reuse identifiers aren't something we typically need to care much about - it's usually more of an implementation detail of the UITableView/UICollectionView. And considering we explicitly told the UICollectionView or UITableView what cell type to expect for a given reuse identifier, we should be able to use that cell type implicitly, rather than casting after dequeuing.
Here's how you can do that.
The ReusableView protocol
If we make all of our custom UITableViewCell and UICollectionViewCell subclasses conform to the ReusableView protocol below, they will have a property called defaultReuseIdentifier which can be used as the reuse identifier without having to name it explicitly.
```
public protocol ReusableView: class {
    static var defaultReuseIdentifier: String { get }
}

public extension ReusableView where Self: UIView {
    static var defaultReuseIdentifier: String {
        return NSStringFromClass(self)
    }
}
```
That means you can avoid copy/paste errors, and don't have to think about what value to give to your reuse identifier. You get a reuse identifier for free, using the class name. But it works even better with some extensions.
UITableView/UICollectionView extensions
These extensions add a generic method to UITableView and UICollectionView called dequeue, which lets you dequeue a cell without having to explicitly register it, or having to cast it to your custom type.
```
public extension UITableView {
    func register<T: UITableViewCell>(_: T.Type) where T: ReusableView {
        register(T.self, forCellReuseIdentifier: T.defaultReuseIdentifier)
    }

    func dequeue<T: UITableViewCell>(for indexPath: IndexPath) -> T where T: ReusableView {
        register(T.self) // this removes the need to explicitly register a cell
        guard let cell = dequeueReusableCell(withIdentifier: T.defaultReuseIdentifier, for: indexPath) as? T else {
            preconditionFailure("Could not dequeue cell with identifier: \(T.defaultReuseIdentifier)")
        }

        return cell
    }
}

public extension UICollectionView {

    func register<T: UICollectionViewCell>(_: T.Type) where T: ReusableView {
        register(T.self, forCellWithReuseIdentifier: T.defaultReuseIdentifier)
    }

    func dequeue<T: UICollectionViewCell>(for indexPath: IndexPath) -> T where T: ReusableView {
        register(T.self) // this removes the need to explicitly register a cell
        guard let cell = dequeueReusableCell(withReuseIdentifier: T.defaultReuseIdentifier, for: indexPath) as? T else {
            preconditionFailure("Could not dequeue cell with identifier: \(T.defaultReuseIdentifier)")
        }

        return cell
    }
}
```
Using the register method, it will register cells with the default reuseIdentifier from ReusableView. It will then handle casting, throwing a preconditionFailure if the cast fails. But it shouldn't, because registering the cell for reuse happens at the same time as dequeuing a cell of that type.
Registering and Dequeuing Now
Conform your UITableViewCell or UICollectionViewCell to ReusableView:
```
class MyCustomCell: UITableViewCell, ReusableView {
    // your cell implementation
}
```
And declare the expected cell type when you dequeue your cell:
```
let cell: MyCustomCell = tableView.dequeue(for: indexPath)
```
That's it. You never need to specify a reuse identifier, you don't need to register your cell for reuse, and you don't need to deal with casting.
The Code
I wrote this into a Swift package on GitHub, called ReusableCells. It uses just three small files to do the above, so if you don't use Swift Package Manager, it's really easy to copy the code in yourself.

If you liked this article, please consider buying me a coffee to support my writing.
1 February 2020
- uikit
Child View Controllers
If you’re finding your UIViewControllers are getting large and unmanageable, and have too many responsibilities, splitting them out into Child UIViewControllers is a great way to go.
If you’re not sure how to do that, I find these resources really useful:
- Container View Controllers on Use Your Loaf, if you prefer using Storyboards.
- Child View Controllers on Swift By Sundell, if you write your views in code.
- And of course, the obligatory link to Hacking With Swift's article on the topic.
  
  If you liked this article, please consider buying me a coffee to support my writing.
1 February 2020
- uikit

Blog

Main Home Screen

Dock

Widget Changes

App Changes

Fitness Apps

Night Focus Home Screen

Watch Faces

Daytime

Night

Atuin

Starship

fzf

grep

Oh My Zsh and its git plugin

Secure Shellfish

Threads 🧵

Mastodon 🐘

Bluesky 🦋

Roundup 🥇

Reading

Gaming

tl;dr

One Particular Example Where I Use git reflog

Restoring A Dropped Commit

Aside

Reference

Resources

Find out more about Switch Control

The @Test Attribute

Expectations

Traits

Tags

Parameterised Tests

Test Suites

Wrap Up

What Is It?

FAQ

You Can't Do It All

Remember You May Not Be Able To Use This For A While

Set Aside Dedicated Time

Write Code

Share Your Excitement

Apps

Locked the Garden Gate

Main Home Screen

Widget Changes

App Changes

General Usage

Night Focus Home Screen

My challenges for 2023

My daily challenges

Overall

Faster Merges

More Coding, Less Waiting

Better Quality Reviews

Easier To Fix Or Revert

PR Tips

Review Your Own PR

Keep Titles Concise

Make Descriptions Descriptive

But Seriously, Review Your Own PRs

Search Results

Aside: I've slightly changed the example from Apple's docs

Widgets

Apps

Dock

Watch

The Phantom Menace is a 4 star movie

Alternatives

Owning the content

Owning the appearance

Owning my own projects

Owning my own vanity

Related reading:

New goal type

UI cleanup

Code cleanup

Bugs

Getting there

One Particular Example Where I Use `git reflog`