畫面一變窄，表單欄位重疊、底部按鈕被鍵盤遮住，回到頁面後編輯內容也消失。
最快解法：現在就做蘋果摺疊 iPhone 適配，移除固定螢幕尺寸假設，改用安全區、尺寸特徵與自適應布局，並測試視窗變化及程式中斷後的狀態恢復；不要為傳聞中的分辨率另寫一套介面。
截至 2026 年 9 月 5 日，蘋果尚未確認摺疊 iPhone 的產品名稱、螢幕形態或專用開發介面。你今天能可靠執行的工作，不是猜測螢幕尺寸，而是依據蘋果已公開的布局、尺寸特徵與狀態保存機制，先把現有 iOS 程式中最容易斷裂的假設清掉。
先確認你是否正面對這類適配風險
這篇內容適合三類團隊：
- 介面中存在固定寬高、絕對座標或依裝置型號分支的 iOS 開發者。
- 需要讓複雜表單、影片、編輯器或雙欄內容適應不同可用空間的產品團隊。
- 正在建立摺疊形態相容性用例、但尚未取得實體裝置的移動 QA 人員。
如果你的程式只在單一固定尺寸模擬器上驗收，現在最值得先查的不是新機傳聞，而是視窗寬度變化、系統安全區改變，以及應用程式在背景中被中止後能否回到原本任務。
先拆掉固定尺寸造成的布局斷裂
固定螢幕寬度的 iOS 介面應怎樣改？先不要把 UIScreen.main.bounds.width、裝置型號或設計稿截圖尺寸當成布局規則。這些值可以協助記錄問題，但不應直接決定按鈕位置、欄位寬度或列表層級。
你可以按照以下順序做程式碼審查：
- 搜尋固定寬高、絕對座標、硬編碼邊距，以及根據裝置名稱執行的
if分支。 - 找出依賴單一螢幕方向或單一視窗比例的自訂元件。
- 將「這個寬度代表手機」之類的判斷改為「目前可用空間是否足夠」。
- 對表單、列表、詳情頁和編輯器分別定義最小可用寬度，而不是讓所有元件按相同比例放大。
- 在同一頁面中檢查文字換行、按鈕最小觸控區域和內容優先級，避免寬度增加後出現大量空白，寬度縮小後卻把主要操作推到螢幕外。
SwiftUI 可用 ViewThatFits 在多個候選結構中選擇能容納內容的版本，而不是為假想摺疊螢幕建立專用尺寸。這個 API 的用途與限制可直接參考蘋果的 ViewThatFits 文件。UIKit 團隊則應把布局條件放在容器與特徵變化上，避免把裝置型號寫進視圖控制器。
一個常見的現場案例
例如編輯器目前在窄螢幕顯示「內容區＋固定右側工具欄」。設計稿寬度足夠時沒有問題，但當可用空間改變，工具欄會壓縮文字區，鍵盤出現後底部儲存按鈕又被遮住。
錯誤做法是為傳聞中的摺疊展開寬度新增第三套座標。較穩妥的做法是把工具欄改成可收合面板：空間不足時保留主要編輯操作，次要功能進入工具列或選單；空間充足時才呈現並排結構。這同時改善現有小尺寸裝置、分割視窗和外接顯示環境的可用性。
再處理安全區與內容裁切
可變螢幕尺寸應怎樣布局？安全區應由系統環境提供，而不是由團隊猜測開孔、鉸鏈或摺痕位置。不要因為媒體報道某種可能形態，就在頂部或中央預留永久空白；這會在現有裝置上直接浪費內容空間，也可能使真正的操作區變窄。
逐項檢查以下位置：
- 導航列標題和返回操作是否在安全區內。
- 自訂工具列、播放器控制項和全屏影片是否會貼近系統邊界。
- 底部固定按鈕是否會被 Home Indicator 或鍵盤覆蓋。
- 浮層、通知、錯誤提示和拖曳面板是否以目前視窗為基準。
- UIKit 視圖控制器是否能在安全區變更時重新布局。
UIKit 的 viewSafeAreaInsetsDidChange() 正是用來處理安全區變化的生命週期回呼，應把需要重新計算的內容集中在這裡，而不是只在初次載入時設定一次。官方 UIKit 文件也提醒你，安全區可能因環境改變而更新。
同時要檢查可及性。字體放大、較長的本地化文字和較大的觸控目標，往往比假想的摺疊形態更早暴露布局缺陷；可參考蘋果的人機介面可及性指南重新驗收。
讓窄版與寬版重組內容，而不是等比放大
自適應布局的核心不是「所有東西都變大」，而是決定在有限空間中什麼必須留下、什麼可以延後。
你可以為每一個主要流程寫出兩種結構：
- 列表頁：窄版先顯示標題、狀態和主要操作；寬版才增加預覽、分類或側欄。
- 詳情頁：窄版採用列表到詳情的連續導航；寬版可同時保留列表和詳情。
- 表單頁：窄版以單欄和分段流程為主；寬版才使用雙欄，但不可讓欄位失去清晰標籤。
- 編輯器：窄版保留輸入和儲存；寬版才顯示格式、歷史或輔助檢視。
- 影片頁：控制項必須能在方向變更後重新排列，不能只依賴固定的底部高度。
SwiftUI 可以用尺寸特徵和自適應容器切換結構；UIKit 則可將內容區、側欄和工具區拆成獨立容器，再由當前可用空間決定是否呈現。這樣做的優點是規則根據環境而不是產品傳聞，缺點是你需要重新確認導航層級、埋點和自動化測試的預期畫面。
把狀態與視圖尺寸分離
摺疊或展開時怎樣避免頁面狀態丟失？先列出使用者正在進行的任務，再決定哪些狀態必須保存。不要只保存目前頁面名稱，因為使用者回到頁面時，真正需要的是可繼續工作的上下文。
至少應檢查以下狀態：
- 尚未提交的文字和表單內容。
- 列表滾動位置與目前選取項目。
- 影片播放位置、是否靜音和全屏狀態。
- 篩選條件、排序方式與搜尋字串。
- 導航堆疊、目前編輯步驟和未完成的錯誤修正。
SwiftUI 可用 SceneStorage 保存與場景相關、可重建的介面狀態；官方 SceneStorage 文件適合用來確認哪些資料應由場景保存。UIKit 團隊則應按照UIKit 狀態恢復指南設計恢復識別資訊與編碼內容。
不要把大型草稿、敏感資料或不可安全序列化的物件全部塞進視圖狀態。較可靠的做法是：視圖只保存恢復所需的輕量識別資訊，真正草稿交由可持久化的模型或暫存層管理；恢復時重新取得資料，並處理資料已失效或權限已變更的情況。
把鍵盤、影片與背景切換放進同一組測試
很多布局問題不是單一方向變更造成，而是多個環境事件連續發生。例如使用者在表單中輸入文字，鍵盤彈出後旋轉畫面，接著切到背景播放影片，再回到前景；如果每個事件都會重建頁面，未保存內容就可能消失。
你應安排以下故障組合：
- 輸入法出現與收起時，底部操作區是否仍可觸及。
- 方向變更期間，是否重複發送資料請求或重建播放器。
- 相機、影片或麥克風權限流程中，視圖尺寸改變後是否遺失返回位置。
- 從前景進入背景再返回時，是否重複載入、重設篩選條件或清空草稿。
- 鍵盤動畫尚未完成時，浮層是否使用過期的視窗尺寸。
UIKit 可監聽鍵盤 frame 變更通知，確認內容區的底部 inset 與動畫同步；相關事件定義可參考官方鍵盤通知文件。SwiftUI 則應將前景與背景處理視為場景生命週期的一部分，使用 scenePhase 判斷何時保存草稿、停止非必要工作或重新整理資料，具體行為可對照官方 scenePhase 文件。
沒有摺疊 iPhone 真機也能先完成大部分排查
沒有摺疊 iPhone 真機怎麼提前適配？你不需要先知道未來裝置的精確尺寸，仍可用今天可取得的環境找出大多數布局和狀態問題。
建議按以下步驟執行：
- 在可調整視窗或不同尺寸模擬環境中，從窄到寬連續拖動，觀察布局是否只在初次載入時正確。
- 用現有不同螢幕尺寸的裝置驗證列表、表單、影片和編輯器，不要只截取首頁。
- 在自動化截圖測試中加入文字放大、鍵盤顯示、橫豎屏與長文字資料。
- 強制程式進入背景，再回到前景，確認草稿、滾動位置、導航和播放狀態。
- 對每個可變尺寸畫面記錄「主要操作是否仍可見、可按、可恢復」，並將失敗案例附上環境與重現步驟。
- 等實體產品與新 SDK 官宣後，再補驗鉸鏈形態、觸控區域、效能和系統專屬互動；在此之前不要建立未經確認的專用分支。
在你的多尺寸 iOS 介面驗收流程中，可把這組測試分成布局、狀態、輸入與背景切換四個類別。若團隊需要並行測試不同配置，也可先查看配置測試環境的服務選項，再決定哪些檢查適合本機、哪些適合遠端執行。
用這張表決定現在做什麼、真機出現後再做什麼
| 檢查面向 | 現在即可完成 | 暫時不要做 | 官宣或取得真機後補驗 |
|---|---|---|---|
| 布局 | 移除固定寬高，測試可用空間與內容重組 | 依傳聞分辨率新增分支 | 驗證專用尺寸特徵與系統行為 |
| 安全區 | 使用系統安全區，測試導航、浮層與底部操作 | 為猜測的鉸鏈或開孔預留空白 | 驗證真實裁切、觸控與邊緣互動 |
| 狀態 | 保存草稿、篩選、滾動、導航和播放上下文 | 把狀態綁在某個視圖尺寸 | 驗證尺寸變更期間的系統恢復流程 |
| 輸入與媒體 | 測試鍵盤、方向變更、相機與前背景切換 | 只驗證冷啟動首頁 | 驗證實體裝置效能與特殊手勢 |
| QA | 可調整視窗、不同尺寸裝置、自動化截圖 | 等真機才開始建立用例 | 增加鉸鏈、觸控區與硬體相關案例 |
如果你目前的方案是只針對固定尺寸模擬器驗收，缺點是容易漏掉安全區更新、鍵盤遮擋和背景恢復；如果改用未證實的摺疊尺寸做專用介面，缺點則是提前增加維護分支，還可能在正式設計不同時全部重做。對需要臨時並行測試、遠端驗收或自動化截圖的團隊，租用 Macstripe 的 Mac 測試環境通常比臨時購買多台裝置更容易調整；但若你需要長期穩定重負載、實體相機或特殊硬體介面，自購 Mac 與本地真機仍更合適。你可以先從Macstripe 的配置訂單頁匹配短期測試需求，再把可變尺寸回歸結果納入正式 QA 流程。
