Exploring MCP: XcodeBuildMCP for Faster Incremental Builds in VS Code, Cursor & Windsurf

In my previous post, I wrote an introduction to XcodeBuildMCP, a MCP server to help AI-IDEs like VS Code, Cursor, and Windsurf bridge with the Xcode build system.

Exploring MCP: XcodeBuildMCP for Building & Running iOS Projects in VS Code, Cursor & Windsurf
Explore XcodeBuildMCP, an MCP server that bridges AI assistants with iOS development tools. Discover projects, build for simulators, install and launch apps—all without leaving your editor. Reduce context switching without Xcode in your iOS development workflow through the Model Context Protocol.

I explored how to build, run, and manage simulators directly from your preferred editor, minimizing context switching.

The dream, as always, is that one single, environment for AI-powered iOS development. While XcodeBuildMCP brought us closer by handling build and run commands, one friction point remained: the speed of iterative builds.

GitHub - cameroncooke/XcodeBuildMCP: A Model Context Protocol (MCP) server that provides Xcode-related tools for integration with AI assistants and other MCP clients.
A Model Context Protocol (MCP) server that provides Xcode-related tools for integration with AI assistants and other MCP clients. - cameroncooke/XcodeBuildMCP

Every time I asked the assistant to build after a small change, it triggered a full xcodebuild, which, depending on the project size, could take a significant amount of time. This slows down the rapid feedback loop for which using an AI assistance made sense, especially for autonomous error checking and fixing.

But Cameron has been cooking with much faster incremental builds, thanks to the integration of a tool called xcodemake, you can now slash those build times dramatically after the initial compilation.

Let's explore how this works and how to enable it!

The Need for Speed: Why Incremental Builds Matter

When working iteratively, especially with an AI assistant making changes or when you are rapidly prototyping, you often build and run again after minor code adjustments.

Running xcodebuild from scratch each time involves significant overhead: launching the build system, checking dependencies, and unnecessarily recompiling unchanged files.

An incremental build system is smarter. It aims to recompile only the files that have actually changed (and their dependents), leading to much faster builds after the first one. Xcode itself does this internally, but invoking xcodebuild externally often loses some of that efficiency.

For AI workflows where you might ask the assistant to "build and check for errors" frequently, this time difference is the amount that you spend doom-scrolling on socials.

xcodemake for Xcode Builds via Makefiles

To achieve faster external builds, XcodeBuildMCP now has experimental support for xcodemake.

GitHub - johnno1962/xcodemake: Faster xcodebuilds using “make”
Faster xcodebuilds using “make”. Contribute to johnno1962/xcodemake development by creating an account on GitHub.

Here is the core idea behind xcodemake, directly from its documentation:

xcodemake is a script that logs xcodebuild output to generate a Makefile for an Xcode project. [...] Once the Makefile has been generated you can use the "make" command for incremental builds which is generally considerably faster. Note however, xcodemake only recompiles program source changes, not resources or other binary aspects of an app bundle. [...]

It's intended for folks looking to build their project outside Xcode, for example, using extenal editors such as VSCode or Cursor. When you use xcodebuild you're pretty much launching the entire Xcode app from scratch in order to perform a each single build. Converting the build into a Makefile will be faster as make is exceptionally lightweight [...].

Essentially, xcodemake observes a full xcodebuild once, figures out the necessary compilation steps, and translates them into a Makefile. Subsequent builds can then use the standard, lightweight make command, which figures out the minimal set of files needing recompilation based on modification times.

Enabling Incremental Builds in XcodeBuildMCP

The integration within XcodeBuildMCP of xcodemake is currently an experimental feature, so keep that in mind.

To turn it on, you need to use the 1.4.0 beta and add INCREMENTAL_BUILDS_ENABLED: "true" to the env section of the configuration in your editor's MCP settings file.

Here is how it would look in Cursor:

{
  "mcpServers": {
    "XcodeBuildMCP": {
      "command": "mise",
      "args": [
        "x",
        "npm:xcodebuildmcp@1.4.0-beta.1",
        "--",
        "xcodebuildmcp"
      ],
      "env": {
        "INCREMENTAL_BUILDS_ENABLED": "true" // <-- Enable incremental builds
      }
    }
    // ... other MCP servers
  }
}

For VS Code:

{
  "mcp": {
    "servers": {
      "XcodeBuildMCP": {
        "command": "mise",
        "args": [
          "x",
          "npm:xcodebuildmcp@1.4.0-beta.1",
          "--",
          "xcodebuildmcp"
        ],
        "env": {
          "INCREMENTAL_BUILDS_ENABLED": "true" // <-- Enable incremental builds
        }
      }
      // ... other MCP servers
    }
  }
}

After saving the configuration, your editor should pick up the change.

Incremental Builds in Action

I tested this on an MLX (Apple's ML framework) project I am working on:

First Build

The first time I asked Cursor (using Gemini 2.5 Pro) to build the project for the simulator after enabling the feature, XcodeBuildMCP detected it needed to generate the Makefile.

Called MCP tool `ios_simulator_build_by_name_project`

Parameters:
{
  "projectPath": "...",
  "simulatorName": "iPhone 16 Pro",
  "scheme": "MLXDestinex"
}

Result:
ℹ️ Using xcodemake for faster incremental builds.
ℹ️ Generating Makefile with xcodemake (first build may take longer)
... (Standard xcodebuild output) ...
✅ iOS Simulator Build build succeeded for scheme MLXDestinex.

This initial build took roughly 63 seconds, similar to a standard xcodebuild, as xcodemake needed to observe the full process.

Subsequent Builds

Next, I deliberately introduced several syntax errors into one of the Swift files. I then asked Cursor:

Fix and build

Cursor identified the errors, applied the fixes, and triggered the build. This time, the output was different:

Called MCP tool `ios_simulator_build_by_name_project`

Parameters:
{
  "projectPath": "...",
  "simulatorName": "iPhone 16 Pro",
  "scheme": "MLXDestinex"
}

Result:
ℹ️ Using xcodemake for faster incremental builds.
ℹ️ Using make for incremental build
... (make build output, only showing the changed file being recompiled) ...
✅ iOS Simulator Build build succeeded for scheme MLXDestinex.

The key messages are Using xcodemake for faster incremental builds and Using make for incremental build.

And the build time? Less than 2 seconds!

0:00
/0:29

I repeated this, making a small change, asking the AI to build, and consistently saw these sub-2-second build times!

Moving Forward

I defined a cursor rule like:

Build and run the project everytime you implement a feature or fix an issue. If there are any errors or warnings, analyze and fix them and rebuild the project until it succeeds.

Previously, the build step could take a minute or more (for bigger projects) each time, making such autonomous loops painfully slow.

With incremental builds, this step potentially drops to many seconds after the initial build. And it is fun to watch Cursor iterate at a speed that would expect from Xcode's build system!

But remember, this feature is explicitly marked as experimental in XcodeBuildMCP. While it worked well in my testing for one project, it had issues with derived data in a much bigger project. I have already reported the issue and you can do so here:

Issues · cameroncooke/XcodeBuildMCP
A Model Context Protocol (MCP) server that provides Xcode-related tools for integration with AI assistants and other MCP clients. - Issues · cameroncooke/XcodeBuildMCP

As noted in its documentation, xcodemake primarily speeds up the recompilation of program source code. Changes to resources (Assets.xcassets, Storyboards, etc.), project settings, or dependencies might not be picked up correctly by make alone.

In such cases, you might need to trigger a clean build (clean_project or clean_workspace tool in XcodeBuildMCP) to force a full rebuild and regenerate the Makefile.

Happy Faster MCPing!