iPhone Duo 適配怎麼測？2026 企業 CI 驗收清單

iPhone Duo Mac CI 測試不是單一任務。技術負責人先把需求拆成六種狀態：

• 應用程式兼容：現有功能在不同姿態下能否正常顯示與操作。
• 介面優化：導航、彈窗、自訂布局和內容密度是否需要重新設計。
• 模擬器驗證：用可重現的環境執行布局、旋轉與狀態保持回歸。
• 真機驗證：確認攝影機、效能、實體互動和硬體行為。
• 素材提交：產生符合 App Store Connect 要求的截圖或其他素材。
• 生產發布：正式歸檔、簽名及提交流程。

這六類工作不能全部用「增加建置機」解決。Apple 已公開 iPhone Duo 的開發者準備資源、設計更新和技術影片；Xcode 27 已正式發布，但面向 iPhone Duo 的 Xcode 27.1 beta 與部分完整開發資料仍以稍後提供為狀態，應以官方頁面後續更新為準。Apple 的設計與開發資源 可作為資產盤點起點。

本週的決策記錄至少要包含：應用範圍、業務優先級、預定上線窗口、負責人、不可接受的兼容問題，以及目前缺少的證據。若工具鏈仍未能穩定重現，結論應是「建立隔離驗證通道」，而不是「把它直接併入生產」。

研發團隊負責把介面風險轉成可測試資產。Apple 的 iPhone Duo 技術影片與開發說明 可協助團隊確認設計與布局檢查方向，但不能取代企業自己的頁面清單。

每個高風險頁面都應交付以下資料：

• 外屏、內屏、展開、摺疊和旋轉等測試姿態。
• 導航、彈窗、攝影機、場景管理及自訂布局的預期結果。
• 觸發條件、重現步驟、程式碼位置和負責人。
• 修復狀態、阻斷級別及可否轉為自動化測試。
• 失敗截圖、測試紀錄和交接給 QA 的版本識別。

普通橫向與直向回歸只能證明基本方向切換，不等於完成 iPhone Duo 適配。若頁面依賴固定寬度、單一場景或手動保存狀態，應直接列為高風險項目。研發的否決條件是：無法定位重現條件、核心流程在某一姿態遺失，或修復後沒有可重跑的驗證案例。

QA 則要將測試拆成基礎兼容、姿態切換、狀態保持、快照素材和真機行為。模擬器適合驗證可重現的布局與狀態轉移；攝影機、效能和實體互動仍要等待真機證據。這也是 Apple 的相關技術說明 應與企業測試紀錄並讀的原因。

CI 平台團隊的責任不是把新工具鏈安裝到每一台 Mac，而是建立一條可撤回的驗證路徑。

建議依以下順序落地：

• 建立與正式 Xcode 27 分離的 Xcode 27.1 驗證節點。
• 為驗證節點設定獨立 Runner 標籤、任務佇列和存取權限。
• 先選代表性專案，執行最小姿態回歸和兼容建置。
• 收集安裝與恢復結果、建置時長、測試時長、失敗率、佇列等待及硬碟變化。
• 確認結果可重跑後，再擴大到更多倉庫與測試套件。
• 將結論交給安全發布團隊，決定是否允許進入預發布流程。

這些項目是企業自己的觀測資料，不應用裝置數量直接推算 Mac 節點數。沒有原始 CI 日誌，就不能宣稱某個配置一定能承擔某種回歸量。

安全發布團隊則要保護正式簽名邊界。驗證節點應與正式歸檔、憑證私鑰及 App Store 發布節點分離。預覽工具鏈預設不得取得生產簽名資產。測試帳號、內部依賴、日誌與建置製品也要設定保存範圍，並準備節點重建後的憑證清除流程。

App Store Connect 已列出相關截圖規格，但官方說明素材上傳支援將於年內稍後開放。因此，現階段可以準備可重現的素材產生流程，不能把「已能產生素材」寫成「目前已能正式提交」。截圖規格說明 應放進驗收證據，而不是當作發布入口已經完成的證明。

Mac 容量應按工作特徵決定，而不是按團隊人數決定。以下四種方案可作為 IT 與採購的比較基準：

若企業需要先取得實際佇列資料，可把一台隔離的遠端 Mac 測試節點用於代表性專案。重點不是宣稱租用方案必然更快，而是先量出自己的建置時長、姿態回歸時長、等待時間和重建結果，再決定是否進入固定節點池。

iPhone Duo 應用程式適配需要測試哪些裝置姿態？

應按外屏、內屏、展開、摺疊及旋轉狀態盤點，而不是只測一般橫向和直向。導航、彈窗、攝影機、場景管理與自訂布局都要有預期結果；高風險頁面必須附上重現條件、程式碼位置、修復狀態與自動化判斷。

Xcode 27.1 如何在企業 CI 中單獨部署？

待官方工具可用後，將它放在獨立驗證節點，不覆蓋正式 Xcode 27。使用專用 Runner 標籤和任務佇列，先跑代表性專案及最小姿態回歸，再擴大範圍；驗證節點預設不得讀取生產簽名資產。

iPhone Duo 模擬器測試能否替代真機測試？

不能完全替代。模擬器適合布局、導航、狀態保持和快照等確定性回歸；攝影機、效能、實體互動與硬體差異仍需要真機證據。驗收表應把模擬器通過和真機通過分成兩個欄位。

新增 iPhone Duo 回歸任務後 Mac CI 是否需要擴容？

不一定。先比較獨立驗證節點的建置時長、回歸時長、佇列等待、失敗率與硬碟變化，再觀察正式任務是否受到影響。若峰值佇列持續超出發布窗口，才在固定節點、短期遠端 Mac 或混合部署之間選擇。

以下清單應由責任人逐項勾選，並把證據交給下一個角色。沒有證據的項目，不應標示為完成。

研發

• [ ] 完成外屏、內屏、展開、摺疊和旋轉姿態的高風險頁面盤點。
• [ ] 為每個問題記錄程式碼位置、重現條件、負責人和修復狀態。
• [ ] 區分介面優化、應用兼容和可自動化回歸。
• [ ] 將核心流程的預期結果交給 QA。
• [ ] 對無法重現或狀態遺失的問題保留否決權。

QA 與研發效能

• [ ] 建立模擬器、真機、素材和發布的分層矩陣。
• [ ] 每項測試記錄姿態、應用狀態、預期結果、失敗截圖和阻斷級別。
• [ ] 指定哪些案例每次提交執行，哪些案例只在專題回歸執行。
• [ ] 將模擬器通過與真機通過分開報告。
• [ ] 把不可自動化的硬體行為交接給真機測試負責人。

CI 平台

• [ ] 建立獨立的 Xcode 27.1 驗證節點與 Runner 標籤。
• [ ] 確認正式 Xcode 27 節點未被預覽工具鏈污染。
• [ ] 先用代表性專案執行最小姿態回歸。
• [ ] 保存建置時長、測試時長、失敗率、佇列等待和硬碟變化。
• [ ] 在擴大倉庫範圍前完成一次可重跑驗證。

安全與發布

• [ ] 驗證節點與正式歸檔、私鑰和發布節點隔離。
• [ ] 檢查測試帳號、內部依賴、日誌與建置製品的保存範圍。
• [ ] 驗證節點預設無法取得生產簽名資產。
• [ ] 演練節點重建後的憑證清除。
• [ ] 在素材上傳支援正式開放前，不把素材流程標示為可提交。

IT 與採購

• [ ] 以任務頻率、峰值佇列和單次占用時間評估容量。
• [ ] 確認生產簽名任務仍由可信的專用節點承擔。
• [ ] 判斷新增負載屬於短期適配高峰還是長期固定回歸。
• [ ] 為維持現狀、短期擴容、固定節點和混合部署各自記錄證據缺口。
• [ ] 先以隔離節點完成 PoC，再提交長期採購或租用決議。

完成清單後，決策不應只寫「需要更多 Mac」。建議輸出一頁容量決議，至少回答：

• 新增任務每週或每個發布窗口出現的頻率。
• 單次建置與姿態回歸各自占用節點多久。
• 峰值時段的佇列等待是否影響發布窗口。
• 驗證環境是否需要與生產簽名環境完全隔離。
• 故障後是否能重建節點並清除憑證。
• 哪些證據仍缺少，誰負責補齊。

若現有節點能吸收負載，維持現狀比過早採購更容易控管。若適配只集中在短期窗口，彈性容量較適合做驗證。若回歸成為長期固定工作，才有理由增加專用節點。需要了解不同區域遠端 Mac 交付條件時，也可先比較香港 Mac 雲端配置，再按企業的網路與權限要求做 PoC。

目前方案若是把新回歸直接塞進生產 Mac，常見缺點是工具鏈污染正式環境、驗證任務與發布任務互相搶佇列，以及簽名資產被迫暴露給較寬的執行範圍。若再以固定採購應付短期高峰，還會增加閒置、維護和節點重建成本。對尚未掌握真實負載的團隊，先租用一台隔離的遠端 Mac 執行代表性專案，通常比立即擴充固定容量更容易取得可審核的證據；完成測試後，再決定是否保留、增加固定節點或回到現有架構。

當團隊需要臨時驗證環境時，可到 MESHLAUNCH 的 Mac 方案頁面了解可用的租用方式。先把佇列與耗時記錄下來，再讓資料決定長期容量。