2026 iOS 27 視窗適配：別等摺疊 iPhone 的驗收清單

勝出方案：現在就開始 iOS 27 視窗適配，不要等待摺疊 iPhone 的名稱或尺寸官宣。只要程式仍依賴固定螢幕畫布、設備類型或方向判斷，便應立即遷移 scene lifecycle，清理 UIScreen.main 相關布局邏輯，並用 Xcode 27 建立連續尺寸驗收；摺疊 iPhone 的傳聞只影響日後增加哪些測試點，不影響今天啟動改造。

這篇適合仍維護大量 UIKit 舊程式、固定寬度布局的開發者；也適合要建立 iPhone Mirroring、iPad 與新形態視窗回歸矩陣的 QA 團隊。若技術負責人正評估本地 Mac 是否能支撐 Xcode 27 多執行個體測試，文中的分工與算力判斷也可直接套用。

截至 2026 年 8 月 23 日更新：可調整視窗、scene lifecycle 與相關 API 方向，依 Apple Developer 的 WWDC26 Session 278、UIKit 文件及 Xcode 27 發行說明核實。摺疊 iPhone 名稱、螢幕尺寸、售價與上市安排仍未獲正式確認；秋季活動日期亦不應當作驗收前提。相關活動日期報道

先把適配基線從「裝置」改成「視窗」

Apple 已確認 iOS 27 與 macOS 27 下，iPhone Mirroring 的 App 視窗可以自由調整大小；iPhone-only App 在 iPad 上也可調整視窗。WWDC26 Session 278 同時把 scene lifecycle、避免依賴主螢幕引用，以及不以設備類型和方向作為布局核心，放進開發者需要處理的方向。Session 278 文字稿

這代表團隊的適配基線應改成以下三項：

• 場景基線：畫面屬於哪個 UIWindowScene，由 scene 狀態與視窗上下文決定，不再假設 App 永遠只有一個主畫面。
• 空間基線：布局依據是目前容器或 View 的可用寬度、高度與 safe area，而不是某個 iPhone 型號的固定畫布。
• 變化基線：視窗尺寸可能連續改變。程式必須在變化時更新約束、內容比例、觸控座標與快取。

團隊可以把需求分成三層。Apple 已確認的行為與文件要求屬於必須修正；能令布局更能應付連續尺寸的 trait、容器和元件重構屬於建議改造；摺疊 iPhone 的特定尺寸則屬於日後補充測試。未官宣的產品參數不能先拿來設計 breakpoint。

UIKit 舊程式：從 API 審計開始，而不是先加更多斷點

第一輪不應由設計稿開始，而應由全域搜尋開始。搜尋以下呼叫與條件：

• UIScreen.main
• UIScreen.bounds、screen.bounds
• UIDevice.current.userInterfaceIdiom
• interfaceOrientation
• 依裝置名稱、螢幕比例或縮放倍數切換布局的判斷
• 舊式 App lifecycle 中直接建立或管理視窗的程式

UIScreen.main 並不是在 iOS 27 被簡單刪除。真正的風險是它代表的螢幕不一定是目前 scene 所在的螢幕，因而可能回傳與現行視窗不匹配的資訊。Apple 的 UIScreen.main 說明 與 UIWindowScene.screen 文件 應分開閱讀，不能把「API 還存在」當成「適合拿來做布局」。

舊寫法常見於自訂 ViewController：

let width = UIScreen.main.bounds.width
if width < 500 {
    showCompactLayout()
}

替代方向不是把 500 換成另一個數字，而是讓布局讀取目前 View 的實際邊界，或交由 Auto Layout、size class 與 trait collection 決定：

override func viewDidLayoutSubviews() {
    super.viewDidLayoutSubviews()
    let availableWidth = view.bounds.width
    updateLayout(for: availableWidth)
}

若程式需要取得目前視窗上下文，應由當前 View、ViewController 或 UIWindowScene 往上取得，而不是全域抓主螢幕。Apple 的 scene 設定文件 與 scene lifecycle 遷移指南 可作為程式碼審查依據。

開發者的優缺點判斷：

• 保留固定裝置斷點：修改快，但 iPhone Mirroring、iPad 調整視窗和未來尺寸會暴露死角。
• 改用當前可用空間：初期需要重整容器與元件，但驗收條件能從「某部裝置」轉成「某種空間狀態」。
• 只修畫面、不修 lifecycle：靜態截圖可能通過，scene 重建、背景返回前景時仍可能拿到舊尺寸。

SwiftUI 與混合架構：找出被包裝層藏起來的固定尺寸

SwiftUI 頁面不代表天然完成 iOS 27 視窗適配。常見問題是用 UIDevice、方向或預設寬度切換整套 View，或者由 UIKit 包裝層傳入固定 frame。這些寫法在傳統裝置選擇測試中可能正常，連續拖曳時卻會出現內容突然跳版、按鈕離開可視區、列表寬度不更新。

審查時可按畫面類型分工：

• 導覽結構：窄視窗時確認返回入口仍可見；寬視窗時確認多欄導覽不會留下空白欄。
• 彈窗與表單：檢查內容高度變化後，確認按鈕不被鍵盤、safe area 或視窗底部遮住。
• 列表與卡片：移除以設備名稱選擇欄數的條件，改驗證容器寬度改變時的重排。
• UIKit 包裝層：搜尋 preferredContentSize、固定 frame 和傳入 SwiftUI 的寬高，確認它們不是由一次性螢幕讀值生成。
• 文字內容：加入動態文字尺寸，再拖曳視窗；不要只用固定長度的測試字串。

SwiftUI 的 View 變化要看容器提供的空間。UIKit 與 SwiftUI 混合時，邊界資料只應有一個可信來源，避免 UIKit 用 UIScreen.main 算一次，SwiftUI 又以自己的容器寬度算第二次。團隊可參考 Apple 的 UIKit 彈性布局示例 檢查元件是否真正依賴可用空間。

全螢幕內容：遊戲、地圖和自繪畫布要同步更新

全螢幕偏好不是免除視窗適配的理由。遊戲、地圖、影片和 Metal 畫布至少要核對以下鏈路：

• 視窗變化後，渲染 drawable 或畫布尺寸是否更新。
• 觸控點是否仍以同一套座標系轉換。
• 依尺寸建立的紋理、地圖快取與裁切區域是否重建或失效。
• 內容比例改變時，產品是選擇裁切、留黑邊，還是重新排版；決定必須寫入驗收預期。
• 尺寸快速變動時，是否每次事件都觸發昂貴重建，導致操作中出現模糊或閃動。

這裡不能從「看起來變模糊」推導具體幀率，也不能宣稱某個 Mac 配置一定能達到某個性能。驗收記錄應寫明畫面現象、出現條件、裝置與版本，再依官方文件或本站實測補充性能結論。對於非全螢幕的地圖和影片頁面，也要測試窄視窗下控制列是否仍能觸及。

QA 的驗收入口要互補，而不是重複點幾部裝置

Xcode 27 的 Device Hub、Xcode Previews、iPhone Mirroring 與真實 iPad，適合承擔不同風險。Xcode 27 發行說明可用來核對當前測試工具與版本行為；模擬器環境設定文件 則可參考可調整尺寸的配置方式。Xcode 27 Release Notes

QA 不應只在報告中寫「iPhone 16 通過」。每一筆案例應記錄：

• 測試入口：Device Hub、Preview、iPhone Mirroring、iPad 或真機。
• 視窗狀態：窄、寬、拖曳中、比例變更、前景返回。
• 重現步驟：由哪個頁面開始，調整尺寸後執行哪個操作。
• 證據：截圖或錄影、版本、scene 狀態及相關日誌。
• 結果：布局是否溢出、互動是否不可達、內容快取是否刷新。

可直接交給 QA 的驗收清單：

• [ ] 從登入頁拖曳到窄視窗，確認主要按鈕、錯誤訊息和鍵盤避讓仍可見。
• [ ] 從窄視窗連續拖至寬視窗，確認列表、表單和多欄布局沒有停留在舊狀態。
• [ ] 在 iPhone Mirroring 中調整尺寸後，重新進入導覽、彈窗與編輯頁。
• [ ] 在 iPad 上測試 iPhone-only App 的可調整視窗，記錄內容裁切與可觸控範圍。
• [ ] 開啟動態文字，再重複窄、寬視窗測試。
• [ ] 將 App 送入背景後返回，確認 scene 尺寸、渲染畫布與快取同步。
• [ ] 對遊戲、地圖、影片及自繪頁面檢查比例、黑邊、模糊、觸控座標和重建行為。
• [ ] 每個失敗案例附上環境、窗口狀態、步驟、截圖、負責人和未解決項。

這份清單的通過條件是「狀態改變後仍可操作」，不是「在幾部傳統機型上截圖相同」。

技術負責人：用並行測試量決定是否擴充 Mac

完成程式碼掃描後，技術負責人可把工作分成三類：

• 可自動替換：明確的主螢幕讀值、舊 lifecycle 入口和重複的固定尺寸常數。
• 需要人工重構：依設備類型切換整套布局、UIKit 傳固定寬高給 SwiftUI、共用容器狀態不清的頁面。
• 必須專項回歸：Metal、地圖、影片、遊戲、自繪 Canvas，以及依賴觸控座標和快取的模組。

接著估算並行工作數：同時編譯的分支數、模擬器執行個體、真機占用時段，以及 QA 是否需要遠端共同查看畫面。若只是單一開發者、低頻回歸，繼續使用個人 Mac 通常較直接；若多位開發者需要一致的 Xcode 27 環境，或驗收週期被編譯與模擬器排隊拖慢，臨時增加雲端 Mac 測試環境會更容易按人數和週期調整。

取捨也要寫清楚：

• 個人 Mac：硬體介面和本地除錯方便，但多人共用時會受排程、版本漂移與本機資源限制。
• 雲端 Mac：適合短期並行、遠端驗收和統一環境，但需要處理連線品質、頻寬、權限與真機功能限制。
• 自購 Mac：適合長期穩定重負載和需要實體介面的團隊，不適合只為一次相容性回歸而增加固定資產。

正式簽字前，文件應列出負責人、程式碼掃描結果、測試環境、每個失敗案例的證據連結、未解決項與回退方案。若團隊需要先確認遠端環境的登入、權限及連線方式，可先查看 ProxyMac 的幫助中心；若已算出短期並行需求，再對照香港方案資訊，不要在尚未統計測試量前直接選固定配置。

FAQ：把五個高頻疑問轉成驗收動作

請以 FAQ 的答案作為程式碼審查和測試案例的補充，不要把摺疊 iPhone 的傳聞尺寸寫成斷點。正式產品資訊公布後，再新增對應的尺寸與上市裝置測試。

結論：今天改 API，官宣後才補測試點

目前方案若繼續依賴固定螢幕尺寸，會有三個實際缺點：iPhone Mirroring 或 iPad 調整視窗後可能取到錯誤布局依據；背景返回或 scene 切換後可能保留舊尺寸；QA 只能用少數裝置截圖，難以發現連續縮放中的互動死角。若再讓多位成員共用一部本地 Mac，Xcode 27 版本一致性與模擬器排隊也會拉長驗收週期。

因此，已完成 API 審計並算出並行測試量的團隊，可把 ProxyMac 的租用 Mac 作為短期測試環境，按團隊人數、模擬器數量和測試週期安排擴容。它不會取代需要實體介面或長期高負載的自購 Mac，但對折疊 iPhone 官宣前的視窗回歸、遠端驗收和 Xcode 27 環境一致性，通常比臨時改動每位成員的本機更容易管理。

延伸閱讀

• 摺疊 iPhone Ultra 測試：從尺寸變化到相容性驗收
• iOS 27 Golden Gate 開發者 Beta：提早規劃 App 適配與測試