兩個 MCP 伺服器讓 Claude Code 變成 iOS 建置系統

我用 Claude Code 開發 11 個 iOS 應用程式。我有守護 Git 安全的 hooks、強制執行程式碼品質的規則，以及編碼團隊模式的代理定義。但在昨天之前，每次建置錯誤都意味著複製終端機輸出、貼回去，然後祈禱代理能理解上下文。模擬器管理靠的是原始的 xcrun simctl 指令。測試結果則是一堆毫無結構的文字牆。

兩條 claude mcp add 指令改變了這一切。

重點摘要

XcodeBuildMCP（76 個工具，開源）負責建置、測試、模擬器、實機部署和 LLDB 除錯——全部無需開啟 Xcode。Apple 原生的 Xcode MCP（20 個工具，隨 Xcode 26.3 提供）橋接到正在執行的 Xcode 程序，提供檔案操作、即時診斷、文件搜尋、Swift REPL 和 SwiftUI 預覽。兩者結合讓 Claude Code 能完整地以程式化方式存取 iOS 開發工具鏈——用結構化 JSON 取代日誌解析，用工具呼叫取代 shell 指令。設定只需不到 2 分鐘。

缺口

Claude Code 在讀寫 Swift 方面表現卓越。它理解 SwiftUI 模式、SwiftData 關聯和 Swift 6 並行處理。但它對建置系統是盲的。

當建置失敗時，代理必須：

1. 透過 Bash 執行 xcodebuild
2. 解析數千行無結構的輸出
3. 期望能在雜訊中找到實際的錯誤
4. 猜測是哪個檔案和哪一行造成了失敗

當我想執行測試時：

1. 代理從記憶中組建完整的 xcodebuild test 指令
2. 解析 xcresult bundle（或者更常見的情況，解析原始 stdout）
3. 嘗試分辨哪些測試通過、哪些失敗

這等同於要求開發者透過鑰匙孔閱讀編譯器輸出來寫程式碼。資訊技術上確實存在，但介面是錯的。

解決方案：兩個互補的 MCP 伺服器

XcodeBuildMCP（社群版，開源）

XcodeBuildMCP 將 xcodebuild 及相關工具封裝成 76 個結構化 MCP 工具。代理呼叫 xcode_build 後會收到包含分類錯誤、警告和檔案位置的 JSON——而不是 3,000 行的建置日誌。

主要工具：

安裝：

claude mcp add XcodeBuildMCP \
  -s user \
  -e XCODEBUILDMCP_SENTRY_DISABLED=true \
  -- npx -y xcodebuildmcp@latest mcp

-s user 旗標使其成為全域設定——在每個專案中都可使用，無需逐專案設定。環境變數停用遙測功能（預設會將當機報告傳送至 Sentry；我偏好選擇退出）。¹

Apple Xcode MCP（原生，隨 Xcode 26.3 提供）

Apple 在 Xcode 26.3 中透過 xcrun mcpbridge 提供了自己的 MCP 伺服器。它公開了 20 個工具，透過 XPC 直接橋接到 Xcode 的程序：

安裝：

claude mcp add --transport stdio xcode -s user -- xcrun mcpbridge

需要 Xcode 26.3+（目前為 Release Candidate，即將正式推出）。

為什麼兩者都需要？

它們在建置和測試上有所重疊，但架構不同：

• XcodeBuildMCP 透過 xcodebuild CLI 獨立運作——不需要 Xcode 程序。它提供 76 個工具，涵蓋模擬器、實機、LLDB 除錯、UI 自動化和專案鷹架。適合無頭工作流程和類 CI 開發。
• Apple Xcode MCP 需要一個正在執行的 Xcode 實例，並透過 XPC 通訊。它提供 Xcode 專案上下文中的檔案操作、即時程式碼診斷（不僅是建置輸出），以及包含 WWDC 講座在內的原生文件搜尋。

我兩者都使用：XcodeBuildMCP 用於建置-測試-除錯循環（無需開啟 Xcode 即可運作），Apple 的 MCP 則用於文件查詢、Swift REPL 驗證或 SwiftUI 預覽渲染。

實戰測試

我用以下提示詞對我的 Water 應用程式（SwiftUI + Metal 流體模擬 + HealthKit）執行了完整的健康檢查：

Use the XcodeBuildMCP and Apple Xcode MCP tools to do a full
health check of this project:

1. List available simulators and boot an iPhone 16 Pro
2. Build the project for that simulator
3. Run existing tests and report pass/fail results
4. Search Apple docs for "HealthKit water intake"
5. Use the Swift REPL to verify HKQuantityType(.dietaryWater)

發生了什麼

模擬器設定使用了 list_sims、session_set_defaults 和 boot_sim。代理發現 iOS 26 執行環境中不存在 iPhone 16 Pro（它已被淘汰），所以自動切換到 iPhone 17 Pro。這種適應性行為在硬編碼的 xcodebuild 指令中是做不到的。

建置最初失敗了——新的 Xcode 安裝尚未下載 Metal Toolchain。代理從結構化錯誤輸出中偵測到這一點，並執行 xcodebuild -downloadComponent MetalToolchain 來修復。之後建置成功，有 3 個警告：

HomeView.swift:132    UIScreen.main deprecated in iOS 26.0
LogWaterIntent.swift:61   Result of try? is unused

結構化輸出意味著這些警告以分類形式回傳，附帶精確的檔案:行號參考，而非埋在日誌深處。

測試失敗了——但失敗資訊很有參考價值。結構化輸出顯示有 5 個測試方法引用了 injectTapRipple(atNormalizedX:)，這是我在先前的提交中移除的方法。代理識別出確切的提交（7657068 — "remove tap ripple interaction entirely"）並列出了需要更新的測試。零歧義。

文件搜尋和 Swift REPL 確認了 HKQuantityType(.dietaryWater) 是有效的，回傳識別碼 HKQuantityTypeIdentifierDietaryWater。

結果表

整個健康檢查自主完成。我沒有開啟 Xcode，沒有複製任何錯誤訊息，也沒有組建任何 xcodebuild 指令。

教導代理

安裝 MCP 伺服器並不夠。代理需要知道這些工具的存在，以及何時應該優先使用它們而非原始 shell 指令。我更新了 ios-developer 代理定義，加入了明確的指引：

## Build & Test Tools (XcodeBuildMCP)

Prefer MCP tools over raw xcodebuild commands:

- **Build**: Use `build_sim` / `build_device` for structured errors
- **Test**: Use `test_sim` / `test_device` for pass/fail results
- **Simulators**: Use `list_sims`, `boot_sim`, `open_sim`
- **Debug**: Use `debug_attach_sim`, `debug_stack`, `debug_variables`

## Apple Xcode MCP (mcpbridge)

- **Documentation**: Use `DocumentationSearch` for Apple docs
- **Swift REPL**: Use `ExecuteSnippet` for API verification
- **Previews**: Use `RenderPreview` for headless SwiftUI rendering

Prefer these over WebSearch for Apple API questions
and over Bash `swift` for REPL tasks.

若缺少這段指引，代理有時會退回到透過 Bash 使用 xcodebuild，或用 WebSearch 搜尋 Apple 文件而非使用原生搜尋。代理定義填補了這個落差。²

實際工作流程的改變

MCP 之前，我使用 Claude Code 的 iOS 工作流程是：

1. 用 Claude 撰寫程式碼
2. 在 Xcode 中手動建置（或在終端機中透過 xcodebuild）
3. 將錯誤複製回 Claude
4. 重複

MCP 之後：

1. 描述我想要的功能
2. Claude 撰寫程式碼、建置、讀取錯誤、修復、執行測試，並驗證 API 行為
3. 我審閱最終結果

過去需要我主動參與的建置-錯誤-修復循環，現在自主完成。代理不再從原始文字中猜測出了什麼問題——它讀取結構化資料，精確地知道什麼失敗了、在哪裡、為什麼。

這是我在 AI 工具中反覆看到的模式：突破並非讓 AI 更聰明，而是讓它以結構化方式存取開發者已經在用的工具。 MCP 是實現這一點的協定——正如 hooks 賦予 Claude Code 確定性的護欄，MCP 賦予它確定性的工具介面。Xcode 不是第一個、也不會是最後一個透過 MCP 公開自身的開發工具。³

設定清單

給所有用 Claude Code 開發 iOS 專案的人：

1. 安裝 XcodeBuildMCP（需要 Xcode 26.3+）： bash claude mcp add XcodeBuildMCP -s user \ -e XCODEBUILDMCP_SENTRY_DISABLED=true \ -- npx -y xcodebuildmcp@latest mcp

2. 安裝 Apple Xcode MCP（需要 Xcode 26.3+）： bash claude mcp add --transport stdio xcode \ -s user -- xcrun mcpbridge

3. 驗證兩者都已連接： bash claude mcp list # XcodeBuildMCP: ... - Connected # xcode: xcrun mcpbridge - Connected

4. 更新您的代理定義以引用新工具（否則代理有時會退回到 shell 指令）。

5. 啟動新的 Claude Code 工作階段——在工作階段中途註冊的 MCP 工具，在重新啟動前不會出現在工具搜尋中。

就這樣。兩條指令，完整的 iOS 建置系統存取權。

常見問題

我還需要安裝 Xcode 嗎？

需要。兩個 MCP 伺服器都是 Xcode 工具鏈（xcodebuild、xcrun、simctl）的封裝。Xcode 必須安裝並設定好。MCP 伺服器讓 Claude Code 以結構化方式存取這些工具——它們並不取代這些工具。

XcodeBuildMCP 能用於純 SwiftPM 專案嗎？

可以。XcodeBuildMCP 同時支援 .xcodeproj/.xcworkspace 和 Swift Package Manager 專案。使用 discover_projs 來尋找可用的專案類型，然後使用 build_sim 或 build_device 搭配適當的 scheme。

CI/CD 管線呢？

MCP 伺服器在 Claude Code 本機端執行。對於 CI/CD，您應繼續直接使用 xcodebuild 或 Fastlane 等工具。MCP 方案專門用於互動式開發循環，即 AI 代理在程式碼-建置-測試循環中需要結構化回饋的場景。