I’ve recently branched out into building iOS apps, mostly for my beautiful new rowing computer, but also some other fun projects I’m really proud of, hopefully soon to be released.

Like any good development process I have a CI. I think the CI is a fantastic tool for not only ensuring code quality but also handling automated builds and deployments. I really don’t ever want to have to manually deploy something again.

To build iOS apps you need XCode. To run XCode you need Mac OS. To run XCode build jobs ephemerally, so that they’re lean, predictable/consistent and easy to maintain you need to either use a dedicated Mac OS runner service (expensive and opaque) or you need a Mac running headless long term (cheap, unreliable).

Mac OS is not a server OS. Mac OS is an antiquated Unix clone that has been poorly maintained and has largely been extended in recent years in service of UI-only usage. It is not a desktop/consumer OS and therefore is not appropriate for long running and headless tasks. I note that there’s a cool open source project to improve it.

I already run a fleet of Mac Minis and Ultra macs, which are incredibly good value these days in the age of the RAMapocalypse. What if I could run Mac OS as a guest OS on Linux (in my case Fedora Asahi Remix) and by extension have a proper ephemeral VM-based runner for my iOS build jobs?

Well, this is now possible: https://github.com/aquarat/apple-macos-arm64-vm-guest

This is shamelessly a Claude and GLM 5.3 production with sprinklings of GPT 6 Astra.

Unfortunately Anthropic occasionally decides that my reverse engineering work is [cyber] and blocks me, but honestly, GLM 5.3 is now excellent. Not as good as Claude Opus 5.5 but good enough and especially good for reverse engineering work. Thank you Dario, thank you for promoting GLM 5.3 by telling me how dangerous it is and how I shouldn’t be allowed to use it 🫠

Back to the VM guest project: A user called steelbrain did some experimental work on this topic originally. It gave me/the agent the base from which to work. Their work was alpha and incomplete. One of the big issues was the lack of a virtualised clock, which cause all kinds of boot failures. Another issue was the GPU handling, which was largely broken and where it did work was extremely slow. The iOS simulator needs a GPU, so this had to be fixed.

A huge amount of work/time went into making sure the VMs started and stopped reliably. The agents did hundreds of test runs to confirm reliability and timing - this work still isn’t sufficiently complete in my opinion. But what I can tell you is that this now works reliably for my Forgejo instance (Forgejo is an absolutely wonderful private Github system, it’s so fast 🥲, so lean, so clean).

Go forth and enjoy ❤️