症狀：iPhone Duo 上出現留白、裁切或工具列擠壓；最快解法：先用 Xcode 27.1 的 iPhone Duo 模擬器重現，再檢查固定尺寸、方向假設與工具列佈局，通常不必重寫整個介面。
舊 SDK 建置的 App 仍可執行，但「能執行」不等於已充分利用新顯示空間。若你要確認舊版是否需要重新建置，先以實際畫面為依據，再按本文的情境完成適配與驗收。
仍以舊 SDK 建置 App、想確認 iPhone Duo 顯示效果的獨立開發者，可先判斷是否需要適配。 使用固定寬高、固定方向或自訂導覽列的 SwiftUI／UIKit 開發者，可按具體症狀排查。 負責遠端建置與提交的小團隊，可把模擬器檢查納入發佈流程，但不要把它當成真機驗收或審核結果的保證。
最後更新於 2026 年 10 月 23 日；版本與系統行為核對自 Apple iPhone Duo 準備指南、設計指南及 Xcode 27.1 發布說明。
先用模擬器定位 iPhone Duo App 版面錯位
舊 SDK 建置的 App 能在 iPhone Duo 上正常顯示嗎？ 可以執行，不代表一定會按新裝置的完整可用空間重新配置。Apple 指出，使用 iOS 27 SDK 的 App 會動態適應顯示尺寸；採用 iOS 27.1 SDK 或更新 SDK 建置，才可使用更完整的螢幕佈局，並須留意工具列與標籤列的變化。準備指南
這表示你應把兩個判斷分開：先確認現有版本是否可用，再判斷是否要以較新的 SDK 重建，讓介面配合新空間。不要僅因舊版可以啟動就認定適配完成，也不要在尚未重現問題前先重寫整套介面。
| 排查選項 | 適合情況 | 主要檢查點 | 工程排序 |
|---|---|---|---|
| 保留舊建置並觀察 | 既有功能可用，尚未確認版面問題 | 內外螢幕是否裁切、留白或遮擋 | 中 |
| 以 iOS 27 SDK 建置後重測 | 希望介面按顯示尺寸動態適應 | 尺寸變化時的內容重排 | 高 |
| 以 iOS 27.1 SDK 建置並驗收 | 需要採用較完整佈局並核對工具列變化 | 安全區、主要操作與標籤列可見性 | 高 |
依內外螢幕切換檢查尺寸假設
為什麼切到內螢幕後會留白或顯示不全？ 常見原因不是螢幕本身，而是介面把某個固定寬高、固定邊界或裝置型號當成可用空間的替代指標。當可用區域改變，固定尺寸可能留下空白；內容容器若沒有收縮或重排機制，則可能被裁切或壓到其他控制項。
依 Apple 的準備資料，使用 iOS 27 SDK 的 App 會動態適應顯示尺寸；因此，排查時應將內外螢幕切換前後的畫面並列，而不是只檢查啟動時的初始狀態。
按以下順序留下可重現證據：
- 以同一組操作進入問題畫面，記錄目前採用的建置版本與模擬器狀態。
- 在外螢幕截取問題畫面，再切換至內螢幕，以相同操作路徑記錄結果。
- 比對內容容器邊界、文字換行、按鈕位置，以及是否出現留白、裁切或重疊。
- 在程式碼中搜尋固定寬高、固定邊距，以及根據裝置型號推斷畫面尺寸的分支。
- 調整後重複相同操作，確認版面變化與原始問題之間有可追蹤的對應關係。
核對旋轉、折疊與自訂介面的狀態
內外螢幕切換後如何判斷是版面錯誤，還是功能邏輯出錯？ 先分開觀察視覺位置與操作結果：如果內容被遮住、控制項移位或點擊區域與畫面不一致，優先檢查佈局、安全區與自訂繪製；如果畫面位置正確但操作結果錯誤，再追查狀態更新、導覽流程或資料載入。
自訂導覽列、手繪控制項、固定方向畫面和複雜容器尤其值得逐項檢查。切換姿態後，即使主要內容還在螢幕內，點擊區域也可能沒有跟著更新；反過來說，點擊失效也未必是版面問題。記錄重現步驟時，請把「畫面看起來不對」和「操作結果不對」分成兩項，避免把所有異常都歸因於模擬器。
UIKit 專案可檢查 trait 變化與安全區參照；Apple 的 UITraitCollection 文件說明 trait collection 的用途。自訂介面若直接計算位置，也要確認計算依據會隨可用空間變化，而不是只在最初載入時設定一次。
依工具列與標籤列變化核對主要操作
iOS 27.1 SDK 的工具列位置變化會影響舊 App 嗎？ Apple 已說明，以 iOS 27.1 SDK 或更新 SDK 建置的 App 可採用更完整的螢幕佈局，並需留意工具列與標籤列的佈局變化；這不等於每個舊 App 都必然出現問題。你應先確認目前使用的 SDK，再檢查具體操作是否仍可見、可點擊且不被內容遮擋。Xcode 27.1 發布說明
逐項驗收時，先查看主要動作按鈕與標籤列是否仍在預期位置，再確認內容有沒有延伸到工具列下方；接著實際操作，而不只憑截圖判斷控制項是否可用。若工具列是自訂繪製，或畫面以固定留白避開系統元件，應特別檢查原有的空間假設是否仍成立。官方的 iPhone Duo 設計指南可協助核對系統介面與 App 內容的安排方式；以模擬器重現的結果則應記下建置 SDK 與操作路徑，方便回歸比對。
按 SwiftUI 或 UIKit 修正，而非重造整套介面
SwiftUI 專案應優先檢查什麼？ 先找出依賴固定 frame、固定留白或特定尺寸類別的視圖，再確認父容器改變可用空間時，子視圖是否能調整。尺寸類別可作為判斷環境的參考，但不應把一種寫法當成適用所有畫面的通用解法；仍須以實際出錯的容器、內容與互動方式決定修正範圍。SwiftUI 尺寸類別文件
UIKit 專案則先核對 trait 變化如何傳遞、約束是否能適應容器尺寸，以及主要內容是否依安全區配置。使用自訂導覽列或自行計算位置時，應將問題畫面的重現證據對應到具體約束或計算邏輯，再做局部修改，而不是為每一種姿態複製一套獨立介面。UIKit trait 可參照前述文件；內容避讓可依 safeAreaLayoutGuide 文件核對。
修正完成後，保留原本操作路徑重新測試：若位置正確但狀態丟失，處理狀態保存；若控制項仍被遮擋，回查容器與安全區；若不同尺寸下呈現正常且操作一致，才進入下一輪整合測試。這種逐項驗證可避免把一次畫面修正誤當成整個介面已完成適配。
以模擬器結果決定是否進入發佈驗收
怎樣用 Xcode 27.1 模擬器檢查版面？ 先確認工具鏈可用，再以代表性的內外螢幕與姿態重現問題，保存修正前後的畫面與操作記錄，最後依發佈需求決定是否進行真機驗收。Apple 的 Xcode 系統需求頁面可供核對工具版本與執行環境要求；模擬器通過只代表已檢查相應模擬情境，不等同真機結果，也不保證 App Store 審核通過。
建議將這些檢查納入團隊流程：
- 環境核對：確認使用的 Xcode、SDK 與模擬器版本，並以 Apple 系統需求頁確認目前環境是否符合要求。
- 問題重現：固定進入畫面的操作方式，分別記錄內外螢幕、旋轉或姿態變更後的顯示與操作結果。
- 修正留證：把問題畫面與改動位置連結，記錄修正後相同操作是否仍能重現。
- 回歸檢查：除了原問題，也核對主要操作、內容避讓與狀態保持，避免修好一種顯示情況卻破壞其他流程。
- 發布判斷：把模擬器驗收結果與真機測試、簽名及提交檢查分開記錄；缺少真機覆核時，不要把模擬器結論寫成真機驗收完成。
如果本地沒有符合 Xcode 27.1 系統需求的 Mac，購買實機會先產生硬體支出，也要自行管理硬碟空間、系統更新與長時間運行；租用遠端 Mac 則可在需要期間取得可操作的 macOS 環境，但不適合必須直接連接實體裝置、或需要長期固定高負載而更重視自有硬體的情況。你可先確認本機能否執行所需工具，再依模擬器驗收與建置需求評估 MACGPU；iPhone Duo App 版面錯位是否已修好，仍應以可重現的畫面和操作結果判定。