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

一個Claude Code工作階段若指向沒有Xcode MCP伺服器的iOS專案,就如同盲人摸象。代理程式可以讀取Swift檔案、寫入Swift檔案,並透過Bash工具執行xcodebuild,但每個建置錯誤都意味著要解析數千行非結構化輸出。模擬器管理只剩下原始的xcrun simctl指令。測試結果以一整面文字牆的形式湧現,代理程式得從中掃描出失敗項目。

您可以透過新增兩個MCP伺服器,讓Claude Code獲得完整的Xcode整合:XcodeBuildMCP(v2.3.2版本宣稱在建置、測試、模擬器與LLDB除錯方面提供82個工具),以及Apple隨Xcode 26.3一同推出的原生Xcode MCP(20個工具,涵蓋檔案操作、診斷與SwiftUI預覽)。 兩者都只需要單一的claude mcp add指令。兩者協同運作,以結構化的JSON回應取代非結構化的建置記錄解析,讓代理程式能精確掌握錯誤位置、每個方法的測試結果,以及程式化的模擬器控制。

兩道claude mcp add指令改變了一切。MCP(Model Context Protocol)是一項開放標準,規範定義於modelcontextprotocol.io,讓AI代理程式能透過結構化的JSON請求與回應,呼叫外部系統上的工具:概念與REST API相同,但專為代理程式對工具的通訊而設計。⁵

TL;DR

XcodeBuildMCP(開放原始碼,根據v2.3.2文件目前提供82個MCP工具)在無需執行Xcode的情況下,處理建置、測試、模擬器、實機部署與LLDB除錯。Apple原生的Xcode MCP(20個工具,隨Xcode 26.3以xcrun mcpbridge形式推出)橋接到正在執行的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與相關工具封裝成結構化的MCP工具(目前v2.3.2目錄中有82個)。代理程式呼叫build_sim後,取回的是包含已分類錯誤、警告與檔案位置的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的行程中。重要警告: 截至2026年5月,Apple尚未發布MCP伺服器的獨立文件。下方的工具清單是根據作者的測試與Rudrank Riyam的早期分析所整理。工具名稱與功能可能在未來的Xcode版本中變動:

安裝方式:

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

需要Xcode 26.3以上版本。

為何兩者都要?

它們在建置與測試上有所重疊,但架構不同:

• XcodeBuildMCP 透過xcodebuild CLI獨立運作,無需Xcode行程在執行中。目錄涵蓋面廣(截至v2.3.2有82個MCP工具),涵蓋模擬器、實機、LLDB除錯、UI自動化與專案鷹架。獨立式架構的重要性在於能支援無頭工作流程:代理程式可以在不開啟Xcode的情況下進行建置與測試,速度更快、佔用的系統記憶體也更少。
• Apple Xcode MCP 需要Xcode執行個體在執行中,並透過XPC(Apple的行程間通訊框架)進行通訊。它在Xcode專案環境中提供檔案操作、即時程式碼診斷(不只是建置輸出),以及包含WWDC議程的原生文件搜尋。XPC橋接的重要性在於它能公開Xcode的內部狀態(即時診斷、已解析的符號、預覽算繪),這些是任何CLI工具都無法存取的。

我兩者並用:XcodeBuildMCP負責建置-測試-除錯循環(它在Xcode未開啟時也能運作),Apple的MCP則用於需要文件查詢、Swift REPL驗證或SwiftUI預覽算繪時。

當AI代理程式透過Bash執行xcodebuild時,它收到的是一串非結構化文字,必須透過啟發式方法解析,猜測錯誤從何處開始與結束、從部分匹配中推斷檔案路徑,並期望格式沒有變動。當同一個代理程式透過MCP呼叫build_sim時,它收到的是JSON回應,內含已分類的錯誤、警告、檔案路徑與行號,全部都在可預測的欄位中。代理程式的任務從解析轉變為推理。對於以LLM為基礎的代理程式,差異更為關鍵:每個字元的非結構化建置輸出都會消耗context window的token,這意味著一份3,000行的建置記錄,可能在代理程式找到那個唯一重要的錯誤之前,就耗盡了工作記憶。結構化的JSON回應讓代理程式能直接讀取錯誤,而不是去搜尋它。MCP並未讓代理程式變得更聰明,而是讓代理程式收到的資訊變得可讀。

真實世界測試

我使用以下提示詞,對我的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

結構化輸出意味著這些警告以分類的形式回來,並附有確切的file:line參考,而不是埋藏在記錄中。

測試 失敗了,但失敗訊息很有資訊性。結構化輸出顯示有5個測試方法引用了injectTapRipple(atNormalizedX:),而這個方法我在前一個commit中已移除。代理程式找出了確切的commit(7657068, "remove tap ripple interaction entirely"),並列出哪些測試需要更新。毫無模糊空間。

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

結果表格

整個健康檢查在大約90秒內自主完成,包含模擬器啟動時間。我沒有開啟Xcode、沒有複製任何錯誤訊息、也沒有建構任何xcodebuild指令。在使用MCP之前,同樣的五步驟健康檢查約需8到10分鐘的人工主動參與:撰寫xcodebuild指令、解析輸出、切換到Xcode進行文件搜尋、開啟Swift Playgrounds進行REPL驗證。時間節省並非來自更快的建置(建置時間相同),而是來自消除每個階段之間需要人工解析的步驟。

結構化 vs. 非結構化:代理程式實際看到的內容

差異很具體。以下是同一個建置錯誤透過兩種介面所呈現的樣貌:

透過Bash(xcodebuild原始輸出),47行雜訊圍繞著一個錯誤:

CompileSwift normal arm64 /Users/.../HomeView.swift
...
/Users/blake/Projects/Water/Water/Views/HomeView.swift:132:9:
warning: 'main' is deprecated: Use UIScreen.main in iOS 16.0+
         ^~~~~~~~
** BUILD FAILED **
The following build commands failed:
  CompileSwift normal arm64 .../FluidRenderer.swift
...

代理程式必須解析數千行,猜測錯誤從何處開始與結束,並從部分匹配中推斷檔案路徑,每一行雜訊都消耗context window的token。

透過MCP(build_sim結構化回應),確切錯誤位於可預測的欄位中(為示意而簡化;實際回應包含建置時間與scheme等額外欄位):

{
  "status": "failed",
  "errors": [{
    "file": "FluidRenderer.swift",
    "line": 89,
    "message": "Cannot find 'MTLPixelFormat' in scope",
    "severity": "error"
  }],
  "warnings": [{
    "file": "HomeView.swift",
    "line": 132,
    "message": "'main' is deprecated in iOS 26.0",
    "severity": "warning"
  }]
}

代理程式直接讀取錯誤、識別檔案與行數,並開始思考修復方法。沒有解析、沒有猜測、沒有浪費的token。context window的成本從數千個token降到數十個。

教導代理程式

僅僅安裝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文件,而非使用原生搜尋。代理程式定義填補了這個缺口。² 若想更廣泛地了解如何將代理程式定義與hooks、skills、rules一同建構,Claude Code指南涵蓋了完整的設定階層。

實務上會改變什麼

在使用MCP之前,我與Claude Code的iOS工作流程是:

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

使用MCP之後:

1. 描述我想要什麼
2. Claude寫程式碼、建置、讀取錯誤、修復、執行測試,並驗證API行為
3. 我審查最終結果

過去需要我主動參與的建置-錯誤-修復循環,現在自主進行。代理程式不再從原始文字中猜測哪裡出錯,而是讀取結構化資料,精確得知失敗為何、發生在何處、原因為何。

突破點不在於讓AI更聰明,而在於讓AI能以結構化方式存取開發者已在使用的工具。 MCP是讓這一切成為可能的協定,正如hooks為Claude Code提供了確定性護欄(實作細節請參閱hooks教學),MCP則為它提供了確定性的工具介面。Xcode不是第一個、也不會是最後一個透過MCP公開自身的開發工具。³

其他開發者也回報了使用MCP建置系統的類似結果。Rudrank Riyam對Apple Xcode MCP工具的詳細解析,確認了本文所述的文件搜尋與Swift REPL功能,並指出了同樣的XPC依賴限制。⁶ 更廣泛的MCP生態系現在包含Docker、PostgreSQL、GitHub與Kubernetes的伺服器,每一個都依循相同模式,將CLI工具封裝在結構化的JSON介面中。⁷ Apple的「Meet agentic coding in Xcode」技術講座(涵蓋Xcode 26.3的代理程式功能)將此功能介紹為Apple對AI輔助開發更廣泛投入的一部分,把MCP定位為AI代理程式與開發工具之間的標準介面,而非小眾協定。⁸

結構化介面帶來的效率提升,與AI工具使用的更廣泛研究一致。Jimenez等人的SWE-bench(2024)發現,可存取結構化工具(檔案層級編輯工具、具結構化輸出的測試執行器)的代理程式,解決的GitHub議題,顯著多於僅能使用具非結構化輸出的bash指令的代理程式。⁹ 此模式並非Xcode獨有:結構化工具存取能跨領域提升代理程式表現,因為它將代理程式的任務從解析轉變為推理。

限制與目前的缺口

MCP並非萬靈丹。誠實列出它無法做到的事:

沒有視覺化除錯。 MCP能傳回建置錯誤與測試結果的結構化資料,但無法顯示應用程式的視覺狀態。一個讓視圖偏離中心10像素的版面配置bug,既不會產生建置錯誤,也能通過所有邏輯測試。XcodeBuildMCP中的screenshot與snapshot_ui工具能擷取畫面,但詮釋視覺正確性仍需要人工審查(或另外的視覺模型)。代理程式能建置、執行、測試,但它看不見。

Apple MCP對Xcode行程的依賴。 Apple的xcrun mcpbridge需要Xcode執行個體正在執行。如果Xcode當機或被關閉,透過該伺服器的MCP呼叫便無法成功(橋接依賴於Xcode的行程)。XcodeBuildMCP則直接使用xcodebuild迴避了這一點,但任何橋接到Xcode XPC介面的工具,都會繼承Xcode的行程生命週期。實務上的影響是:在使用文件搜尋或SwiftUI預覽的工作階段中,需要保持Xcode開啟。

沒有增量建置感知。 build_sim工具會執行完整建置。它不知道前一次建置是否成功、也不知道是否只有一個檔案被變更。代理程式每次呼叫都會從頭重建。對於大型專案,這比起支援增量建置的xcodebuild,每個建置週期會增加可察覺的數秒。為了結構化輸出而付出這項代價尚可接受,但這確實是真實的成本。

Apple MCP工具的不穩定性。 您所連接的每個MCP伺服器,都是您正在延伸的信任邊界,而安全性影響是真實存在的,MCP攻擊面分析記錄了整個生態系中的50個漏洞。Apple在Xcode 26.3中推出MCP伺服器時並未提供公開文件。工具名稱、參數格式與回應結構,可能在未來的Xcode版本中變動,且不會有棄用警告。任何依賴特定Apple MCP工具簽名的程式碼,都應視為暫時性的。XcodeBuildMCP作為開放原始碼且由社群維護的專案,提供更穩定的介面,並有語意化版本控制與變更日誌。⁴

沒有程式碼簽署診斷。 配置設定檔錯誤、憑證不符與權限衝突,是iOS開發中最不透明的建置失敗類型之一。兩個MCP伺服器都未對程式碼簽署問題提供結構化診斷,僅有原始錯誤訊息。代理程式收到的是「Code signing failed」加上一個檔案路徑,而不是「您的配置設定檔已於2月15日過期」或「此權限需要特定的App ID前綴」。程式碼簽署仍是一個需要人工除錯的領域。

設定檢查清單

對於以iOS專案執行Claude Code的任何人:

1. 安裝XcodeBuildMCP(需Xcode 16以上、macOS 14.5以上): 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建置系統存取權。

設定後可以試試: 請Claude Code「為模擬器建置此專案,並回報任何錯誤」。將回應與您透過Bash執行xcodebuild -scheme YourScheme -sdk iphonesimulator build所得的輸出做比較。MCP回應將錯誤依檔案與嚴重程度分類,呈現於結構化欄位中。原始的xcodebuild輸出則將相同資訊埋藏在數千行交織的編譯器輸出中。這個差異在第一個建置錯誤出現時就會立刻顯現。

重點摘要

對於使用AI代理程式的iOS開發者:

• 結構化的工具存取改變了代理程式的能力範圍。 「代理程式寫程式碼,然後期望您去建置」與「代理程式寫程式碼、建置、讀取錯誤、修復」之間的差距,正是文字補全工具與開發夥伴之間的差距。MCP透過給予代理程式結構化JSON,而非非結構化建置記錄,彌合了這個差距。

• 兩個MCP伺服器涵蓋互補的需求。 XcodeBuildMCP在Xcode未開啟時也能運作(無頭建置、模擬器、除錯)。Apple的Xcode MCP橋接到正在執行的Xcode行程(診斷、文件、SwiftUI預覽)。兩者並用,以完整覆蓋iOS開發工作流程。

對於評估MCP用於其他工具鏈的工程師:

• 此模式可推廣至Xcode之外。 任何輸出非結構化文字的開發工具(編譯器、linter、測試執行器、套件管理員),在被封裝於結構化MCP介面後,對AI代理程式而言都會更有用。協定本身不如這項洞見重要:當資訊以可預測的欄位而非可變格式的記錄抵達時,代理程式能更好地推理。

• 代理程式定義填補了最後一哩的缺口。 安裝MCP伺服器是必要的,但還不夠。代理程式定義中明確的指引(「優先使用build_sim而非xcodebuild」)可避免代理程式在結構化替代方案存在時,仍回退到shell指令。

完整的Apple生態系叢集:App Intents vs MCP探討跨介面的路由問題;與iOS應用程式並存的MCP伺服器介紹應用內伺服器模式;Foundation Models代理程式工作流程解析應用內vs工具LLM的分工;三種介面說明更廣泛的iOS應用介面模型。中心節點位於Apple生態系列。iOS代理程式開發指南更詳細地涵蓋MCP驅動的完整工作流程,包括模擬器管理與測試驅動模式。

FAQ

我仍需要安裝Xcode才能將MCP與Claude Code一同使用嗎?

是的。兩個MCP伺服器都是Xcode工具鏈(xcodebuild、xcrun、simctl)的封裝層。Xcode必須安裝並設定好。MCP伺服器讓Claude Code能以結構化方式存取這些工具,但並未取代它們。

XcodeBuildMCP能與純SwiftPM專案一同運作嗎?

可以。XcodeBuildMCP支援.xcodeproj/.xcworkspace與Swift Package Manager專案。使用discover_projs找出可用的專案類型,再以適當的scheme使用build_sim或build_device。

那CI/CD流水線呢?

MCP伺服器在本機與Claude Code一同運行。對於CI/CD,您仍可繼續直接使用xcodebuild或Fastlane這類工具。MCP方法專門針對的是互動式開發循環,在這個循環中,AI代理程式在程式碼-建置-測試週期中需要結構化的回饋。

什麼是MCP,它對AI開發工具為何重要?

Model Context Protocol(MCP)是一項開放標準,定義AI代理程式如何透過結構化的JSON請求與回應,與外部工具進行通訊。在MCP出現之前,代理程式與開發者工具的互動方式,是執行shell指令並解析其非結構化文字輸出,這種脆弱的方法在輸出格式變更時會失效,並會浪費context window的token於雜訊上。MCP標準化了介面:代理程式發送結構化請求(帶有參數的build_sim),工具則傳回結構化回應(包含已分類錯誤、檔案路徑與行號的JSON)。代理程式的任務從解析轉變為推理。MCP之於AI代理程式工具,正如REST之於網路API:一項共享協定,讓任何工具都能向任何代理程式公開結構化能力。