介面在 iPhone Duo 模擬器中出現留白、拉伸或裁切，不一定是設計稿尺寸錯誤。
最快的排查方式：先確認專案使用的 SDK，再用 Xcode 27.1 模擬器逐一重現展開、摺疊與旋轉狀態；錯位優先檢查固定螢幕尺寸與只依裝置方向切換版面的邏輯。模擬器能協助找出問題，但不等於完成真機驗收。
適合需要把 Figma 設計意圖和原生畫面逐項核對的 UI 設計師，以及要檢視摺疊、展開、旋轉後關鍵流程的產品設計師。
專案或 QA 負責人也可用本文確認交付前需要哪些 Mac、Xcode 和裝置驗收安排。
最後更新於 2026 年 10 月 26 日；SDK 與模擬器資訊依 Apple iPhone Duo 準備指南、Xcode 27.1 發布記錄及相關技術說明核對。
先辨認錯位發生在哪個狀態
不要只截下一張「看起來不對」的畫面。先把問題描述成可重現的狀態：外螢幕或內螢幕、展開或摺疊、直向或橫向，以及畫面是留白、裁切、拉伸還是控件被遮擋。這些線索能協助分辨 SDK 顯示差異、可用空間變動和版面邏輯錯誤。
Apple 的準備指南指出，iOS 27 與 iOS 27.1 SDK 在 iPhone Duo 的螢幕利用方式上有差異。舊 SDK 建置的程式即使能執行，也可能未呈現更新 SDK 下的顯示範圍。因此，外螢幕或內螢幕出現留白時，先記下建置使用的 SDK，不要只憑畫面判定素材尺寸錯誤。Apple 的 iPhone Duo 準備指南與 Xcode 27.1 發布說明可用來核對版本背景。
| 觀察到的狀況 | 優先核對 | 判斷方向 |
|---|---|---|
| 邊緣有異常留白 | 建置所用 SDK、問題出現的螢幕 | 比較相同姿態下不同 SDK 的畫面；先分清版本差異與資源留白 |
| 展開後內容位置偏移 | 展開前後實際可用寬高、版面斷點 | 檢查是否以固定螢幕邊界計算位置 |
| 旋轉後選錯版面 | 可用寬高或 size class、方向切換條件 | 不要假設同一方向必然對應同一種應用程式區域 |
| 按鈕或工具列被擠壓 | 安全區域、可用空間、工具列排列 | 分別核對內容區和可觸控控件，不要只看背景是否鋪滿 |
SDK 與畫面狀態對照
| 檢查項目 | 要記錄的資料 | 為什麼有用 |
|---|---|---|
| SDK | 專案建置使用的 SDK 版本 | 區分版本行為與版面本身的缺陷 |
| 裝置姿態 | 展開、摺疊及旋轉狀態 | 讓團隊能以相同條件重現錯位 |
| 螢幕位置 | 內螢幕或外螢幕 | 判斷問題是否只影響特定顯示範圍 |
| 異常類型 | 留白、裁切、拉伸或遮擋 | 將後續檢查集中到尺寸、裁切或控件位置 |
展開或摺疊後內容突然位移
展開與摺疊會改變應用程式可使用的空間。如果版面仍根據一個固定的螢幕尺寸計算內容位置，就可能出現控件偏移、空白區域過大，或內容被推到可視範圍以外。這類問題通常不是只改一張背景圖就能修好。
可請開發人員確認版面讀取的是視窗或視圖當下的實際範圍，而非假設整個螢幕永遠維持同一個邊界。UIKit 的 UIView bounds 文件說明了視圖自身座標空間的邊界；若使用 SwiftUI，可參考 GeometryReader 文件，核對版面如何依據容器幾何資訊調整。
設計師不必先讀懂程式碼，也能檢查幾個結果：主要標題是否仍在預期位置、主要按鈕是否可見且可觸及、展開後新增的空間是否被合理使用。若只有其中一個狀態出錯，應把該姿態和螢幕位置一併交給開發團隊，而不是只附一張沒有狀態說明的截圖。
提醒：背景圖片填滿寬螢幕，不代表前景按鈕仍處於安全且可觸及的位置。背景裁切與互動控件位置要分開驗收。
旋轉後版面分支選錯
裝置方向本身不足以判斷 iPhone Duo 上應採用哪種版面。若設計或程式只用「直向／橫向」切換，就可能在方向相同、但應用程式可用區域不同的情況下，套用不合適的排列。
排查時先比較實際可用寬度與高度，再看目前使用的版面斷點或 size class。Apple 的 iPhone Duo 技術講解涵蓋姿態與應用程式區域的檢查方式，可供團隊核對具體測試情境。設計複核則應回到稿件上的斷點：旋轉前後，主要內容、導覽和關鍵操作是否仍符合原有設計意圖。
如果寬螢幕狀態下圖片主體被切掉，請分開記錄圖片裁切與內容版面。圖片可以採用不同裁切策略，但不可因此遮住主要操作；工具列和標籤列也要留意是否因空間變化而重新排列。若主要按鈕被擠到螢幕邊緣，應再檢查安全區域和可用空間，而非單純縮小整組介面。
可重現的排查流程
以下流程適合設計交付前與開發、QA 團隊一起操作；每次只變更一項條件，才能看出錯位是否跟版本或姿態相關。
- 記錄建置版本。 請開發人員確認專案實際使用的 SDK，並記下 Xcode 版本。不要只記錄本機安裝了哪個 Xcode，因為安裝版本和專案建置使用的 SDK 不是同一項資訊。
- 固定問題樣本。 選一個最容易出錯的主要畫面，記下入口、畫面內容及操作步驟，例如打開頁面後展開裝置；同一份樣本供設計、開發和 QA 使用。
- 逐一改變姿態。 在 Xcode 27.1 的 iPhone Duo 模擬器中，分別檢查展開、摺疊及旋轉狀態；每次只改一項，並記下異常是否跟著該狀態出現。
- 比對可用空間。 若異常只在展開或旋轉後出現，請開發人員核對視窗或視圖實際範圍、版面斷點和 size class，並檢查是否使用固定螢幕邊界。
- 逐項看交互控件。 核對主要按鈕、工具列、標籤列及安全區域；另外檢查大幅圖片或影片的主體有沒有被裁掉，不要把背景填滿當成版面通過。
- 留下可交接紀錄。 每個樣本保留螢幕位置、姿態、SDK、重現步驟與截圖，並標出設計稿中對應的斷點或關鍵元素。
- 劃分驗收責任。 模擬器複核可用於發現版面問題；實際裝置的觸控、顯示和最終交付驗收，仍應由負責真機測試的團隊完成。Apple 亦分別說明了在模擬裝置或實體裝置上執行程式的方式。
若需要交接一個精簡紀錄，可用這段文字模板；以下輸出只是記錄格式示例，不代表實際測試結果：
SDK：請填入專案建置使用的版本
螢幕：外螢幕／內螢幕
姿態：展開／摺疊／旋轉
異常：留白／裁切／拉伸／控件遮擋
重現步驟：請按操作順序填寫
結果：請貼上對應模擬器截圖
iPhone Duo 模擬器錯位常見問題
介面被拉伸或裁切時，先檢查什麼？
先記下異常發生的螢幕位置、裝置姿態和專案 SDK，接著用相同條件重現。若只有某個姿態出現問題，再檢查固定螢幕尺寸、視窗實際範圍及圖片裁切方式；若不同 SDK 的呈現不同，先確認版本差異，不要立即重製素材。
展開後版面不合，應看螢幕尺寸還是方向？
先看應用程式實際可用的寬高或 size class，再核對方向判斷。展開會改變可用空間，方向相同也不表示版面區域相同。設計師可將稿件斷點、主要內容位置和按鈕可觸及性逐項比對，並把不一致的姿態交由開發人員檢查版面邏輯。
iOS 27 與 iOS 27.1 SDK 的顯示行為一樣嗎？
Apple 資料指出兩者的螢幕利用方式存在差異。舊 SDK 建置的程式可以執行，但不一定已按新 SDK 的顯示方式適配。排查時應保存建置所用 SDK，再在相同螢幕與姿態下比較；只有確認版本條件一致後，才適合判斷是否為設計資源或版面程式的錯誤。
沒有自己的 Mac，怎麼檢查原生介面？
可先請開發或 QA 團隊提供 Xcode 模擬器的姿態截圖、SDK 資訊和重現步驟。若設計師需要自行操作模擬器，則要安排可用的 Mac 與 Xcode 環境，並先用代表性專案驗證能否完成所需檢查。模擬器可供版面複核，不能取代真實裝置驗收。
沒有 Mac 時的檢查安排
Xcode 27.1 的 Device Hub 可用於檢查 iPhone Duo 模擬器中的不同姿態；Apple 的技術講解可協助團隊核對模擬器檢查方式。若設計師目前主要使用 Windows，先確認負責原生複核的同事能否提供 Mac 與 Xcode 環境；若團隊希望自行操作，再用自己的代表性專案測試環境是否符合工作需要。
沒有自有 Mac 時，可比較由開發團隊代為複核與短期使用遠端 Mac 兩種安排。代為複核較省去環境準備，但設計師未必能即時操作和反覆調整；遠端使用則可自行重現問題，仍需先確認可用環境與操作方式。NodeMini 的遠端 Mac 方案資訊可作為評估起點，但服務環境是否符合 Xcode 27.1 的實際需求，應先行確認，不能由此推定模擬器已覆蓋所有裝置狀況。
如果目前流程完全依賴 Windows，原生模擬器複核會多一道設備切換，團隊協作也可能受限於別人何時能提供畫面，且模擬器結果仍不能取代真機驗收。偶爾需要 Xcode 時，租用 Mac 可避免為短期檢查直接購置設備，也讓設計師能自行重現與記錄錯位；若要評估這種短期方案，可查看 NodeMini 的 Mac 使用選項，並先以代表性專案確認環境是否可用。若工作長期依賴穩定的本機 Mac，或驗收必須接觸實體裝置，則應安排自有設備或由團隊負責真機測試，不宜把遠端模擬器當成完整替代方案。