Codex 新增 iOS 構建外掛：將模擬器畫面串流進瀏覽器，支援熱過載

做過 iOS 開發的人大多體會過這種痛苦：為了看一眼 SwiftUI 元件的效果，Xcode 的 Canvas 經常轉圈轉到懷疑人生，動不動就崩潰斷連。

Codex 似乎打算繞開這個泥潭。它最近加入了一個名為 Build iOS Apps 的外掛，核心是引入了模擬器瀏覽器對映工具。說白了，它直接把本地執行的 iOS 模擬器畫面，即時串流進了 Codex 自帶的應用內瀏覽器。

怎麼把模擬器搬進瀏覽器

這套方案的底層並沒有去魔改蘋果的底層框架，而是用了一套清晰利落的工程化流轉。

當開發者或者 Codex 想要檢視介面時，流程會先通過系統的裝置命令獲取可用模擬器的識別符號，隨後在後臺終端裡執行 serve-sim 服務。

這個服務會把選定模擬器的畫面流媒體化，並在本地輸出一個預覽網址。Codex 的內建瀏覽器只要開啟這個地址，就能直接看到即時執行的 iOS 畫面，甚至在網頁裡完成基本的介面互動。

為了保證執行可靠，它還配了嚴格的清理機制。終端退出時會自動殺掉 serve-sim 輔助程序，防止懸掛程序佔用埠，在建立連線前還會要求驗證是否有真實畫面幀渲染出來，避免把空白網頁當成成功。

丟棄式工程與動態庫熱過載

很多人更關心的可能是另一個問題：SwiftUI 預覽如果脫離了 Xcode，還能不能像本地一樣即時修改、即時生效。

這個外掛交出的答卷挺巧妙。針對可以匯入的 Swift Package 元件，它提供了一個專門的啟動指令碼。它會指向你的程式碼包清單和目標元件，然後在你的原始碼目錄之外，臨時生成一個隨用隨拋的寄宿工程。

這個寄宿工程會被自動編譯並安裝到模擬器中執行，同時預設開啟檔案監聽模式。一旦你修改了 Swift 程式碼，工具不會去重新打包或重啟整個應用，而是直接重新生成動態庫並熱替換進正在執行的程序，幾秒內就能看到新介面。

它完整相容了常見的 PreviewProvider 和較新的 #Preview 語法，支援通過正規表示式過濾要顯示的預覽項，還能用頁面控制器切換不同的預覽變體。

更讓人放心的是它的操作邊界：官方規範明確要求，絕對不要為了跑通預覽去擅自修改使用者的工程檔案、工作空間或構建配置。所有臨時專案都在外部生成，程式碼倉庫始終保持乾淨。

為什麼重要

我們認為，這一步對正在嘗試用 AI 寫完整專案的開發者來說是個非常及時的補丁。

過去讓 AI 寫 iOS 原生程式碼，最大的堵點就是視覺反饋。寫 Web 應用時，AI 能夠輕易調起本地網頁並截圖做驗證；但面對蘋果的封閉生態，AI 往往只能盲寫程式碼，寫完後還要人類去 Xcode 裡點開看排版。現在，模擬器畫面直接進到 Codex 瀏覽器，意味著 AI 可以自己截圖驗證佈局、排查畫素偏差，真正補全了視覺除錯的閉環。

它的設計思路也非常聰明。它沒有硬著頭皮去入侵龐大脆弱的 Xcode 專案檔案，而是把範圍約束在獨立的 Swift Package 內，利用外接寄宿工程加動態庫注入來實現熱過載。這種做法規避了損壞使用者工程配置的風險，把髒活都留給了臨時環境。

當然，侷限同樣明顯。它目前主要面向模組化的 Swift Package，對於那些強耦合在老舊大型工程裡的純業務介面，熱過載並不能直接拿來即用；而且它依然重度依賴本地 Mac 環境和已安裝的 Xcode 模擬器，算不上純雲端的免配置方案。

但整體來看，把模擬器推流和無侵入熱過載結合起來，給原本封閉沉重的移動端 AI 程式設計撕開了一個口子。如果你的專案已經在走模組化路線，這套工具非常值得第一時間試一試。