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

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

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 give Claude a Mac it can reach. Claude Code works in your project on the computer you already have. When it needs Xcode, it starts a NoMac cloud Mac, puts the project there, builds and tests it, signs the app and sends it to TestFlight. 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.
• ·NoMac credit: $10 buys 12.5 hours of Mac time and never expires.
• ·An iPhone with TestFlight installed for real-device testing.
• ·An active Apple Developer Program membership for signed distribution. Building and running the Simulator need none.
• ·An app record in App Store Connect and a team key connected to NoMac.
• ·Node.js on the machine where Claude Code runs.

The Apple account work is a one-time human step: create the app record, then connect an App Store Connect team key at nomac.app/apple. 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. It stays on NoMac's server and never reaches the Mac or the chat; Claude only needs a NoMac login.

Connect Claude Code to a cloud Mac

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 get_mac_credits and connect_status. Claude should now see tools for starting a Mac, running commands on it, setting up signing, and sending a build to TestFlight.

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, start a NoMac Mac, build it for
the Simulator, run the tests, and fix any compiler errors. Ask me before
signing a build for TestFlight. Stop the Mac when you are done.

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. Start a Mac and put the project on it

Claude calls start_mac and waits until the Mac is ready, usually in about a minute. It then clones the repository into ~/drive/src with exec_mac, or runs nomac sync . from the project folder to upload the working tree. Cloning from Git sends only committed files, so local secrets stay where they are. The drive is kept between sessions, so tomorrow's session continues from the same folder.

2. Compile before you sign

Claude runs an unsigned xcodebuild build for the Simulator. It catches Swift errors, missing files, package problems, and many project-setting mistakes without an Apple account or a TestFlight release. Claude reads the compiler output, changes the source, sends it to the Mac again, and repeats. It can run the unit tests the same way, boot the Simulator, and look at a screen with screenshot_mac.

3. Create the TestFlight build

Once the build passes, Claude calls set_up_signing. It registers the bundle ID, makes the App Store profile, installs it with the account's certificate on the Mac, and returns the exact archive and export commands. Claude runs them, then calls send_to_testflight with the .ipa. Apple processes the upload, usually in 5 to 15 minutes, 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. Crashes and comments testers share come back to Claude through get_feedback, giving it evidence instead of guesses.

Claude stops the Mac when the work is done. Stopping deletes the VM; the project and build caches on ~/drive are kept, so the next build is incremental.

How development differs from a local Mac

A local Mac runs a simulator after every small change at no cost. A cloud Mac can run the same Simulator, but it is billed by the minute and every step goes over the network, so make each 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. Read the error before editing Swift; steps only a person can take come back from set_up_signing with a link.
• ·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 on the App Store record before submission, fill in the metadata with set_metadata, prepare accurate screenshots, and answer Apple's privacy, encryption, content-rights, and age-rating questions yourself. Claude can stage the release with publish, which returns Apple's blockers without submitting, 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 but fails during distribution.

The short version

Claude Code writes and repairs the app on Windows or Linux. A NoMac Mac runs Xcode, signing, and the TestFlight upload, started and stopped by Claude and billed by the minute. 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.