iPhone Duo 應用怎麼適配？2026 折疊屏測試時間表

症狀：固定尺寸、方向判斷或自訂導覽列，讓畫面在內外螢幕切換後裁切、遮擋或留下空白。
最快解法：先升級並固定開發環境，恢復可伸縮布局，再依外螢幕、內螢幕、分屏與折疊狀態逐步驗收；真機到貨前可完成大部分布局排查，但攝影機、續航、觸控與鉸鏈互動必須留到真機複核。

截至 2026 年 9 月 10 日，本文內容以 Apple 發布會後的官方公告、Apple Developer 文件與 Tech Talks 為核對基礎；Xcode、SDK 或提交要求若仍標示為 beta、coming later，本文不會把它們寫成穩定版能力。Apple 官方 iPhone Duo 公告

這篇文章適合仍依賴固定螢幕尺寸、方向判斷或自訂導覽列的 iOS 開發者，也適合需要制定 iPhone Duo 回歸測試計劃的 QA 負責人。如果你的團隊缺少持續可用的 Mac 建置環境，或只想在上市前短期增加測試並發，後面的環境分支也能直接拿來排程。

先分流：哪些應用要立即做 iPhone Duo 應用適配

不要因為「折疊 iPhone」多了一個形態，就把所有頁面重寫。先把現有應用分成三類：

• 暫時無需修改：主要使用 Auto Layout、size classes、標準導覽元件，沒有依賴固定寬高，也不會把特定螢幕索引當成永久畫布。
• 需要布局調整：存在固定寬高、以主螢幕尺寸推算內容、用橫豎屏判斷控制整個頁面，或在 safe area 外自行繪製工具列。
• 需要專項功能驗證：使用自訂導覽、雙欄介面、攝影機、畫中畫、多視窗、外接附件，或要求使用者在頁面中途改變視窗尺寸。

Apple 的 UIKit 布局文件把重點放在可適應的約束與容器行為，而不是為每一種裝置形狀建立一套獨立畫面。你應先對照UIKit 布局與可伸縮介面文件，再決定哪一層需要改動。

經驗提醒：最常見的失敗不是「沒有畫出折疊動畫」，而是內容仍認為螢幕寬度永遠不變。結果是外螢幕按鈕被截斷，展開後雙欄空白，或返回上一頁時導覽堆疊消失。

第一階段：先固定 Xcode 27 與 iOS 27 的可重現環境

在第一個建置週期開始前，先記錄 Xcode、SDK、Swift 套件、測試資料與簽署設定。Xcode 27 或 iOS 27 若在 Apple Developer 頁面仍有 beta 或後續發布標記，就把該狀態寫入測試報告，不要讓 CI 標籤暗示它已經是穩定工具。

你可以按以下順序建立基線：

1. 依照Apple 的 Xcode 系統要求確認本地 Mac 是否能執行目標版本。
2. 鎖定 Xcode、SDK、Ruby 或 Node 依賴、套件解析結果與建置腳本版本。
3. 在本地 Mac 與雲端 Mac 使用相同的環境檔、簽署流程與建置產物命名。
4. 先執行現有版本，不急著修改程式。
5. 保存外螢幕、內螢幕、不同視窗尺寸下的截圖、啟動日誌、旋轉結果與背景恢復結果。

裝置與測試目標的管理，應以Apple Device Hub 官方文件當日內容為準。若模擬工具名稱、下載方式或支援狀態變動，先在乾淨測試節點重跑一次，不要直接把個人電腦上的快取環境複製到 CI。

如果你需要把短期測試節點交給多位開發者使用，先參考MacPull 的開發環境協助說明，確認遠端連線、帳戶權限、工具版本與建置產物保存方式，再決定哪些工作留在本地 Mac、哪些工作放到雲端 Mac。

第二階段：由固定尺寸改成可伸縮布局

這個階段的目標不是把頁面「做得像折疊手機」，而是讓同一個資訊層級在窄與寬的視窗中都能成立。逐項搜尋以下程式模式：

• 直接寫死寬度、高度、欄位位置或按鈕座標。
• 以主螢幕尺寸代替目前 scene bounds。
• 以一次性的橫豎屏判斷決定所有子頁面的布局。
• 忽略 safe area，或自行繪製會壓住系統保留區的工具列。
• 把標準導覽控制器替換成沒有尺寸適應能力的自訂導覽列。
• 只在啟動時讀取尺寸，視窗改變後沒有重新計算內容。

Apple 的視圖控制器管理文件可用來核對容器與子視圖的責任邊界；場景尺寸限制文件則適合檢查應用是否錯誤限制了可用視窗範圍。

最小修改原則是：先讓約束、容器與 scene bounds 決定布局，只有在業務真的需要時，才讀取折疊或鉸鏈狀態。不要把專屬硬體邏輯散落到每一個 ViewController，否則下一次視窗或裝置形態調整時，回歸成本會快速增加。

第三階段：由單一畫面轉向多狀態驗收

完成布局調整後，測試範圍至少要包含以下四種狀態：

• 完全閉合：確認窄螢幕仍保留登入、付款、搜尋、返回等核心操作。
• 完全展開：確認內容不會只集中在一側，雙欄或主從關係有合理層級。
• 部分折疊：檢查折痕或保留區附近的文字、按鈕、拖曳元素與焦點狀態。
• 分屏、視窗縮放與畫中畫：檢查鍵盤、播放器、彈窗和背景恢復是否持續。

在這個階段，同一個測試案例要記錄「狀態改變前後」而不是只記錄最後一張畫面。例如，使用者在內螢幕填寫表單後折疊裝置，欄位內容是否仍在；播放器進入畫中畫後回到應用，導覽堆疊是否被重新建立；分屏後按鈕是否仍位於可觸控區域。

注意：如果業務不需要依照鉸鏈狀態改變功能，不要為了測試而建立鉸鏈專用分支。先驗證系統尺寸變化能否讓布局自然重排，只有產品需求明確要求姿態感知時，才把硬體狀態納入 API 與驗收標準。

第四階段：把回歸測試分成自動化與人工觀察

第一週的回歸矩陣，至少應加入啟動流程、關鍵頁面尺寸、旋轉或視窗變化、背景恢復、鍵盤避讓、輔助功能與登入狀態。自動化 UI 測試適合驗證元素存在、文字可見、按鈕可點擊、流程能完成；但視覺比例、手勢連續性、折疊中的觸控反應與攝影機預覽，仍要安排人工觀察。

你可以使用以下決策條件設定門檻：

• 若固定尺寸只出現在非核心裝飾區，且所有核心流程通過，則先記錄為低優先級，進入後續修復。
• 若固定尺寸造成按鈕不可點擊、付款內容裁切、登入流程中斷或資料遺失，則阻斷建置，不進入灰度發布。
• 若模擬器能重現布局問題，則先修復並加入 UI 回歸案例；否則不要把「模擬器未發現問題」當成真機通過。
• 若問題只涉及攝影機附件、觸控熱區、發熱、耗電或折疊過程連續性，則標記為真機必測，不用猜測模擬器結果。
• 若工具或 API 仍是 beta，則把版本狀態與測試日期寫入報告，並在提交前按官方文件重新核對。

真機上市後：只補證據，不要重新做無邊界全量測試

上市後的第一輪真機驗收，應對照上市前基線，集中補齊模擬器無法證明的項目：

1. 以正式簽署版本安裝，確認啟動、更新與資料遷移。
2. 重現閉合、展開與部分折疊過程，觀察頁面是否短暫閃爍、跳位或丟失焦點。
3. 實測攝影機預覽、拍攝附件、麥克風、定位與外接配件。
4. 在長時間操作、背景切換與充電情況下觀察溫度、耗電與記憶體成長。
5. 以Apple 官方真機分發文件核對註冊裝置與安裝流程。
6. 根據阻斷缺陷數量，決定立即發布適配版本、先做小範圍灰度，或繼續觀察。

這種做法能把折疊 iPhone 兼容測試控制在可管理範圍：上市前處理布局與狀態邏輯，上市後用真機確認硬體交互與長時間運行，而不是把每個頁面重新手動點一遍。

FAQ：把上市前適配疑問轉成可執行判斷

現有 iPhone 應用一定要重寫嗎？

不一定。先檢查布局約束、scene bounds、safe area 與導覽容器；只有固定尺寸已經影響核心流程，或自訂元件無法在不同視窗狀態下重排，才需要局部重構。整個應用推倒重來，通常不是 iPhone Duo 應用適配的第一步。

沒有真機能否提前完成測試？

可以先完成大部分布局與流程驗證，但不能宣稱已完成完整兼容。只要測試涉及攝影機附件、觸控區域、鉸鏈連續性、發熱或耗電，就要在正式硬體到手後補測。模擬器的價值是縮短等待，不是取代所有真機證據。

折疊 iPhone 應用兼容測試如何估算時間？

用缺陷風險估算，而不是用螢幕數量估算。標準布局可先排一個工作日做環境、基線與風險篩選；若含自訂導航、雙欄、相機或多視窗，就要再安排核心修復、回歸和真機複核，並把阻斷缺陷獨立列入發布門檻。

最後的環境決策：擴充本地 Mac，還是短期使用雲端 Mac

如果你目前只靠一台本地 Mac，短期適配衝刺常見的問題是建置被長時間測試佔用、Xcode 版本互相干擾、QA 無法並行取用一致環境；若直接把工作搬到一般雲端伺服器，還可能遇到 macOS 圖形介面、簽署憑證、頻寬、遠端觸控觀察與持久化硬碟管理等限制。對需要真機連線或長期重負載的團隊，自購並固定一套 Mac 仍較容易控管；但只是為了上市前增加幾個建置與測試節點，臨時擴充硬體往往會留下閒置成本。

你可以先閱讀MacPull 的 Mac 開發環境資訊，再按專案週期評估是否需要短期增加可用 Mac、分離 Xcode 版本與測試並發。若你的團隊正處於 iPhone Duo 上市前的兼容衝刺，租用 MacPull 的環境通常比臨時採購設備更容易控制週期；但若是全年穩定的大型建置、需要固定實體介面，或必須長期保留真機實驗室，則應把自有設備與真機矩陣一併納入總成本，而不是只比較單次租用費。

常見問題