Apple’s Xcode MCP built my app in 2.1s.
Then it was basically done.
It built the open Xcode project, gave me a clean log, and dropped the output in Debug-iphoneos/Meteora.app. Nice. Except that was a device build, not simulator.
No tool to switch run destination. No boot simulator. No install. No launch. I had to manually change Xcode to a simulator, rebuild, then use simctl outside the MCP.
The moment it clicked
Then I tried XcodeBuild MCP.
I set projectPath, scheme, simulatorId, and later bundleId. Then I ran this:
session_set_defaults(...)
build_sim()
get_sim_app_path(...)
install_app_sim(...)
launch_app_sim()
It built, installed, launched, opened Simulator, and let me capture a screenshot of the running app. First run took 79.1s. Warm rebuild dropped to 42.3s.
That timing wasn’t apples to apples though. Apple’s 2.1s was build-only. The 42.3s XcodeBuild MCP number was the whole loop: build, resolve app path, install, and launch.
When I timed the steps separately, build_sim() was only 9.7s. get_sim_app_path() took 14.0s, install took 19.1s, and launch took 13.8s. The simulator loop was the slow part, not compilation.
These tools are solving different problems
Apple Xcode MCP feels like remote hands for the currently open Xcode tab. If Xcode is already pointed at the right scheme and destination, it builds fast and tells you what happened. It knows what it is.
But that’s also the problem. It stops at build.
XcodeBuild MCP feels like giving the agent an actual iOS workflow. It can target a simulator, reuse DerivedData, install the app, launch it, open Simulator, grab screenshots, and capture logs.
That’s what an agent needs if it’s going to verify its own work instead of declaring victory after compile.
The feedback gap is the whole game
If the question is “can the agent build, run, inspect, and keep going without bothering me every 30 seconds,” XcodeBuild MCP wins easily.
Build success is cheap. Feedback loops are expensive.
An agent that can only build is basically a polite intern standing next to the elevator. An agent that can build, launch, screenshot, and read logs can close the loop.
The annoying gotcha
XcodeBuild MCP isn’t perfect. I hit one dumb issue where launch_app_logs_sim() refused to run because bundleId was missing.
session_set_defaults({ bundleId: "com.stardust.Meteorite", persist: false })
After that, the workflow was smooth. Its the kind of friction I can live with.
Which one I’d use
I’d use XcodeBuild MCP as the default.
I’d keep Apple Xcode MCP around for 2 cases: when I explicitly want the official Apple path, or when I want to sanity check the open Xcode tab.
But if I’m asking an agent to do real iOS work, I want the one that can get the app onto a simulator and show me the result.
Right now, that’s not a close call.