Part 2 of **Building Apps Without Code. Part 1 is how I built my first app, Steamy Dumplings, without knowing how to code. This one is for people who don't own a Mac — and can't justify buying one — but still want to ship iPhone apps.
I don't own a Mac. I never have. Everything below was done from my iPhone.
But I do have iPhone apps — real ones, in TestFlight, one of them submitted to the App Store. I'm a no-code builder. I work with an AI partner (Forge, my Muse agent) who writes the code. My job is the ideas, the decisions, and the testing on my phone.
That worked fine — until we nearly ran out of the thing we were borrowing to build on.
The problem: the line, and the cap
To ship an iPhone app, Apple requires a Mac. Not "prefers." Requires. Xcode — the tool that compiles, signs, and uploads an iOS app — only runs on macOS, on Apple hardware.
We were using GitHub Actions' Mac runners. It worked, but:
- We'd burned 1,826 of 2,000 included minutes by the morning of Oct 20. macOS minutes count at 10x, so what's left looks bigger than it is.
- Runners queue. You push, you wait in line, you hope.
- The obvious fix — buy a used Mac mini for ~$433–$500 — broke my own rule: I only buy gear with money these projects have earned. We need to make money first.
So I said the thing that started all of this:
"We will build an app. No Mac needed. No line."
First, the research: why do you actually need a Mac?
Forge checked our own build workflows before we guessed. It's not one job, it's five, all bundled inside Xcode:
- Compiling the code for iPhone, using the iOS SDK that only ships inside Xcode
- Packaging icons, assets, and storyboards with Mac-only tools
- Code signing the app so Apple trusts it
-
Archiving it into the actual
.ipafile Apple accepts - Upload validation — since April 28, 2026, Apple requires Xcode 26 / the iOS 26 SDK or the upload is rejected
You can't do those five on an iPhone. There's no Xcode for iOS. What you can do is hide the Mac somewhere else — and build a simple front door to it on your phone.
That's the whole idea: make your iPhone act like the Mac you don't have. Simple cards for each of my apps, one big "Build to TestFlight" button, plain-English status. No fake Mac desktop — I killed that idea. Simple cards. Your iPhone is the front door, a real Mac in the cloud does the five jobs behind it.
The two free lanes we found
We didn't invent a Mac. We found two we already had access to, for free:
- Codemagic — the button lane. 500 free macOS minutes a month on M2 Macs for individuals. It has an API, so a button in an app can trigger a real build.
- Xcode Cloud — Apple's own lane. 25 compute hours a month, already included in the Apple Developer Program I'm already paying $99/year for.
Combined, that's way more headroom than GitHub was giving us — and no line we don't control.
I tested the prototype on my iPhone that afternoon. Tap Dumplings → watch the 5 steps check off → "In TestFlight." Simulation, clearly labeled. It worked. I gave the go: connect Codemagic, make it real.
Then we failed three times in a row
This is the part most build stories skip.
Build #1 failed. Build #2 failed. Build #3 failed — all at the exact same step: writing the App Store Connect API key.
The key existed. It was saved in Codemagic. It worked everywhere else. But inside the build, the key file came out empty, and the signing step rejected it.
Build #3 added a diagnostic that finally cracked it: Codemagic's portal integration doesn't hand your actual key to build scripts. It hands them a 72-character reference token pointing at the key. If your script treats that token like the key itself, you get an empty file and a confusing error.
The fix wasn't in the portal at all. It was moving the key into an encrypted environment-variable group and letting the build script prefer that. One commit later:
Build #4 succeeded end to end in 3 minutes flat. Key valid, archive signed, uploaded. At 4:43 PM ET on Oct 20, Steamy Dumplings build 16 landed VALID in App Store Connect.
No Mac in my house. No GitHub line. A button, a cloud Mac I don't own, and a build Apple accepted.
What we deliberately did NOT ship on
We also researched a more radical idea — building on Linux with open-source Xcode replacements, no Mac anywhere at all. Those projects are public and real, but Apple's license restricts the iOS SDK to Apple-branded hardware, so that path carries a terms risk for a developer account.
I'm not risking the account my apps live on for an experiment. The method in this article — your iPhone in front, a legitimate cloud Mac behind it, through Apple's own Developer Program — is the safe, repeatable one. That's the one I'm teaching here.
What's next
The iPhone front door got its final wiring that same evening. We rebuilt it with the trigger key held safely in its backend, instead of bolting it on — and then I pressed the button myself. The app ran it all the way to "In TestFlight," and Steamy Dumplings build 17 landed VALID in App Store Connect that night. The button isn't a prototype anymore. It's how I ship.
But the question we set out to answer is already answered:
You don't need to buy the Mac first. You need to understand exactly what the Mac does, find where that work can legally live, and build the simplest possible door to it.
For me, that door is an app on my phone, with my apps as cards, and one button.
No Mac. No line.
Try it yourself
- Apple Developer Program — you need this either way, it's what makes TestFlight and the App Store possible: https://developer.apple.com/programs/enroll/
- Xcode Cloud — Apple's own cloud build service, 25 hours/month included with that program: https://developer.apple.com/xcode-cloud/
- Codemagic — the cloud-Mac service we built on: https://docs.codemagic.io/yaml-basic-configuration/yaml-getting-started/
- Codemagic code-signing with environment variables — the docs behind the fix that saved Build #4: https://docs.codemagic.io/yaml-code-signing/alternative-code-signing-methods/
- My apps and projects — Hawkins Crafting Co.: https://hawkinscraftingco.com
Patrick Hawkins builds apps, books, and products with AI as a creative partner — no code background. He writes about the real builds, including the failures, here on DEV.
