Gitonium: The first six weeks

Six weeks ago, I decided to stop thinking about doing side projects and instead commit to finishing one. I’ve said this before, but primarily just to myself.

Bart Simpson on the whiteboard, writing he must finish his side projects. Telling it to the world is an entirely different matter. I decided to announce it publicly: I’m making an app! 🎉

I must finish one side project before starting another

A little while after having kids, I mostly stopped doing side projects and stopped posting on Twitter. Renovating a house, taking care of children, plus a full-time job will eat up most of your time. I didn’t have the surplus energy for much more.

I’ve been an iOS developer for ten years now, and before that, I worked for years on a desktop app. Nowadays, I mainly help teammates fix issues, interview developers, plan stuff, deal with releases or Continuous Integration problems, deal with app reviewers, or solve complex merge conflicts—very little of what I characterize as “creative” work.

I have wanted to start a side project for a long time. Preferably an app I could use myself. I’m no business- or marketing genius, and I’ve read my fair share of stories about indie apps with zero users, so by building something for myself, I’ll make sure it gets at least one user: me.

I’ve long been thinking about what kind of app I should build, and I want to make a desktop app again. There is one thing that I have had a constant relationship with, pretty much since day one as a developer, and that is version control. More specifically: Git.

As a consequence of my job, I’ve become quite the Git power user over the years, and one of its most painful experiences is merging branches and dealing with merge conflicts. I do this all the time, and I have a lot to say about how merging could be made more accessible. I feel that I can add serious value here, so this is where I decided to focus my efforts.

This is Git
xkcd: This is Git

Before I can start solving those problems, I need to build many components. I need code that speaks to the Git repository. I need views to display changes and diffs. I need to show code changes over time and reveal similarities, patterns, and repetitions. At first, I’ll use these components to build a simple Git client, and after that, I will take on improving the merge process.

It’ll be worth all the effort if this app can cut my average merge time in half at work. I think it will reduce it far more.

I am returning to my roots by making a desktop app for the Mac again. It will be fun, it will be mine, and no product manager shall come near it!

I’m journalling daily on this project. I’m also documenting everything and posting regular status updates on Twitter.

The beginning

I began by announcing the name: Gitonium. I mostly picked that name because it starts with Git and the dot com domain was available.

I have this quirk where I don’t feel like an app project is serious unless it has a proper icon, so I drew a beta version, inspired by the “Launched”-style of Charlie Chapman. I will need to make the release version later, but I feel like this sets the right tone for now.

Next, I decided to build with SwiftUI because that excites me. So-called experts keep talking about the importance of finding product/market fit, but right now, I’m not worrying too much about that; there are tons of other Git apps. What concerns me more is product/founder fit. If I’m going to stand a chance of finishing this project and shipping this app, then I have to create systems to fit this project around myself and my lifestyle so that I’ll want to spend the evenings and the weekends working on it. The work has to feel like play.

Another thing I’m doing that perhaps goes against what people recommend is that I am not cutting corners to get to an MVP as fast as possible. This project will succeed because my only definition of failure would be if I ended up not using the app. I’m building this, slowly and meticulously, with as many unit tests as practical. To stay creative, I have to avoid getting bogged down with bugs and technical debt. I have to remain as much as possible in the creative zone to be happy. It shouldn’t be too complicated or take long to fix a bug. Problem domains must be self-contained and small enough that I can work on each in isolation, unfazed by any noise from kids and family in the background.

I decided to build Gitonium using The Composable Architecture because I wanted to explore building apps in this way and because it works well with SwiftUI. I’m following their principle of hyper-modularization, using Swift Package Manager to enforce separation of concerns. At the time of writing, I am up to thirteen modules!

So, what’s the current status? In general, I’m thrilled with how far I’ve gotten.

This is what Gitonium looked like on April 22nd, using just dummy data: (very) Early Gitonium Screenshot

And here’s what it looks like a month later with real data: (very) Early Gitonium Screenshot

I’ve spent the last weeks of May working on my Diff component. It’s central to everything I plan to do, so I have to get it right. So far, it has been the most challenging part of the project, but that was as expected. Last night, I finished the final pieces of the code for coloring changed lines, so I am now ready to start on the second part of the app. The first part was displaying branches, commits, and diffs. The second part is the interface and functionality to perform a commit. I do not doubt that this will prove just as challenging as the first part, but the good news is I am having so much fun with this!

Thank you so much for reading and following along! ❤️

Until next time!


Want more like this?

Sign up to receive more posts like this right in your inbox as soon as I write them.