A Year Ago, I Didn't Own a Mac

Twelve months ago I did not own a Mac. I had never written a line of Swift, and I could not have told you how an app gets onto a phone.

This week I finished building one.

I am a senior developer by trade, which made the whole thing harder rather than easier. When you are good at one thing, going back to being bad at something is uncomfortable in a very specific way.

The part of web work I got tired of

Most of my career has been spent on SaaS products. A lot of that work is plumbing.

Permission settings. Configuration screens. The middle layer that shuttles data between what you see and where it is stored. It is genuinely useful work and I am good at it, but I had stopped finding it interesting.

I wanted to build something a person holds in their hand and walks around with.

Buying a Mac mini was the actual first step

You cannot build an iPhone app without a Mac. That sounds obvious, but it was a real barrier: I had been a Windows and Linux person for my whole career.

So I bought a Mac mini and put it under my desk. Then I did something that turned out to matter more than the purchase: I refused to treat it as just a laptop replacement.

It became a server. Every new thing I wanted to learn, I learned by making that machine do it.

Small steps, in order

The goal was too big to attack directly, so I broke it into pieces small enough to finish in an evening. Roughly in order:

1. Get a website to publish itself automatically whenever I change the code. No manual uploading, no clicking around.
2. Set up monitoring, so the machine tells me when something breaks instead of me finding out later.
3. Lock the thing down properly. Nothing exposed to the open internet that does not need to be.
4. Only then: open Xcode for the first time.

Each step was boring on its own. Together they meant that by the time I started the app, I already had somewhere real to put its data.

Teaching an AI to log into my own server

One of the more useful experiments was giving an AI assistant controlled access to the Mac mini so it could help with server work directly.

That is a sentence worth being careful about. The interesting part was not the access itself, it was deciding what it should never be able to touch, and making sure the machine enforced that rather than trusting good behaviour.

I learned more about security in those two weeks than in years of building web apps where someone else owned the infrastructure.

The shortcut that taught me the most by failing

My first attempt at the app was not native. I used Capacitor, which is a tool that lets you wrap a website up so it installs and runs like a real app.

The appeal was obvious. I already knew how to build for the web, so I could move fast and use what I had.

And it worked, to a point. After a lot of Figma wireframing I had my idea running on an actual phone in my hand, which was a genuinely great moment.

Then I ran into the ceiling. Anything that needed to feel properly native, or run smoothly under pressure, or use the parts of the phone that make an iPhone app feel like an iPhone app, fought me the whole way.

To be clear, this is not a criticism of the web stack. I still use and love Vue for what it is good at, and that has not changed. It just turned out that "I already know this tool" is a bad reason to pick it for a job it was not built for.

Why I switched to native

So I started again in Swift, Apple's own language, using their tools.

It was slower at first. Everything was unfamiliar, and I spent a lot of evenings stuck on things that would have taken me five minutes on the web.

I leaned on AI heavily here, mostly as a tutor rather than an author. Asking why something works the way it does, having a concept explained a third time in different words, checking whether the approach I had in mind was the normal one. That shortened the learning curve more than any course would have.

The difference in the result was not subtle. The app stopped feeling like a website pretending, and started feeling like it belonged on the device.

The hardest problems turned out not to be code

I expected the technical side to be the mountain. It was not.

Once the app worked, I was left holding a set of questions my day job had never asked me: What is this actually for? Who pays, and for what exactly? What do I charge? Do I need to register a business? What do I refuse to build even though I could?

I have a business degree, and this is the first time in years it has been the more useful half of my education.

Those questions are harder than Swift, because nothing compiles. There is no error message telling you your pricing model is wrong.

What I have now

The app is built. It is past the point where I would call it a minimum viable product and into the territory where I am proud to show it to people.

It is called Meadow. The short version: you leave a song at a real place, and someone else has to physically walk there to find it.

I will write about how it works properly in its own post, because it deserves more room than a paragraph here.

If you are thinking about a similar jump

Buy the hardware before you feel ready, pick steps small enough to finish in one sitting, and do not assume your existing tools deserve to come with you.

The tool you know is not always the right tool. That was the expensive lesson, and it was worth it.

If you want to follow what happens next, come and say hello in my Discord server, or have a look at plantasong.com to see what I have been building.