From Tinkering With Macs to Building My Own Apps

If you've been reading The Apple Geek for any length of time, you'll know that I've always enjoyed tinkering with technology. Whether that's breathing new life into an old Mac, experimenting with different operating systems, finding new uses for ageing hardware or getting something working that wasn't necessarily designed to work in the first place, I've always been interested in what technology can do rather than simply how new or expensive it is.

Over the years, that curiosity has led me down some fairly interesting rabbit holes. Some projects have been simple fixes, others have turned into considerably larger undertakings than originally intended. However, somewhere along the way, I've gone from primarily writing about Apple products and experimenting with other people's software to actually developing applications of my own. And not just one application, either. Apparently, I don't know when to stop.

It Usually Starts With a Problem

Looking back, there's a fairly obvious pattern to most of my projects. I'll be doing something perfectly normal, encounter a minor inconvenience and start wondering whether there's a better way of doing it. Sometimes an existing application does exactly what I need, and that's the end of the story. Other times, the available solutions are either unnecessarily complicated, missing something important or simply don't fit the way I want to work.

That's usually when I start thinking about building something myself. It's an innocent enough idea, but one that generally leads to Xcode, Swift, several cups of coffee and an unreasonable number of evenings trying to understand why something that worked perfectly yesterday has suddenly stopped working today. What I've discovered is that the initial idea is often the easy part. Turning it into something reliable, useful and pleasant to use is where the real work begins.

Interestingly, none of the four applications I've been working on started with some grand business plan. They all came from problems I'd encountered personally, usually while doing something completely unrelated to software development. Golf, coaching, padel and classic cars might not sound like particularly connected interests, but they've all provided inspiration for projects that have gradually taken over a surprising amount of my spare time.

ForeThought and the Golf Rabbit Hole

ForeThought was probably the point where things started getting a little out of hand. As a keen golfer, I'm constantly trying to improve my game, and like most golfers, I've experimented with various applications for tracking scores, measuring distances and analysing performance. There are plenty of excellent options available, but I wanted something slightly different. Rather than another application to use while walking around the course, I wanted somewhere to sit down afterwards, review what had happened and work out what I actually needed to practise.

The original idea was a relatively straightforward macOS golf journal. Record a round, enter a few statistics, review the results and perhaps keep some notes about practice sessions. Being someone who spends plenty of time using a Mac, it made sense to build the application around the desktop rather than trying to squeeze everything onto a phone screen. I wanted something that felt like a proper Mac application, with a dashboard, navigation, charts and enough space to present useful information clearly.

Of course, once I had the basics working, I started thinking about everything else that might be useful. Competition results, handicap tracking, lesson history, practice sessions and fitness information all became part of the application. Then came golf bag management, club specifications, distance gapping, wedge matrices and PDF reports. Before long, my simple golf journal had developed into something resembling a complete golf management platform.

The interesting thing was that I wasn't just building features to see whether I could make them work. I was actually using ForeThought to record my own rounds, review my performance and identify areas of my game that needed attention. Seeing an application I'd created become part of my regular routine was a particularly satisfying milestone, and it encouraged me to continue developing the idea.

One Application Becomes Two

ForeThought introduced another problem almost immediately: it's a Mac application, and taking a MacBook onto a driving range or into a golf lesson isn't particularly practical. What I needed was a lightweight companion application that could record useful information while I was away from my desk and make it available to ForeThought afterwards.

That became Lesson Logger, initially designed as a simple digital notebook for recording golf coaching sessions. Anyone who has had a golf lesson will know how easy it is to leave feeling you've finally understood your swing, only to forget half the instructions a few days later. I wanted somewhere to record what my coach had explained, what needed practising and any particular feelings or movements I should remember before the next session.

As with ForeThought, the original scope didn't stay small for very long. Lesson Logger developed to include practice planning, guided programmes, fitness activities, yardages, coaching assessments and reporting. The challenge also moved beyond simply recording information. I wanted the two applications to exchange data, which introduced file handling, JSON structures, cloud storage, automatic imports and all the little complications involved in making separate applications work together.

Android development has added another dimension to the project, particularly when trying to provide a consistent experience across different operating systems. What began as a small iPhone companion has gradually become an important part of a much wider system for recording, understanding and improving golf performance.

From Golf Courses to Padel Courts

You might think that two golf applications would be enough to keep me occupied, but apparently not. During the winter months, when the weather and shorter days make regular golf more difficult, I started playing more padel. It's a brilliant game, excellent exercise and surprisingly addictive, but it wasn't long before I found myself thinking about another little piece of technology that could make the experience better.

That idea became Courta, a padel scoring application designed to make keeping track of points, games and sets as straightforward as possible. The initial concept was simple enough: two teams, clear scoring controls and an interface that could be used without interrupting play. However, padel has several scoring variations, including tiebreaks and Golden Point rules, so even the basic scoring logic needed considerably more thought than I'd originally anticipated.

Then I started exploring connected matches, allowing multiple players to follow the same scoreboard using a shared six-digit code. Suddenly the project involved a server API, synchronisation between devices and support for both iOS and Android. Apple Watch development introduced another challenge entirely: creating controls large enough to use reliably on a tiny screen while playing a competitive sport. I've also spent a surprising amount of time refining spoken announcements so the application knows when to call game point, announce completed games and report the result of a set correctly.

Courta has been particularly interesting because so much of its development depends on real-world testing. Something might look perfectly sensible in Xcode but turn out to be awkward when you're standing on a padel court trying to award a point between rallies. That feedback has been invaluable, and it's a good reminder that designing software isn't just about making something look attractive on a screen.

And Then There Was Parked

My latest project came from a completely different interest: cars. I've always had a soft spot for older German machinery, particularly Volkswagens, and owning or regularly using more than one vehicle creates a small but surprisingly annoying problem. Apple Maps and Google Maps are both capable of remembering where you've parked, but their automatic parking features are generally focused on the most recently parked vehicle rather than keeping track of multiple cars independently.

If you've left a classic car somewhere, switched to your everyday vehicle and parked that somewhere else, the original location isn't necessarily going to be available when you need it. It's not a problem everybody encounters, but it's exactly the sort of inconvenience that makes me wonder whether I could build something better.

Parked is my attempt to solve that problem. The idea is to manage individual vehicles, each with its own saved parking location, while also providing useful everyday features such as parking timers and reminders. It's intended to be equally useful for someone who owns several classic cars and someone who simply wants to remember where they've parked in an unfamiliar town.

I'm continuing to test the iOS application, particularly how it behaves when switching between different vehicles, with Android development and parking-location sharing also part of the plans. Like my other applications, Parked started with a fairly modest idea but has already presented plenty of interesting challenges around location services, reliability and making the whole experience feel effortless.

From Writing About Technology to Creating It

Perhaps the biggest change throughout all this has been how I now look at the software I use every day. I've spent years enjoying Apple's hardware, operating systems and wider ecosystem, but building applications has given me a completely different appreciation for what happens behind the interface. File permissions, synchronisation, database structures, background processing and device compatibility are things most people never need to think about, yet they can make the difference between an application that's genuinely useful and one that's frustrating to use.

I've also learned that software development is largely an exercise in problem-solving and patience. There are days when everything comes together beautifully, followed by others when a tiny change introduces a completely unexpected problem. Something that works perfectly on one device might behave differently on another, and occasionally the solution to an issue turns out to be considerably simpler than the hours spent investigating it.

Despite the frustrations, there's something enormously rewarding about opening an application on your Mac, phone or watch and knowing it's there because you decided to create it. Even better is discovering that it actually solves the problem that inspired it. Whether that's recording a golf lesson, analysing a round, keeping score during a padel match or remembering where you've left a car, these aren't necessarily revolutionary ideas, but they're useful ones.

For me, that's always been the most interesting part of technology. Not simply owning the latest hardware or comparing specifications, but finding ways to make the devices we already have work harder and do something worthwhile.

The Next Chapter for The Apple Geek

The Apple Geek has always been somewhere to document the things I've learned, the experiments I've tried and the technology I've found interesting. From repairing and upgrading ageing Macs to exploring Linux and discovering useful applications, the site has reflected whatever technological rabbit hole I've happened to find myself exploring at the time.

Developing ForeThought, Lesson Logger, Courta and Parked feels like a natural continuation of that journey. Instead of simply reviewing somebody else's software, I'm now in a position to share the experiences of building my own, including the design decisions, technical challenges, successes and inevitable mistakes along the way.

All four applications are at different stages of development, and I've got plenty of ideas about where I'd like to take them next. I'll be writing more about each project individually, looking at where the ideas came from, the features I've built and the lessons learned throughout their development.

If there's one thing I'd like people to take away from all this, it's that you don't necessarily need an enormous business plan or a revolutionary concept to start creating something. Sometimes a small inconvenience, a little curiosity and the willingness to experiment are enough to get started.

I'm not entirely sure what this means for my spare time, particularly when I keep finding new problems I'd like to solve. But I'm enjoying the process, learning an enormous amount and building things I genuinely want to use.

And really, isn't that what being a geek is all about?