MobileBuildMCP (formerly XcodeBuildMCP) and NoMac

MobileBuildMCP, formerly XcodeBuildMCP, gives an AI agent hands inside Xcode, but it needs a Mac. Run it on your own Mac, or from Windows or Linux on a NoMac cloud Mac over SSH, and ship with NoMac.

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 →

MobileBuildMCP is the new name of XcodeBuildMCP: its old website and GitHub repository now redirect to the new ones, and the npm package is mobilebuildmcp. It and NoMac both let an AI agent act on an iOS project, but they solve different problems. MobileBuildMCP gives the agent structured control over Xcode on a Mac. NoMac gives the agent a cloud Mac with Xcode, plus the tools to sign the app, send it to TestFlight and submit it to the App Store.

If you own a Mac, use MobileBuildMCP there for the fast local Simulator loop and NoMac for a clean build and the release. If you work on Windows or Linux, MobileBuildMCP still needs a Mac, but it does not have to be yours: it runs on a NoMac Mac over SSH, and your agent uses it as if it were local.

What MobileBuildMCP does

MobileBuildMCP 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 installation guide lists macOS 14.5 or later and Xcode 16 or later as requirements. The MCP mode guide explains that its tool surface defaults to the simulator workflow 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 starts a full macOS VM with Xcode, the iOS Simulator and administrator access when the agent calls start_mac, usually in about a minute. The agent clones the repository into ~/drive/src, runs xcodebuild and simctl through exec_mac, and sees the screen or the Simulator with screenshot_mac. It costs $0.80an hour, billed per minute. Stopping deletes the VM, while the account's drive keeps the project and build caches for the next session.

It also covers work after compilation. set_up_signing makes the App Store profiles with the Apple key kept on NoMac's server, send_to_testflight puts a signed build on TestFlight, and further tools cover 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.

MobileBuildMCP 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 MobileBuildMCP according to its current installation guide. Agents can start the MCP server on demand with:

npx -y mobilebuildmcp@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 xcode -- npx -y mobilebuildmcp@latest mcp
claude mcp add nomac -- npx @nomac/cli mcp

Codex uses the same stdio commands behind its own configuration:

codex mcp add xcode -- npx -y mobilebuildmcp@latest mcp
codex mcp add nomac -- npx @nomac/cli mcp

Other clients use JSON or TOML configuration. MobileBuildMCP'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 build on the cloud Mac.

Setup B: Windows or Linux, with MobileBuildMCP on the cloud Mac

MobileBuildMCP needs macOS, so it cannot run on Windows or Linux. But an MCP client starts a stdio server by running a command, and that command can be ssh. NoMac's CLI 0.12 gives the Mac a stable SSH name, so the server runs on the Mac while your agent stays on your machine:

npm install -g @nomac/cli
nomac login
cd ~/code/MyApp
nomac start --max-duration 28800 --max-cost 7
nomac sync .
nomac ssh-config
claude mcp add xcode -- ssh nomac npx -y mobilebuildmcp@latest mcp

We ran this on October 14, 2026: MobileBuildMCP 2.7.1 started on the Mac, listed 24 tools, and its list_sims tool returned the Mac's simulators. npx is on the Mac's PATH for commands over SSH, so nothing has to be installed there first. On Windows, run the CLI in WSL, where sync's rsync is available, and run the agent there too.

A few things to know:

• ·The server works on the Mac's copy. Sync before you ask for a build; the project is in ~/drive/src/MyApp, and nomac ssh-config prints the exact path to give the agent.
• ·The name follows the folder. Each later nomac start from the same folder points nomac at the new Mac. If no Mac is running, the server cannot start: run nomac start first, then reconnect the server in your agent.
• ·The connection keeps the Mac running. An open SSH connection counts as activity, so while the agent keeps the server connected the Mac runs until its duration limit or spend cap. The command above allows eight hours and $7. Run nomac stop when you are done.
• ·Other clients. Codex takes the same command: codex mcp add xcode -- ssh nomac npx -y mobilebuildmcp@latest mcp.
• ·Other Mac-only tools. The same pattern applies to other MCP servers and CLIs that need a Mac, such as @mobilenext/mobile-mcp or agent-device (ssh nomac npx -y agent-device ...). We have not tested those.

Add NoMac's own MCP server next to it (claude mcp add nomac -- npx @nomac/cli mcp) for signing and TestFlight. Device feedback comes from TestFlight on a real iPhone. Every Simulator command still crosses the network, so the loop is slower than a Simulator on your own desk. To run the agent itself on the Mac instead, see Claude Code on a cloud Mac. For editing on the Mac, see VS Code and Cursor over Remote-SSH.

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 with MobileBuildMCP

Use MobileBuildMCP to build the scheme for a chosen simulator, on your Mac or on the cloud Mac. 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 MobileBuildMCP for the development 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. Put the tested commit on a clean cloud Mac

After tests pass, commit and push. The agent starts a NoMac Mac and clones that commit into ~/drive/src with exec_mac. The release build must use the same source you reviewed. If a file changes, commit and pull it again.

4. Prove the clean build

Run an unsigned build from that clone. A checkout that has only the commit catches differences a working copy can hide: an uncommitted local file, a scheme that is not shared, or a setting that depends on one keychain.

5. Release to a real phone

Only after the clean build passes, the agent runs set_up_signing, archives and exports the app with the commands it returns, and calls send_to_testflight. Apple processes the build, usually in 5 to 15 minutes. Install from TestFlight and check the same acceptance criteria on a real device.

Common ways to use the wrong tool

• ·Using TestFlight for every visual nudge. Use the Simulator first; make TestFlight builds for meaningful device checkpoints.
• ·Treating a simulator success as release proof. A signed archive from a clean clone still catches project, dependency, signing, and environment problems.
• ·Expecting MobileBuildMCP to manage a cloud Mac. It controls the Mac where its process and Xcode run; starting and stopping that Mac is outside its job.
• ·Leaving the cloud Mac running. It is billed by the minute while it is ready. Stop it when the work is done; the project stays on the account's drive.
• ·Giving both tools a vague “build it” request. Name the 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 MobileBuildMCP for simulator builds, tests, logs, and screenshots;
- do not change signing settings to fix a simulator-only problem.

For a release candidate:
- ensure tests pass, then commit and push;
- start a NoMac Mac and clone that commit into ~/drive/src;
- run an unsigned build there;
- after approval, run set_up_signing, archive, and send_to_testflight;
- stop the Mac when the send is done;
- 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.

MobileBuildMCP closes the development feedback loop, on your Mac or on a cloud Mac. NoMac adds a clean Mac and 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.