DEV Community: Patrick Hawkins

Make Your iPhone Into a Mac to Create Apps for the App Store

Patrick Hawkins — Wed, 21 Oct 2026 17:02:56 +0000

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 .ipa file 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.

I Built My First App Without Knowing How to Code

Patrick Hawkins — Wed, 21 Oct 2026 16:58:50 +0000

Part 1 of **Building Apps Without Code. This should have been my first article, because this is where it all started.

I can't code. Not "I code a little." I mean I have never written the code behind anything I've shipped.

And I have an app — a real one, submitted to the App Store.

It's called Steamy Dumplings, and it's the reason everything else I'm doing exists. So let me tell this one properly, from the start.

What Steamy Dumplings is

Steamy Dumplings is a virtual blind-box app. If you've ever bought a mystery toy and felt that little rush before you open it, that's the feeling we built around.

You open a bamboo steamer, a dumpling is revealed, and it goes on your shelf — your collection, your trophies. Simple on purpose. The fun is in the reveal and in collecting.

By October 7 we had 500 dumplings wired into the app. Five hundred. I didn't build a system for managing 500 collectibles in code, because I couldn't. I kept saying what the next one should feel like, and we kept going until the shelf was real.

The idea came from my son. He was bringing home these dumpling toys, and then we found out something inside them was harmful — causing burns or something like that to kids when they burst open. I thought the idea was cool, being able to collect all these different kinds of dumplings, but I didn't like the idea of having a harmful toy in the house. So I decided to make a game where you could still collect them — but it was on the phone.

How building with AI actually worked, day to day

I work with an AI partner — Forge, my Muse agent. Forge writes the code. We don't pretend otherwise.

My job is everything else:

The ideas. My brain goes a thousand miles a minute. That's my ADHD, and for years it meant a head full of ideas and not enough finish-line bandwidth to learn to code and build the thing. This partnership changed the maths: the ideas could finally get out of my head.
The decisions and the taste. What the steamer should look like, what's too much, when a reveal doesn't feel right. An AI can generate a hundred versions — somebody still has to point and say "that one, and here's why the others are wrong."
The testing. On a real phone, in real hands — including my son Jack, who's 12, and was one of our playtesters. Kids do not protect your feelings about your app, which is exactly why you want them testing it.

That's what "building without coding" actually looks like. Not one magic sentence. A conversation, over and over: I describe it, Forge builds it, I say what's wrong, we go again.

And Jack did more than test it. He gave me a lot of good ideas that have been put into the game — most of them about how the game looks, and things that improved how it plays.

The hardest parts were not the parts I expected

I assumed the hard part would be "the code." It wasn't — I never touched it. The hard parts were:

1. Saying exactly what I meant. "Make it feel better" is not an instruction. Learning to describe what was in my head clearly enough to build took real practice. That skill, honestly, is most of the job now.

2. Knowing when to stop adding things. Every idea sounds good at midnight. Half of building this app was deciding: does the first version need this feature, or does it need to exist first? It needed to exist first.

3. The unglamorous Apple stuff. Turning a working web build into a real iPhone app is a whole second project. We started with a web build and demo so people could try it. Going native meant buying the Apple Developer Program on October 14 — $99 a year, real money out before the app had earned a cent. Then Forge hit a wall: Apple's API simply wouldn't create the App Store Connect record for the app. So I created it myself, manually. The human had to do the one step the automation couldn't. That happens more than people admit.

4. Problems you only find on a real phone. Our builds ran on cloud Macs — I don't own a Mac — and went up to TestFlight. One build had a sound problem we only caught by testing on an actual phone; the fixed build was confirmed working on device before it became the one we submitted.

The milestone: submitted

On October 19, Steamy Dumplings v1.0 was submitted and sat at "Ready for Review," set to release automatically if Apple approves it.

As I write this, Apple hasn't approved it yet, and I'm not going to pretend otherwise. That's fine — the thing I set out to prove is already proved. A person who cannot code described an app, made the calls, tested it on his phone and with his kid, paid the $99, did the manual step Apple required, and got a real app through the real submission door.

What I'd tell another non-coder

Your job isn't code. Your job is knowing what you want. If you can describe it, judge it, and keep deciding, you have the skills that can't be handed off.

Expect a conversation, not a vending machine. We built this together, in loops, with plenty of wrong versions. Expect one prompt to do it and you'll quit at the first bad build.

Test it in real hands early. Especially a kid's, if you can borrow one. They'll find what's boring and what's broken faster than anyone.

Budget for the boring gates. The $99, the accounts, the records you create yourself — that's not a sign you're doing it wrong. It's the toll booth, and everybody pays it.

Ship the first one small and real. Steamy Dumplings is not everything I imagined on day one. It's the version that exists. Everything I'm building now exists because this first one got finished.

You don't need permission from a skill you don't have. You need a first app.

This was mine.

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.

Follow-up article: "Make Your iPhone Into a Mac to Create Apps for the App Store" — how I kept building and submitting apps without ever owning a Mac.

See what I'm building: Hawkins Crafting Co. — Steamy Dumplings and all my other projects live there.