Apple Developer 已提供 Xcode 27.1 的發行說明，以及針對 iPhone Duo 姿態測試的官方 Tech Talk 資料：Xcode 27.1 發行說明與Apple 的 iPhone Duo 姿態測試教學。這代表你現在應先建立 iPhone Duo 狀態恢復測試基線，再用模擬器覆蓋邏輯，最後以真機驗證摺疊互動、相機、感測器與持續執行行為；不要只確認 App 能在內外螢幕顯示。
這篇適合三類讀者：SwiftUI 或 UIKit 開發者，用來建立姿態變化與場景恢復邏輯；QA 與測試負責人，用來編寫可重複的摺疊狀態回歸用例；需要臨時擴充 Apple silicon Mac 測試資源的小團隊，用來安排模擬器、CI 與真機的分工。
先把「恢復成功」拆成四層
「畫面重新出現」只是最低層的結果。一次合格的 iPhone Duo 狀態恢復測試，至少要分開判斷以下四層：
- 姿態變化：App 從閉合轉展開、展開轉閉合，或由直向切換至橫向後，畫面結構、導航層級與輸入焦點是否仍然合理。
- 系統中斷：來電、通知、權限視窗、網路變化、切到背景或系統終止後，App 是否能按照預期回到可操作狀態。
- 任務恢復：使用者正在編輯內容、填寫表單、上傳檔案或播放影片時，回到 App 後是否能繼續原本任務，而不是只回到首頁。
- 資料一致性：未提交的內容、上傳進度、選取項目與伺服器資料是否一致。即使畫面看起來正確，資料遺失仍應判定為失敗。
Apple 的狀態恢復文件將狀態保存與還原放在應用程式生命週期內處理；場景生命週期文件則說明以 Scene 管理不同視窗與場景。你的驗收紀錄應把這些層次分欄，否則「成功重建畫面」很容易掩蓋業務狀態沒有復原的問題。
iPhone Duo 展開後 App 狀態丟失怎麼處理？
先不要把問題歸類為單純版面適配。記下展開前的導航路徑、編輯內容、游標位置、捲動位置與未提交資料，再確認展開動作後哪些值消失。若只有畫面狀態遺失，檢查 Scene 狀態保存與 SwiftUI 或 UIKit 的狀態邊界；若伺服器資料也被覆寫，則要優先加入版本檢查、草稿保存和重試前確認。
第一階段：固定可重複的測試基線
在開始寫用例前，先把每輪測試的變數鎖定。否則同一個失敗結果可能來自不同系統版本、帳號資料或網路條件，無法交給開發者重現。
建議每次測試都記錄：
- Xcode 版本、iOS SDK、App 建置版本與提交識別碼。
- 模擬器或真機型號、系統版本、目前姿態與旋轉方向。
- 測試帳號、初始草稿、檔案狀態、播放位置與伺服器端資料。
- 網路類型、是否刻意切換離線，以及權限設定。
- 觸發前的畫面截圖、操作步驟、預期結果與實際結果。
這裡的重點不是追求一次跑完所有案例，而是讓下一輪能完全重現上一輪。可先建立四個固定任務：編輯一段尚未提交的文字、填寫部分表單、啟動檔案上傳、播放影片至中段。不要預先填入成功率、耗時或自動化覆蓋率；這些數字必須來自你自己的設備與環境實測。
iOS 27 應用如何驗證視窗和任務連續性？
先以同一個測試帳號完成一項任務，再依序記錄視窗狀態、導航栈、輸入焦點、捲動位置和未提交資料。每次只改變一個條件，例如只展開、只旋轉，或只切到背景。這樣才能判斷失敗是由姿態變化造成，還是由場景重建、網路拉取或資料保存造成。
第二階段：用模擬器完成姿態與邏輯預檢
Xcode 27.1 模擬器適合先驗證狀態轉移與介面邏輯。你可以建立以下操作序列：
- 關閉 App 前停留在編輯頁，輸入新內容後由閉合切換至展開。
- 在展開狀態選取文字、移動游標，再切換直向與橫向。
- 在表單輸入一半時切換多視窗，回到原場景後檢查欄位與鍵盤焦點。
- 啟動上傳後改變姿態，確認任務標記、重試按鈕和取消操作仍然可用。
- 播放影片時切換螢幕狀態，確認播放位置與播放控制不會回到預設值。
每個用例都應寫成四段：操作前狀態、觸發動作、可觀察結果、失敗留證。例如，操作前狀態是「表單已填寫姓名但尚未送出」；觸發動作是「閉合後再次展開」；預期結果是「姓名保留、焦點規則一致、送出按鈕狀態正確」；失敗留證則包括錄影、畫面截圖、Scene 記錄與建置版本。
iPhone Duo 模擬器能測試哪些摺疊姿態？
模擬器可用來檢查官方工具提供的展開、閉合、方向切換、視窗大小變化，以及由此引起的導航和狀態重建邏輯。Apple 的多顯示與版面 Tech Talk可作為視窗配置與內容連續性的參考。可是，模擬器不能證明真實鉸鏈操作、觸感、相機切換、感測器讀值或長時間執行一定正常。
第三階段：加入背景、中斷與資料競爭
摺疊應用測試不能只跑姿態變化。真實使用時，系統中斷可能在任務最敏感的時間點出現。你應把以下條件插入四個固定任務：
- 權限視窗出現時閉合或展開，檢查回到 App 後是否仍在原本流程。
- 上傳期間切換網路，確認進度不會被錯誤重設，失敗時要有重試與取消選項。
- 編輯內容尚未保存時切到背景，再回到前景，確認草稿與提示文字一致。
- App 被系統終止後重新開啟，分辨是本機狀態恢復、重新向伺服器拉取，還是只能回到安全的初始狀態。
- 使用通知、來電或其他 UI 中斷打斷輸入，確認焦點、鍵盤和未提交資料沒有靜默遺失。
Apple 的應用程式生命週期文件可協助你區分前景、背景與重新啟動路徑；UI 中斷處理文件則適合用來設計自動化測試中的權限視窗與系統提示處理。
失敗處理要比「恢復不了」更具體。若本機草稿存在，應提供恢復或捨棄選項；若上傳狀態不明，不要直接顯示成功；若伺服器資料較新，應提示使用者選擇合併、保留本機草稿或重新載入。這些結果要寫進預期行為，不能留給測試人員自行判斷。
第四階段：用真機複核硬體相關行為
完成模擬器預檢後，才進入真機專項。真機測試不是把模擬器案例再跑一次，而是確認模擬器無法提供的條件：
- 實際閉合與展開的手勢是否會造成重複觸發、誤觸或輸入中斷。
- 相機啟動、前後鏡頭切換、拍攝中改變姿態時，預覽與拍攝任務是否連續。
- 感測器、旋轉、鍵盤、觸控與裝置方向變化是否符合預期。
- 長時間播放、上傳或編輯時，溫度、耗電、記憶體壓力與背景恢復是否出現不同結果。
- 真機在弱網、斷網、重新連線後，資料保存與任務重試是否安全。
相機流程應另外參考 Apple 的iPhone Duo 相機體驗 Tech Talk。每次真機紀錄都要包含裝置識別、系統版本、App 建置版本、測試帳號、網路環境和姿態序列。模擬器通過只能標記為「邏輯預檢通過」，不能直接寫成完整相容結論。
上線前用放行矩陣收斂判斷
最後不要以「大部分畫面正常」作為發佈條件。把問題分成三個等級：
- 阻斷級：編輯內容遺失、上傳重複、帳務或權限狀態錯誤、回到錯誤帳號，或 App 在核心姿態切換後無法操作。
- 可接受降級：任務被暫停，但有清楚提示、草稿仍在、重試路徑可用，且不會誤報完成。
- 體驗問題：捲動位置略有變化、非核心動畫中斷或版面需要重新載入，但資料、任務和導航仍正確。
你可以在發佈候選版本前逐項勾選：
- [ ] 閉合至展開、展開至閉合的四個固定任務都已執行。
- [ ] 直向、橫向與多視窗切換均已留下截圖和操作記錄。
- [ ] 背景、權限、通知、網路切換與系統終止案例都有預期結果。
- [ ] 編輯、表單、上傳和播放進度未出現未提示的資料遺失。
- [ ] 模擬器結果與真機結果已分開標記，沒有把前者當成硬體相容證明。
- [ ] 阻斷級問題已修正並回歸；降級行為有產品與 QA 共同確認。
- [ ] 發佈版本可回滾，測試用例、錄影、日誌和建置識別碼已交付。
開發負責人應確認狀態保存、Scene 生命週期與資料模型；QA 負責人應簽署用例結果、失敗證據和回歸範圍；發佈負責人則要確認降級提示、回滾版本與真機覆蓋範圍。三者缺一，放行結論都不完整。
如果你目前用的是固定本機 Mac，這套流程的限制通常不是 Xcode 本身，而是沒有足夠的真機前置時間、不同系統建置環境和可重複的測試節點。自購 Mac 適合長期高負載與需要實體介面的團隊；雲端伺服器則常需要另外處理圖形介面、頻寬、裝置連線和權限問題。若只是為了 iPhone Duo 上線前的多輪驗收，臨時租用 vmzig 的 Mac 環境，通常比臨時添購硬體更容易按版本切換測試；但涉及真實摺疊手感、相機或感測器的案例，仍要保留真機確認，不能只依賴遠端環境。