XcodeBuildMCP and NoMac are two halves of iOS development

XcodeBuildMCP gives an AI agent hands inside local Xcode; NoMac gives it a cloud release path to TestFlight and the App Store. Here is when to use one or both.

September 9, 2026 · 8 min read

XcodeBuildMCP and NoMac both let an AI agent act on an iOS project, but they solve different problems. XcodeBuildMCP gives the agent structured control over Xcode on a Mac. NoMac gives the agent a managed path from a source snapshot to a signed TestFlight or App Store release.

If you own a Mac, the tools work well together: use XcodeBuildMCP for the fast local simulator loop and NoMac for the repeatable release loop. If you work on Windows or Linux, XcodeBuildMCP does not remove the need for macOS; use NoMac for remote compilation and test on a real iPhone.

What XcodeBuildMCP does

XcodeBuildMCP is an MCP server and command-line tool that exposes Xcode actions to coding agents. It can discover projects, build and test schemes, control simulators, install and launch apps, capture logs, take screenshots, and support device workflows.

Its official XcodeBuildMCP documentation currently requires macOS with Xcode installed. The MCP mode guide explains that its default tool surface focuses on the simulator and can be expanded by enabling other workflows. Device work also depends on code signing being configured in Xcode.

That makes it powerful during development. An agent can change a SwiftUI view, build it, launch it in a simulator, take a screenshot, tap through the interface, inspect logs, and fix what it sees without waiting for a human to operate Xcode.

What NoMac does

NoMac accepts a project snapshot from the machine where the repository lives. It runs a smoke or signed release build on managed macOS infrastructure, handles signing, uploads the release to App Store Connect, and returns structured status and failures to the agent.

It also covers work after compilation: TestFlight feedback, release checks, metadata, screenshots, and staged App Store publication. The user connects the Apple account once and keeps final submission behind a human confirmation.

XcodeBuildMCP vs NoMac

This is not a contest over which MCP server has more tools. The useful question is where the Apple toolchain lives and which feedback loop you need right now.

Setup A: use both on a Mac

Install XcodeBuildMCP according to its current installation guide. Agents can start the MCP server on demand with:

npx -y xcodebuildmcp@latest mcp

Authenticate NoMac separately:

npx @nomac/cli login

Then add both servers to your MCP client. Claude Code, for example, can register them with:

claude mcp add xcodebuild -- npx -y xcodebuildmcp@latest mcp
claude mcp add nomac -- npx @nomac/cli mcp

Codex uses the same stdio commands behind its own configuration:

codex mcp add xcodebuild -- npx -y xcodebuildmcp@latest mcp
codex mcp add nomac -- npx @nomac/cli mcp

Other clients use JSON or TOML configuration. XcodeBuildMCP's MCP client guide provides current examples. Keep the two server names obvious so the agent does not confuse a local simulator build with a remote release build.

The combined development loop

1. Make a small source change

Ask the agent to state the acceptance criteria and inspect the current implementation. It should edit the smallest relevant area and add a test for logic when possible.

2. Build and test locally

Use XcodeBuildMCP to build the scheme for a chosen simulator. Run unit tests, launch the app, collect logs, and inspect screenshots. For a UI change, ask the agent to exercise the actual interaction rather than accepting a successful compile as proof.

Use XcodeBuildMCP for the local loop:
1. discover the project and scheme;
2. build and run on the existing iPhone simulator;
3. run the relevant tests;
4. capture a screenshot after completing the changed flow;
5. inspect warnings and logs.
Do not create a release build yet.

3. Push the tested source

After local tests pass, call NoMac's push_project. The remote build must use the same saved source you reviewed. If a file changes after the push, create a new snapshot.

4. Prove the clean cloud build

Start a NoMac workflow=smoke build. This catches differences that a developer machine can hide: an uncommitted local file, a package cache, a scheme that is not shared, or a setting that depends on one keychain.

5. Release to a real phone

Start workflow=release only after the clean smoke build passes. NoMac archives and signs the app, uploads it, and waits for App Store Connect processing. Install from TestFlight and check the same acceptance criteria on a real device.

Setup B: Windows or Linux without a Mac

Do not install XcodeBuildMCP on Windows or Linux and expect it to provide Xcode remotely by itself. Its documented requirements include macOS and Xcode. Without a Mac host, connect only NoMac to the agent:

npx @nomac/cli login

# Claude Code
claude mcp add nomac -- npx @nomac/cli mcp

# or Codex
codex mcp add nomac -- npx @nomac/cli mcp

Use smoke builds for compiler feedback and TestFlight for UI and device feedback. It is a slower interface loop than a local simulator, so group related work into coherent slices and keep business logic well covered by tests.

For the full version of that workflow, see Claude Code without a Mac, Cursor on Windows, or Codex to TestFlight.

Common ways to use the wrong tool

• ·Using TestFlight for every visual nudge on a Mac. Use the local simulator first; make TestFlight builds for meaningful device checkpoints.
• ·Treating a simulator success as release proof. A clean remote archive still catches project, dependency, signing, and environment problems.
• ·Expecting XcodeBuildMCP to manage a cloud Mac. It controls the Mac where its process and Xcode run; infrastructure is outside its main job.
• ·Expecting NoMac to be an interactive simulator. It returns builds and release state, not a live development canvas.
• ·Giving both tools a vague “build it” request. Name the local or remote workflow and the evidence you expect back.

A good instruction file prevents confusion

Put a short workflow in the repository's AGENTS.md or equivalent file. Adapt it to your project:

For normal development:
- use XcodeBuildMCP for simulator builds, tests, logs, and screenshots;
- do not change signing settings to fix a simulator-only problem.

For a release candidate:
- ensure local tests pass;
- push the current source with NoMac;
- run a NoMac smoke build;
- after approval, run a NoMac release build and wait for TestFlight;
- never submit to App Review without explicit human confirmation.

This turns tool choice into project policy. The agent no longer has to rediscover whether “build” means a quick simulator check or a signed external action.

Where the human stays in the loop

Let the agent automate reversible development and beta work. Keep Apple agreements, privacy declarations, encryption answers, age rating, content rights, and final submission under human control. Before release, run review_lint and compare every store claim with the build you actually tested.

XcodeBuildMCP closes the local feedback loop. NoMac closes the distribution loop. Used together, an agent can see the app, prove a clean build, and deliver the exact revision to TestFlight—while you still decide what reaches the App Store.