Ship an iOS app from Codex to TestFlight

Build a SwiftUI app with Codex, check it in the cloud, send it to TestFlight, and prepare an App Store release without owning a Mac.

September 9, 2026 · 9 min read

Need a Mac for this? NoMac gives your agent full macOS with Xcode for $0.80 an hour, billed per minute. Start now →

OpenAI Codex can create and maintain a native SwiftUI app, but writing the source is not the same as shipping it. A distributable iPhone app must still be compiled with Xcode, signed for your Apple team, uploaded to App Store Connect, processed, and installed through TestFlight.

On a Mac, Codex can work with the local Xcode toolchain. Without a Mac, it can keep working in the repository and start a NoMac cloud Mac for the macOS-only steps. The result is a closed loop: Codex changes code, builds it on the Mac, reads the failure or success, and gives you a beta to test on your iPhone.

What Codex can do in an iOS repository

OpenAI's official Build for iOS guide covers scaffolding, building, debugging, and testing SwiftUI projects. It recommends a CLI-first project with a repeatable build command and shows how local Xcode tools can give Codex simulator output, screenshots, and UI automation.

That is the best loop when a Mac is available. The no-Mac version keeps the same disciplined repository and runs the same Xcode commands on a cloud Mac that Codex drives over MCP:

Prepare the Apple side once

• ·Join the Apple Developer Program.
• ·Create the app record in App Store Connect with the final bundle ID.
• ·Connect an App Store Connect team key to NoMac at nomac.app/apple.
• ·Add yourself as a TestFlight internal tester and install TestFlight.

Apple requires the app record before a build can be uploaded. It also uses the bundle ID and version information inside the build to match that upload to the record, as explained in App Store Connect Help. Set those identifiers carefully before asking Codex to create repeated releases.

None of this is needed to start a Mac and compile: an Apple account matters only for signed builds. Mac time comes from prepaid credit at $0.80 an hour, billed per minute.

Connect NoMac to Codex

From the machine that contains the project, authenticate once:

npx @nomac/cli login

Then add the local MCP server to Codex:

codex mcp add nomac -- npx @nomac/cli mcp
codex mcp list

The official OpenAI MCP documentation documents the codex mcp add command and says the desktop app, CLI, and IDE extension share the MCP configuration. Clients that connect to remote MCP servers can use the hosted server at https://mcp.nomac.app/mcp instead, which signs in with OAuth.

Write a brief that produces a shippable first version

Codex is strongest when it can inspect the repository and work toward observable acceptance criteria. Define one user, one main job, the data boundary, and what “done” means.

Build version one of a native SwiftUI iPhone app for recording coffee recipes.

The user can create, edit, delete, and search recipes. Each recipe has a name,
coffee weight, water weight, grind note, steps, and optional rating. Store data
locally. There is no account, analytics, or network service in version one.

Inspect the repository before editing. Keep the architecture small, preserve
the existing deployment target, add unit tests for validation and search, and
use accessible standard controls. When ready, start a NoMac Mac and build for
the Simulator. Fix evidence-backed failures, then ask me before creating a
TestFlight build.

This prompt limits accidental scope and gives Codex permission to finish the compile loop without giving it permission to publish an unreviewed app.

The Codex-to-TestFlight workflow

1. Inspect the project

Have Codex report the project or workspace, scheme, bundle ID, deployment target, dependencies, and entitlements. If the repository contains only Swift files, ask it to make a complete project before building. A shippable app needs project configuration and assets, not just code that looks valid.

2. Put an exact commit on the Mac

Codex calls start_mac, waits until the Mac is ready, and clones the repository into ~/drive/src with exec_mac, or runs nomac sync . from the project folder. That gives the remote build a defined input. If Codex changes a file afterwards, it must send the change to the Mac again; otherwise it will be debugging older source. The drive is kept between sessions, so a later session continues from the same folder.

3. Compile for the Simulator

Codex runs an unsigned xcodebuild build and the unit tests for the Simulator. On failure, it reads the relevant lines of the compiler output. Ask Codex to state the failure category and proposed fix before it edits anything.

Use NoMac: start a Mac, clone this repository into ~/drive/src and build
the app for the iOS Simulator. If it fails:
1. find the relevant error lines in the build log;
2. explain the root cause in plain English;
3. make the smallest supported fix;
4. pull the fix on the Mac and build again.
Do not sign or send anything to TestFlight yet.

For a private repository, save a GitHub token as a NoMac secret first (request_secret), so the Mac can clone and pull it.

4. Release to TestFlight

When the Simulator build passes, approve a TestFlight build. Codex calls set_up_signing, runs the archive and export commands it returns, and sends the .ipa with send_to_testflight. Apple processes the binary, usually in 5 to 15 minutes, before TestFlight can distribute it. When ready, install it and test the main flow from a clean launch. Then have Codex stop the Mac.

5. Feed the real result back

Report what you observed, not what you think the code is doing. Include the device, screen, action, actual result, and expected result. Attach a screenshot for visual problems. Codex can then inspect the relevant source, add a regression test where possible, and make the next small change.

What to test on the iPhone

• ·First launch, empty state, and the complete main task.
• ·App relaunch after data has been created or edited.
• ·Large text, VoiceOver labels, dark mode, and landscape where supported.
• ·Keyboard dismissal, validation errors, and destructive-action confirmation.
• ·Offline behavior and denied permissions.
• ·An older supported iOS version if real users may have it.

TestFlight is not only a delivery channel. Apple provides tester feedback, screenshots, and crash reports through it, and Codex reads shared crashes and comments with get_feedback. Apple's TestFlight overview explains the internal and external testing path. Internal testing is usually the fastest loop while you are still changing basic behavior.

Keep the agent's authority narrow

Codex can safely run reversible steps under clear instructions: edit, test, compile, and create internal beta builds. Store submission deserves a separate gate. It changes the state of your developer account and may send the app to review.

• ·Let Codex run review_lint and explain every blocker.
• ·Let it draft descriptions and release notes from features that really exist.
• ·Check screenshots, privacy answers, age rating, encryption, and content rights yourself.
• ·Require explicit approval before publish is called with confirmation.

When a Mac would improve the loop

A NoMac Mac runs the Simulator too: Codex can boot a device with simctl, install the build, and look at the screen with screenshot_mac. If you have access to a Mac, a local Xcode integration still avoids the network round trip for rapid UI work: the agent can build, launch, inspect screenshots, and interact with the simulator before making a release. The XcodeBuildMCP and NoMac guide shows how that local loop and a cloud Mac fit together.

If you do not have a Mac, keep views simple, make logic testable, use Simulator builds on the cloud Mac for compiler feedback, and use TestFlight for real behavior. Also read what actually needs a Mac for a clear list of the steps the cloud can handle and the decisions only you can make.

The practical result

Codex becomes more than a code generator when it can see whether the project compiled and help deliver the result to a real device. The effective no-Mac loop is simple: edit, build on the cloud Mac, fix, sign, TestFlight, feedback, repeat. The final App Store decision stays with you.