資料點：Xcode 27.1。 Apple 的 Xcode 27.1 RC 發行說明列有 iPhone Duo Simulator 的已知限制；因此，iPhone Duo 企業 iOS CI 測試可以先納入代表性建置與版面檢查，但不能把模擬器通過當成真實裝置上的完整發布證明。核對 Xcode 27.1 發行說明，正式版與現行限制仍應在採用前重新確認。
最後更新於 2026 年 10 月 25 日；核對來源為 Apple Developer 的 Xcode 發行說明、iPhone Duo 準備指南與設計指南。
本文適合負責企業 iOS 建置與測試基礎設施的 IT、CI 平台、應用、QA 及發布人員。
如果目前只需判斷模擬器能否加入流水線，先看工具鏈與支援邊界。
如果需要制定發布簽核，則應一併檢查未覆蓋項目、實機補測責任和回退條件。
iPhone Duo 企業 iOS CI 測試，應先驗收什麼？
先把流水線要證明的事情說清楚：是建置可用、啟動成功、版面沒有回歸，還是符合發布准入條件。這些是不同層次的證據，不能以一個「CI 綠燈」概括。
建議把驗收目標寫成團隊可檢查的項目，而非「支援 iPhone Duo」這類沒有測試紀錄的標籤：
- 建置與啟動：指定的 Xcode、專案設定及測試目標能否完成建置，應用能否在目標模擬器啟動。
- 版面回歸：應用實際支援的外螢幕、內螢幕及姿態變化下，關鍵畫面是否符合預期。
- 互動檢查：重要操作流程是否能在模擬器中重現；不支援或難以模擬的行為另列補測。
- 發布准入：通過條件、阻斷問題、例外核准和回退方式是否有明確負責人。
Apple 的測試文件說明如何執行測試及解讀結果，可用來設計 CI 報告的閱讀方式；但團隊仍須自行定義哪些結果足以阻擋發布。查看 Xcode 測試執行與結果解讀文件
CI 平台負責人：怎樣確認 Xcode、Mac 與模擬器可用？
iPhone Duo Simulator 可以納入自動化流程的評估，但不是只要流水線能啟動任何模擬器就算完成。先確認建置 Mac 的作業系統、Xcode 版本、專案所需工具，以及目標模擬器是否在該組合下可用。Apple 的 Xcode 系統需求頁列出各版本的支援條件，團隊應以正在採用的版本核對，而非沿用舊節點的安裝紀錄。核對 Xcode 系統需求
接著記錄執行環境，至少要能從一次測試結果追溯：
- 建置節點及其作業系統版本。
- Xcode 與專案採用的工具鏈版本。
- 測試所用的模擬器型號與啟動條件。
- 流水線執行的測試目標、結果和失敗日誌。
「Device Hub」也應納入工具鏈盤點。若團隊使用它管理裝置或測試資源，需先確認實際工作流程是否依賴該功能，以及目標執行環境能否配合；不要只因文件中出現該名稱，就推定 CI 節點已具備所需能力。查閱 Apple 的 Device Hub 文件
對 Xcode 27.1 的限制應另設檢查項。Apple 的 RC 發行說明提及部分擴充功能無法在 iPhone Duo Simulator 執行；這表示依賴特定擴充功能的測試，不應僅憑一般模擬器測試成功就視為已覆蓋。採用前需檢查正式版發行說明和目前文件，將確認過的限制、影響測試目標及替代驗證方式記入流水線說明。
應用團隊：如何把展開、摺疊與尺寸變化納入測試？
測試設計應跟隨應用承諾支援的體驗，而不是複製一套與產品無關的介面範例。Apple 的 iPhone Duo 準備指南與設計指南可作為平台行為和設計考量的依據；專案則應把適用的項目轉成可重複檢查的測試條件。參閱 iPhone Duo 準備指南與 iPhone Duo 設計指南
例如，先為每個關鍵流程標示外螢幕、內螢幕及展開或摺疊後需要維持的功能，再確認尺寸改變時的畫面狀態。若應用會依視窗或視圖尺寸調整排版，測試要檢查尺寸改變後是否重新取得適用的尺寸資訊，而非假設先前讀取值一直有效。具體實作方式依 Apple 的當前文件及專案架構確認，不宜把介面建議直接寫成所有應用都必須遵守的 CI 規則。
應用團隊可以用以下方法讓檢查更可重現：
- 為重要畫面建立穩定的測試入口，避免測試依賴不相關的導覽流程。
- 將不同螢幕狀態下的關鍵內容、操作與版面預期寫進測試案例。
- 對無法穩定自動化的視覺細節，保留人工檢查步驟及檢查紀錄。
- 每當應用改變支援範圍或導覽方式，重新檢查測試案例是否仍代表實際使用路徑。
提醒：模擬器測試能提供指定模擬環境下的結果；它不能自動證明所有真實裝置行為都已驗證。凡是模擬器不支援、無法可靠重現，或專案風險要求實機確認的項目，都應明確列為補充驗證，而非留給發布前臨時判斷。
QA 與發布負責人：哪些結果足以成為簽核證據？
測試矩陣應標示「測了什麼、在哪裡測、結果如何、還缺什麼」。這比單純保存成功或失敗狀態更有助於審核，也能避免把模擬器覆蓋範圍說得過滿。
| 驗收項目 | 模擬器可提供的證據 | 評級判斷 | 仍需確認的內容 |
|---|---|---|---|
| 建置與啟動 | 指定工具鏈下的建置及啟動結果 | 可納入 CI：環境與目標均已記錄 | 工具鏈或測試目標變更後重新核對 |
| 姿態與尺寸版面 | 已設計測試案例的版面檢查結果 | 有條件通過：僅代表已覆蓋的狀態 | 未覆蓋狀態及人工檢查結果 |
| 互動流程 | 模擬器中可重複執行的操作結果 | 按風險判定：不可重現的項目須標示 | 是否需要實機或其他補充驗證 |
| 發布准入 | 測試紀錄、限制清單與簽核資訊 | 不可單獨由模擬器判定 | 例外核准、阻斷問題與回退責任 |
第一步：固定測試環境
將 Mac、作業系統、Xcode、模擬器和測試目標記入測試紀錄。環境資料不足時，失敗原因可能無法重現，也難以判斷問題來自應用還是節點差異。
第二步：界定覆蓋範圍
QA 與應用負責人共同列出需要測試的畫面、姿態、尺寸變化及主要流程。對未納入自動化的項目，寫明原因和補測方式。
第三步：保存結果與限制
保留 CI 結果、必要日誌、未通過項目及已知模擬器限制。若工具鏈或發行說明更新，重查原有測試是否仍能代表團隊的支援範圍。
第四步：設定阻斷與例外規則
發布負責人應說明哪些失敗會阻擋發布，哪些可以經核准後接受，以及例外由誰簽核。不可把沒有紀錄的人工判斷當成自動化驗收結果。
第五步：指定補測與回退責任
對模擬器無法證明、但發布要求必須確認的項目，指派補測負責人並記錄結果。若關鍵測試失敗，需按既定條件暫停發布、修正或回退。
遠端 Mac 的工作負載適配評估
是否採用遠端 Mac，不應從「能否連線」直接推導出「能否承載 CI」。IT 與採購團隊要以實際流水線試跑，核對 Xcode 與模擬器條件、存取方式、權限管理、測試紀錄保存和團隊需要的環境隔離。不同供應環境的配置與交付方式可能不同，不能預設租用環境具有相同的模擬器能力。
按條件選擇接入方案
- 若目前 Mac 節點已符合所需 Xcode 與模擬器條件，且負載不影響既有建置：先在現有節點建立代表性測試，再檢查並行工作對其他流水線的影響。
- 若節點容量、環境一致性或團隊存取方式成為阻礙：先在候選遠端 Mac 環境執行同一組建置與測試，通過工具鏈、權限和結果追溯檢查後再考慮遷移。
- 若專案要求的驗證只能在實體裝置完成，或需要現有環境未提供的硬體連接：保留實機或本地驗證，不要以模擬器或遠端環境替代必要測試。
- 若屬於長期、穩定且持續高負載工作：把租賃與自購 Mac 的持續成本、維護責任、環境控制及擴充需求一併比較；不應只看短期導入成本。
採用遠端環境前，企業還應確認資料處理和存取管理是否符合內部政策，可先參閱資料隱私說明。若團隊正在評估 Mac 租用形式，也可先閱讀 OrbVPS 的 Mac 環境資訊，再用實際專案驗證其交付方式及工具鏈適配情況；本文不預設任何未經試跑的相容性或效能結果。
既有自管 Mac CI 的優點是環境由企業控制，但也可能遇到節點排程衝突、硬體採購與維護負擔，以及跨團隊環境不一致等問題。若容量不足或環境重現確實拖慢驗收，OrbVPS 的遠端 Mac 可作為待驗證的補充方案；先用代表性流水線確認 Xcode、模擬器與權限需求，再決定是否租用。若現有節點已滿足長期工作負載，或專案依賴必須本地連接的實體設備，維持自管環境可能更合適。
以 OrbVPS 雲端 Mac 試跑 iOS CI
在獨享 Apple Silicon 實體節點上部署自架執行器，將建置與模擬器測試納入可持續執行的流程。