Artem Novichkov · 2026-08-13

Headless Xcode：從一句 Prompt 到 Simulator 驗證

Xcode 27 把 MCP server 放進工具鏈後，agent 不必打開 IDE 也能建立 iOS 專案、呼叫 Apple 的 SwiftUI skills、跑 build、渲染 preview，最後在 Simulator 驗證一段完整使用流程。

Published: 2026-08-13Source: Artem NovichkovTopic: Xcode MCP

01 / 啟動

先把 Xcode 變成 MCP server

以命令列啟動 headless server，讓 agent 能透過已定義的工具操作建置、模擬器與預覽；Xcode UI 不再是唯一入口。

02 / 生成

Prompt 之外還要給 skills

文章將 Apple 的 agent skills 與資料流、結構參考一併載入。Prompt 交代意圖，skills 則把 SwiftUI 實作方式與約束帶進上下文。

03 / 驗證

不是 build 成功就結束

先用 RenderPreview 直接取得 PNG，再上 Simulator 測導航與資料變動。每一層都檢查不同風險，避免只靠編譯綠燈。

Key signals

文章示範的，是一條完整而非單點的 agent workflow

Input

Prompt

以自然語言說明要做的 app 與驗證目標，不必用座標或 UI 操作腳本指揮 agent。

Context

Skills

SwiftUI 專用能力與專案結構參考，降低「能跑但不符合慣例」的生成結果。

Evidence

PNG + build

Preview render 加上編譯結果，讓視覺與程式結構都能被明確檢查。

Behavior

Simulator

用連續使用情境驗證導航、輸入與資料傳遞，而非把每個畫面當成獨立截圖。

Workflow

從需求到可觀察結果的六步回路

啟動 server，先處理權限邊界

Headless MCP server 必須先取得可操作 Xcode 與模擬器的授權。這個確認動作不是瑣事：它明確劃出 agent 在本機可做什麼，並避免隱性權限變成日後的不可解釋行為。

以 prompt 建專案，再由 skills 填入專業上下文

文章的核心做法不是只丟一句「做個 app」。它讓 agent 同時讀取 SwiftUI skill、資料流與結構參考，在生成時掌握模型、store、row 與 section 的責任分界。

BuildProject 先回答：專案能否真的編過

自動生成最基本的門檻仍是可建置。建置工具回傳結果與錯誤，讓 agent 能修正實際編譯問題，而不是只根據文字自信地宣稱完成。

RenderPreview 讓 agent 看見畫面

Preview 可在不打開 Xcode Canvas 的情況下產生 PNG。文章特別提醒：多個 state 的 render 要真的被檢視，因為單一成功訊號抓不到間距漂移、換行與狀態不一致。

Simulator 把畫面串回使用行為

Preview 適合單一畫面；導航、文字輸入與資料更新則需要跑完整 app flow。驗證語句維持在使用者意圖層級，工具細節交給 agent 與 MCP。

保留證據，讓下一輪可以迭代

build 回報、render 圖與 simulator 結果共同構成可檢討的輸出。這把「看起來做完」升級成能重跑、能比較、能找差異的工程回路。

Verification stack

三層驗證各自回答不同問題

Build：程式是否可交付？編譯能抓型別、API、專案設定與資源問題。它是必要條件，但不能證明畫面正確或流程通順。

Preview：畫面是否像預期？對 loading、empty、loaded、failed 等 state 做 render，檢查版面、文案換行與狀態差異；將多張圖集中比較更有效。

Simulator：行為是否連貫？模擬器能驗證跨畫面的導航、輸入與資料變動，例如將讀完的書移出清單後再新增一筆資料。

Artifact：結果是否容易被人審閱？把 render 整理成單一 HTML artifact，可讓團隊在同一個脈絡看所有狀態、裝置與外觀設定，而不是交換零散檔案。

Practical takeaways

要採用這條路，先守住這四個原則

把 prompt 寫成驗收意圖，而不是操作步驟描述「完成後應看到什麼」與「哪個流程要成立」，比指定點哪裡更能讓 MCP 工具鏈發揮；同時也保留實作替換的空間。

skills 是工作規格的一部分一段 prompt 很難涵蓋 architecture、SwiftUI 資料流與團隊慣例。把這些規則放在可重用的 skills，可降低每次生成都從零校準的成本。

視覺驗證要有「看圖」這一步render 成功不等於設計正確。要求 agent 檢視 PNG、對照各 state，才能讓自動化真的涵蓋 UI 的細節風險。

權限與成本應先被顯式管理headless 操作會引入本機授權、server 維護與 agent token／執行時間成本。把允許範圍、何時升級到 simulator、何時只做 preview 先寫清楚。

Trade-offs

Headless 不等於沒有代價

少了 Canvas 的即時手感CLI 與 MCP 很適合可重複任務；但探索設計細節時，開著 Xcode Canvas 仍可能更快。兩者可以依工作階段混用。

工具版本是相依條件文章基於 Xcode 27 與其 MCP 能力。實際導入前，要把 Xcode、macOS、Simulator 與 agent client 的版本列為環境前提。

自動生成仍需要審閱skills 與驗證回路能提高可靠性，卻不能代替產品判斷、可及性檢查與安全敏感操作的人類覆核。

輸出物可能需要整理PNG、artifact、build log 和測試結果若沒有命名與保存策略，很快會變成難以比對的雜訊；證據也需要被產品化。

References

來源

Artem Novichkov — Headless Xcode: From Prompt to Simulator with MCP本文依原文示範流程整理；原文發布於 2026-08-13。