Build an iOS app with Claude Code — without a Mac

Create a native SwiftUI app with Claude Code on Windows or Linux, build it on a cloud Mac, and test the signed release on your iPhone with TestFlight.

September 9, 2026 · 9 min read

Yes, Claude Code can help you build a native iOS app even when your computer runs Windows or Linux. It can create the SwiftUI source, organize the Xcode project, fix compiler errors, and prepare the store release. What it cannot do on those computers is run Apple's compiler. Xcode still requires macOS.

The practical solution is to separate writing the app from building it. Claude Code works in your project on the computer you already have. NoMac sends that project to a managed Mac, signs the app, uploads it to TestFlight, and returns useful build results to Claude. Your iPhone becomes the place where you test the real app.

What each part does

Anthropic officially supports Claude Code on macOS, Linux, and Windows, including Windows through WSL or Git Bash. Follow the current Claude Code setup guide for your operating system. The editor is portable; Apple's release toolchain is the part that is not.

What you need before you start

• ·A repository containing a native iOS project, or a clear plan for Claude to create one.
• ·An iPhone with TestFlight installed for real-device testing.
• ·An active Apple Developer Program membership for signed distribution.
• ·An app record and an App Store Connect API key connected to NoMac.
• ·Node.js on the machine where Claude Code can read your project.

The Apple account work is a one-time human step. If the API credential is new to you, read the App Store Connect API key guide. Keep that private key out of prompts and source control; Claude only needs a NoMac login, not your Apple credential.

Connect Claude Code to the iOS build pipeline

Run the login once in a terminal. It opens a browser approval flow and stores the NoMac credential locally:

npx @nomac/cli login

Next, register NoMac as a Model Context Protocol server in Claude Code:

claude mcp add nomac -- npx @nomac/cli mcp

Anthropic documents the same claude mcp add pattern in its MCP documentation. Restart Claude Code if the tool list was already open, then ask it to check connect_status. Claude should now see tools for pushing a project, starting a build, checking status, reading a failure, and preparing a release.

Give Claude a precise first task

Do not begin with only “make me an app.” A useful prompt names the user, the main action, the data, and the first testable version. For example:

Create a native SwiftUI iPhone app for saving short hiking notes.

Version one needs:
- a list of notes
- a form with title, trail name, date, and text
- local persistence; no account and no server
- an empty state and accessible labels

Inspect the repository first. Keep the architecture small. Add unit tests for
the storage logic. When the project is ready, run a NoMac smoke build, fix any
compiler errors, then ask me before starting a signed TestFlight release.

This gives Claude a finish line. It also tells the agent to use a quick compile check before creating a signed release, and it keeps the irreversible decision with you.

The build-and-fix loop

1. Push the current project

Claude calls push_project. The source is packed from the current working tree, so run the MCP server on the same machine as the repository. Check that generated build folders and local secrets are ignored before the first push.

2. Compile before you sign

Ask for build with workflow=smoke. A smoke build catches Swift errors, missing files, package problems, and many project-setting mistakes without making a TestFlight release. Claude polls status, reads the structured failure, changes the source, pushes again, and repeats.

3. Create the TestFlight build

Once the smoke build passes, Claude starts build with workflow=release. NoMac builds with Xcode, signs the archive, and uploads it to App Store Connect. Apple then processes the upload before it appears in TestFlight. Apple's build upload documentation explains that processing step and the version identifiers used to match a build to its app record.

4. Test on the device you actually use

Install the build from TestFlight and test the complete path, not just the launch screen. Create data, quit and reopen the app, change text size, deny a permission, rotate the phone, and try the empty state. TestFlight feedback and crash information can come back through the release loop, giving Claude evidence instead of guesses.

How development differs without a local simulator

A Mac workflow can run a simulator after every small change. A Windows or Linux workflow cannot, so make each remote build answer a useful question. Group related source changes, use unit tests for logic, keep views small enough to reason about, and make a TestFlight build when the feature is coherent.

• ·Prefer standard SwiftUI controls before writing custom gestures or drawing code.
• ·Separate data and business logic from views so it can be tested without a screen.
• ·Ask Claude to treat warnings as work, not background noise.
• ·Send screenshots with exact observations: what happened, what you expected, and on which screen.

If you later gain access to a Mac, Claude can also work directly with Xcode. Anthropic says Xcode 26.3 integrates the Claude Agent SDK and exposes project features through MCP. That is a strong local development loop, but it is a different setup from this no-Mac path. The Anthropic announcement describes the integration.

Common mistakes

• ·No Xcode project in the repository. Swift files alone are not a shippable app. Claude must create or maintain a valid project, workspace, or supported generated project.
• ·The bundle ID does not match. The project, App Store Connect record, and provisioning setup must refer to the same identifier.
• ·A package works only on the newest SDK. Pin dependencies and keep the deployment target explicit so the cloud build is repeatable.
• ·Every problem is treated as a code problem. Signing and provisioning failures have different fixes. Use the classified build result before editing Swift.
• ·The first real test happens at submission. TestFlight is the iteration loop, not a ceremonial final step.

From a working beta to the App Store

A build is only one part of an App Store release. Run review_lint before submission, fill in the metadata, prepare accurate screenshots, and answer Apple's privacy, encryption, content-rights, and age-rating questions yourself. Claude can prepare the work, but it should stop before the final confirmed submission.

Apple says TestFlight is for distributing beta builds, collecting feedback, and improving the app before review. Treat it that way. Read why App Review rejects AI-built apps before submitting, and use the code-signing error guide if the project builds locally in theory but fails during distribution.

The short version

Claude Code writes and repairs the app on Windows or Linux. NoMac performs the Xcode, signing, and TestFlight work on macOS. You test the native result on your iPhone. That is a real iOS development loop without owning a Mac—and it works because each tool is used for the part it can actually do.