iPhone Duo 模擬器已能啟動，但團隊仍不確定哪些姿態應列入 CI 門禁。

最快做法：iPhone Duo 企業 CI 測試矩陣先驗證代表性的折疊、展開狀態與關鍵頁面，再依應用程式風險補上自動化回歸及實體設備檢查；不必把每種姿態和方向全數排列，也不能把 Device Hub 手動探索當成自動化門禁已通過。

企業 IT 負責人：需要決定是否將 iPhone Duo 驗收納入發布流程。
平台工程負責人：需要確認 Xcode 27.1 模擬器和現有 Mac CI 流水線如何承載新增檢查。
QA 負責人：需要把姿態與關鍵使用路徑轉成可重複執行、可追溯的測試範圍。

最後更新於 2026 年 10 月 28 日；上市日期與開發工具資訊核對自 Apple Developer 的 iPhone Duo 準備說明及 Xcode 27.1 發布說明。

建立 iPhone Duo 企業 CI 測試矩陣

已確認的產品與工具資訊：Apple 公布 iPhone Duo 於 2026 年 10 月 23 日上市，並說明 Xcode 27.1 提供相應開發支援。Apple 亦介紹可用於檢視姿態和方向表現的工具。這些是開發與檢查能力的說明，不代表 Apple 規定每個企業都要採用同一套 CI 矩陣。Apple 的準備與提交說明列出上市及開發準備資訊；Xcode 27.1 發布紀錄與版本說明可供核對工具版本。

真正需要決定的不是「要不要測所有畫面」，而是哪些狀態改變會影響使用者完成關鍵任務。可先把工作分成四類，再確認各自的通過證據：

  • Device Hub 手動姿態檢查：用來探索、觀察和記錄不同姿態下的版面變化，協助 QA 找出自動化應覆蓋的情境。
  • 模擬器自動化測試：用固定前置狀態重跑可重現的頁面和操作，適合納入 CI 門禁。
  • 實體設備複核：針對模擬器不能代表、或團隊風險評估要求以實機確認的項目安排驗收。
  • App Store 截圖準備：屬於商店素材工作，不等同於介面回歸或發布批准；素材規格應另行核對 App Store Connect 截圖說明。

企業 IT 的發布範圍

企業 IT 不應以「支援新裝置」作為一個含糊的放行條件。先界定本次驗收是確認程式可啟動、關鍵流程可完成，還是也要確認發布素材與實機行為；三者應各有判定方式，不能用一張模擬器截圖代替。

設計上的差異可能影響共用元件，也可能只影響少數頁面。Apple 的 iPhone Duo 設計指南可協助團隊理解介面適配方向，但企業矩陣仍須按自身產品的實際頁面、導覽方式與風險設定。

發布範圍可先分成以下工作：

  • 將介面適配列為應用程式驗收，明確哪些頁面要檢視尺寸與視窗布局變化。
  • 將可重現的關鍵操作列為自動化候選，避免把人工探索步驟誤列為 CI 通過條件。
  • 將商店圖片和正式發布核准分開管理，避免「素材已備妥」被誤讀為「功能已驗收」。

應用程式團隊的介面風險

固定螢幕尺寸假設、只為單一方向設計的版面、非對稱安全區處理，以及依賴固定位置的自訂導覽，都可能在視窗狀態改變時暴露問題。這些是盤點線索，不代表每個專案都存在相同缺陷；應從程式碼結構與實際畫面確認，而不是預設全部需要重寫。

可以先標記登入、核心業務操作、媒體顯示等頁面，再逐一確認尺寸或姿態改變是否會造成內容被遮擋、操作入口移位、文字溢出，或使用者無法繼續流程。Apple 的介面布局適配技術講解與iPhone Duo 適配技術講解可作為實作檢視的參考；最後的通過條件仍應由產品和 QA 根據實際行為定義。

平台團隊的自動化邊界

裝置工具能協助觀察姿態，不代表現有流水線已經在正確環境中執行測試。平台團隊應確認 CI 使用的 Xcode、目標模擬器、測試方案和結果保存位置；如果流水線只成功啟動模擬器，卻沒有執行預期的測試方案或保留結果，就不能宣告矩陣通過。

Apple 的 Device Hub 文件可用來核對工具用途。實務上應把人工操作與 CI 執行分成兩條證據鏈：前者保存探索過程、觀察到的問題及後續測試設計；後者保存建置結果、測試結果和失敗細節，供團隊重現及審核。

建議平台團隊逐項核對：

  • [ ] 在 CI 記錄中確認實際使用的 Xcode 版本，並核對目標模擬器與測試方案。
  • [ ] 確認測試執行的是預期的測試案例，而不只是完成建置或啟動模擬器。
  • [ ] 保存建置與測試結果，並讓失敗結果能連回對應的提交、測試案例和執行環境。
  • [ ] 將 Device Hub 的手動檢查記錄和自動化門禁結果分開標示。

QA 團隊的代表性狀態

矩陣的目標是覆蓋與應用程式功能相關的變化，不是列出所有可能的姿態、方向和頁面組合。若一種狀態不會改變布局、操作或任務結果，通常不必只為了增加案例數而另立門禁；若它會改變核心流程，則應有明確的測試案例與預期結果。

QA 可從折疊、展開、方向變化及關鍵尺寸改變等類別中，選取與產品功能相關的代表狀態。每項檢查至少要能回答：要看哪個頁面、要完成哪個操作、預期結果是甚麼，以及失敗時要保存甚麼證據。狀態的選擇應以應用程式實際呈現為準，而不是把工具中可操作的狀態一概視為發布要求。

測試案例設計清單

  • [ ] 為每個代表狀態指定一個需要驗收的關鍵頁面。
  • [ ] 寫明狀態變化後要執行的使用者操作，並定義可觀察的預期結果。
  • [ ] 對可能受安全區、視窗布局或自訂導覽影響的頁面，記錄檢查方式與失敗證據。
  • [ ] 將可穩定重現的操作轉成自動化案例；將探索性檢查保留為 QA 記錄。
  • [ ] 為每個未納入自動化的風險項目，記錄人工複核或實體設備補測安排。

常見驗收疑問

企業 iOS CI 如何挑選 iPhone Duo 的代表姿態？

先檢視產品哪些頁面和流程會因折疊、展開、方向或尺寸變化而改變，再挑選能代表這些風險的狀態。核心操作受影響時，將該狀態納入回歸；若變化不影響布局或流程，就不必為了窮舉而增加獨立門禁。

Xcode 27.1 模擬器能協助檢查哪些介面問題？

可用它檢視不同狀態下的布局、內容可見性、導覽位置和關鍵操作是否仍可使用。模擬器檢查能提供介面適配證據，但不能單獨證明所有真實裝置互動或硬體相關行為都符合預期；是否補做實機測試應依應用程式風險判定。

折疊與展開狀態怎樣進入自動化回歸？

先在模擬器檢查中找出可重現、會影響使用者任務的狀態，接著固定測試前置條件，為頁面、操作和結果建立自動化案例。若只是透過 Device Hub 手動切換並觀察畫面，該結果仍是探索證據，不應列為自動化回歸已通過。

模擬器通過後，哪些情況仍應安排實體設備複核？

若應用程式依賴模擬器不能充分代表的硬體互動、真實操作體驗，或團隊風險政策要求實機確認，就應補做實體設備驗收。若某項風險已能由穩定的模擬器案例充分判定，可縮小補測範圍，但應保留理由和未涵蓋事項。

發布與安全團隊的放行證據

自動化門禁應綁定可重現的建置與測試結果；人工姿態檢查則要保留觀察頁面、狀態和問題記錄。若實體設備複核是團隊的發布條件，也要保存相應結果。這些證據分別回答不同問題，不宜合併成一個沒有來源的「驗收通過」。

例外情況應記錄受影響的頁面或流程、風險判斷、暫行處理與回退決策。模擬器通過不等於商店素材完整，素材完成也不等於生產發布已獲批准；三者需由各自的負責人確認。

完成矩陣後，可按下列方式作出放行判斷：

  • 關鍵流程在代表狀態下可重複通過，且結果已保存：納入相應自動化門禁。
  • 仍有模擬器不能充分代表的風險：安排人工複核或實體設備補測。
  • 測試環境、工具版本或結果紀錄不明確：先修正流水線與證據，再判定是否放行。
  • 只有 App Store 素材檢查完成：只標記素材準備完成，不替代功能驗收或發布批准。

Mac CI 承載方式的選擇

新增模擬器檢查前，先確認現有工作流程能否固定 Xcode 與測試方案、保存結果並在必要時重跑。若長期工作負載穩定、需要專屬硬體或特殊實體介面，自行採購及管理 Mac 可能較合適；若需求是階段性驗收或臨時增加遠端 macOS 測試環境，則可比較自管設備與按需租用方案。

自管 Mac 的成本不只購機，也包括設備維護、環境更新與閒置容量；臨時雲端環境則要先核對其存取方式、交付條件及實際工作流程是否符合團隊要求。需要評估遠端 Mac 時，可先閱讀 RUVCLOUD 遠端 Mac 服務資訊，並依 RUVCLOUD 套餐與計費頁面核對當前列出的條件；若要採用，再由 RUVCLOUD 申請頁面確認當下可選的服務內容。本文不推定任何未列明的配置、節點或測試效能。

對持續、穩定且需要掌控實體設備的重負載工作，自購 Mac 或自管 CI 節點可能更適合；若新增驗收只在特定發布階段需要，按需租用遠端 Mac 則可避免為短期需求配置長期閒置設備。此時可把既有 CI 流水線、遠端存取要求與交付條件逐項核對，再決定是否由 RUVCLOUD 承載這段 Mac CI 工作。