Use Xcode MCP Instead of xcodebuild to Save Disk Space and Time in Agentic iOS Development

The Agentic Development Disk Space Trap

When doing AI-driven iOS development, one of the most common approaches is to have our agent operate via the command line (xcodebuild), while you might be doing some debugging / UI verification in the GUI (Xcode.app). Because DerivedData folders frequently exceed 10GB–20GB for modern apps, maintaining separate build directories for the human and the agent wastes massive amounts of SSD space. It also wastes time, as the agent cannot benefit from the compilation work you just completed in Xcode.

It is tempting to pass -derivedDataPath to your agent's xcodebuild commands, pointing it exactly at your live Xcode workspace's DerivedData. The goal is to have the agent "pick up where you left off." I found that sharing the directory destroys the incremental state for both tools instead.

Showing That It Fails

You can run a targeted test on any active project to see the time penalty yourself. Set your project variables:

cd /path/to/repo/iOS
WORKSPACE=GoodNotes.xcworkspace
SCHEME=GoodNotes
# A booted/available simulator UDID - adjust as needed:
SIM_UDID=$(xcrun simctl list devices available | grep -oE '[0-9A-F-]{36}' | head -1)
# Your Xcode's DerivedData folder location
DD=/path/DerivedData

Enable build durations in Xcode to accurately read the GUI's timings:

defaults write com.apple.dt.Xcode ShowBuildOperationDuration -bool YES
# Restart Xcode after running this

• Step 1 - Build in Xcode (⌘B), then build again. The second build is a fast, no-op incremental build.
• Step 2 - Run xcodebuild against the same DerivedData. Use the exact same scheme, destination, and DerivedData path with no source changes:

xcodebuild build \
  -workspace "$WORKSPACE" \
  -scheme "$SCHEME" \
  -destination "platform=iOS Simulator,id=$SIM_UDID" \
  -derivedDataPath "$DD" \
  -skipMacroValidation \
  -skipPackagePluginValidation \
  -skipPackageUpdates

Despite no code changing, the CLI executes a full rebuild. It recompiles, relinks, and re-signs the application instead of acting incrementally relative to Xcode's previous build.

• Step 3 - Build in Xcode again (⌘B). The build becomes slow again. The CLI run overwrote the shared object files and .swiftmodules on disk. Because the intermediate files were modified by a different build driver, Xcode is forced to rebuild a massive portion of the graph.

The Verified Time Penalty

Here is the exact performance penalty measured on the app I'm working on:

By forcing xcodebuild into Xcode's DerivedData, the CLI build ran slower than a clean build, and it dragged Xcode's subsequent incremental build from 22.7 seconds up to 300.8 seconds (a ~13× slowdown).

The Solution: Drive Xcode via MCP

Using Xcode MCP, I was able to save SSD space by using a single DerivedData directory, and maintain fast incremental build times. To accomplish this, use the Xcode MCP bridge (xcrun mcpbridge), introduced in Xcode 26.

When your agent uses xcrun mcpbridge to trigger a build:

• The BuildProject tool calls Xcode.app's internal build system.
• The build executes entirely incrementally, relying exactly on the state you just generated in the GUI.
• Disk space is strictly limited to one DerivedData folder per project.

Look at this page from Apple to see how to enable this for Claude / Codex. In my experience, after running the mcp add command, you can simply ask the agent to use Xcode MCP and it knows what to do.