Give your coding agent TestFlight
A coding agent can write a whole iOS app and then stall at the last mile, because shipping needs a Mac, a certificate and a form. Here is the loop that closes it — build, TestFlight, crash reports, back to the agent.
· 6 min read
A coding agent can write a complete iOS app. It can plan the data model, argue with itself about navigation, and produce a Swift project that compiles. Then it stops, because the next step is not code: it is a certificate, a Mac, a provisioning profile and a web form.
The gap is not intelligence. It is hands. Everything past build requires acting on systems the agent has no account on — and the usual workaround, telling the human to go do fourteen things in App Store Connect, is where most agent-built apps quietly die.
The loop that closes it
What an agent needs is not a dashboard. It needs verbs it can call and structured answers it can reason about:
- ·push — pack the working tree and upload it. Secrets stay on the machine.
- ·build — a signed release build on a cloud Mac, no Xcode anywhere.
- ·testflight — on your phone in about three minutes.
- ·submit — metadata, screenshots, review checks, and the submission.
The important half is the return path. A build failure that comes back as four thousand lines of xcodebuild output is not something an agent can act on; it will guess, and it will guess at your source code when the actual problem was a deployment target or a missing capability. A failure that comes back as a classified reason with the relevant log excerpt is a fix.
Wiring it up
Two commands, then the agent is autonomous for everything after:
npx @nomac/cli login # prints a URL and a short code — you approve it in the browser. # No key is ever pasted into the agent's context.
Then give the agent the MCP server, either locally or hosted:
# stdio command: npx args: ["nomac", "mcp"] # or hosted https://mcp.nomac.app/mcp Authorization: Bearer <nmk_key>
Or skip all of that and tell the agent to read nomac.app/install, which is written for exactly this: an agent-readable setup page that configures the rest itself.
What to keep the human for
An agent that can submit to the App Store unattended is a bad idea, and not because agents are careless. Submission is irreversible in the ways that matter — a rejection is on your developer account, a shipped bug is on your users, and Apple's patience with repeat low-quality submissions is finite.
- ·Builds and TestFlight: let it run. Cheap, reversible, and the fast loop is the entire value.
- ·App Store submission: ask first. The agent prepares everything and stops for a yes.
- ·Anything touching credentials: never. The device login exists so the key never enters a prompt.
This is the same reasoning as a code review gate. The agent doing the work does not mean the agent decides when the work ships. Keep the irreversible step behind a human, and the reversible ones fully automatic.
What comes back
Once a build is on TestFlight, the interesting direction is inbound. Crash reports and tester feedback flow back to the agent, which means the debugging loop closes without you copying stack traces between windows: it shipped it, it can see what happened, it can fix it and ship again.
That is the part that changes how it feels to build. Not “the AI wrote my app” — plenty of tools do that — but that the distance between noticing a bug on your phone and having a fixed build back on your phone is one sentence and three minutes.
Before the first submission
Getting a build to TestFlight is mechanical and now largely solved. Getting through App Review is neither, and an agent will happily submit something with a generated icon, placeholder copy and a category Apple has closed. Read why App Review rejects AI-built apps before you spend a review cycle finding out, and what actually needs a Mac for the one-time Apple setup no tool can do for you.
The full command surface is in the CLI reference, and the HTTP equivalent in the API reference.