可調整大小的 iPhone 時代：在 9 月之前讓 App 做好準備

該如何讓一個 iPhone App 為可調整大小的螢幕做好準備？ Apple 畫下的那條線，就是您連結的 SDK。Xcode 27 的發行說明明確指出，對於連結 iOS 26 或更早 SDK 的 App，Device Hub 的 resize 模式並不支援；而 iOS 27 發行說明中每一則與調整大小有關的條目，都以「使用 iOS 27 SDK 建置」為前提。¹² 接著要做的是：盤點每一處固定尺寸的假設（讀取 UIScreen.main.bounds、寫死的 frame、以方向為條件的佈局），改為倚賴 size class 與能夠適應佈局的 SwiftUI 容器，並在 Xcode 27 的 Resizable Canvas 預覽與 Device Hub 的 resize 模式中持續測試。² 過去卡住連續可調整大小的方向前置條件，在目前的發行說明中已標示為 Fixed，路已經通了。¹

整個夏天，Apple 的秋季 beta 都在向 iPhone 開發者收斂出同一個訊息：別再假設螢幕是一個固定的矩形。證據不在發表會上，而在工具與發行說明裡——可調整大小隨著 iOS 27 SDK 的連結而來，預覽畫布可以自由縮放，而隨著 beta 週期趨於成熟，發行說明也清掉了最後一道結構性障礙。無論今年秋天推出什麼硬體，軟體層面的約定都已經改變。

重點摘要： iOS 27 為以新 SDK 建置的 App 帶來連續可調整大小的能力；Xcode 27 提供了配套的測試介面（Resizable Canvas 預覽、Device Hub 的 resize 模式）；而目前的發行說明——也就是 8 月 24 日推出的 beta 7 版——把方向這道關卡列為 Fixed：該條目在 beta 4 版與 beta 6 版之間移出了已知問題，宣告的方向不再決定 App 能否調整大小。¹ 這項工作大多是做減法：找出佈局中「相信只有一種螢幕尺寸」的地方，然後把那份信念拿掉。以下就是這份檢查清單，順序即是我實際執行的順序。

為什麼是現在

三個有明確日期的事實正在推動時鐘：

1. beta 7 於 8 月 24 日推出，週期已進入穩定階段——Apple 的後期 beta 以修正為主而非新增功能，而正式版每年都在 9 月推出。¹
2. 可調整大小的界線就是 SDK 連結。 Xcode 27 的發行說明把「使用連結 iOS 26 或更早 SDK 的 App」進入 Device Hub 的 resize 模式描述為「unsupported」。² 同樣的模式也貫穿 iOS 的發行說明：每一則調整大小相關的條目都以「使用 iOS 27 SDK 建置」為條件。重新建置，您就站在這條線可調整大小的那一側；留在舊 SDK 上，等於主動退出平台前進的方向。
3. 最後一道結構性關卡已經解除。 在 beta 4 時期，若某個 iPad App 的 UISupportedInterfaceOrientations 少了四個方向中的任何一個，系統就會將它視為不支援連續調整大小——這是一則已知問題，而它所記載的暫行做法帶有未被寫明的代價，我在討論這項暫行做法的文章裡分析過。該條目在發行說明的 beta 4 版與 beta 6 版之間移出已知問題，目前版本則將它列為 Fixed：「從 iOS 27 開始，所支援的介面方向不應再成為連續可調整大小的條件。」beta 7 發行說明中 UIKit 的已知問題清單是空的。¹

三點合起來看：平台現在期待您的佈局是容器的函式，而不是裝置規格表的函式。iPad 先透過多工教了這一課，iOS 27 則把同一份約定延伸到 iPhone。

檢查清單

1. 用 iOS 27 SDK 重新建置，然後真的去看一眼

選擇加入的動作就是重新建置。在改動任何一行佈局程式碼之前，先用 Xcode 27 建置，打開 Device Hub 的 resize 模式，然後拖曳看看。多數結構良好的 SwiftUI App 在這第一次接觸中的表現，往往比作者預期的更好；而壞掉的地方很有啟發性，而且每次都壞在同樣的那幾處——這份清單接下來談的，正是那幾處。

2. 獵捕固定尺寸的成見

依照通常咬人的先後順序，典型的問題點如下：

• 把 UIScreen.main.bounds 當成「螢幕尺寸」。 在可調整大小的世界裡並不存在那個螢幕尺寸，而 UIScreen.main 自 iOS 26 起已正式棄用。請從 window scene 推導尺寸；在 SwiftUI 中則透過容器推導——節制地使用 GeometryReader，或是有意識地使用 containerRelativeFrame(_:)。
• 針對特定裝置校準的寫死 frame 與魔術數字（「寬度 390 點就是 iPhone」）。任何 if width == <數字> 式的裝置推斷，遲早都會騙您。
• 以方向而非尺寸作為佈局條件。 方向判斷向來只是替代指標；隨著 iOS 27 把方向與可調整大小脫鉤，這個替代指標正式成了累贅。請改用水平與垂直 size class 分支，那本來就是它們的用途。
• 在啟動時快取尺寸。 任何在啟動時量測一次並存起來的值，第一次調整大小之後就已經過期。

3. 讓自適應容器去做它們該做的事

SwiftUI 的現代佈局工具正是為此而生：ViewThatFits 用來在多種排列之間做選擇，containerRelativeFrame 用來相對於容器而非螢幕決定尺寸，網格與彈性 frame 則涵蓋兩者之間的一切。如果您的 App 可以追溯到固定矩形的年代，效益最高的重構通常是把一處承重的「GeometryReader 加上算術」佈局換成這些基本元件。UIKit App 也能透過 size class 搭配 UICollectionViewCompositionalLayout 由環境驅動的 section，得到相同的結果。

iOS 27 中工具列與佈局的變化推的是同一個方向——框架現在會在空間耗盡的節點把明確的控制權交給您，而空間如今是動態耗盡的。

4. 在真正發生調整大小的地方測試

Xcode 27 提供了兩個為此打造的介面，兩者都在 beta 週期早期就已成熟：

• 預覽中的 Resizable Canvas 模式——不再受限於特定的尺寸比例（該限制在 beta 2 中解除），因此您可以拖曳走過 App 可能呈現的所有形狀。²
• 針對執行中 App 的 Device Hub resize 模式，其退出路徑的缺陷自 beta 3 起已修正（因當機或切到背景而離開 resize 模式，不會再讓裝置螢幕卡住直到重新開機）。²

請在這兩個介面中，各把每一個主要畫面走過一遍。您找到的錯誤會集中在那些做過快取、做過假設或做過推斷的畫面上。

5. 重新檢視多年前設下的旗標

UIRequiresFullScreen 以及範圍收窄的 UISupportedInterfaceOrientations 宣告，向來是 App 用來退出 iPad 多工要求的手段。兩者都尚未棄用，但如今都以新的方式承擔著結構性的份量——beta 週期花了好幾個版本釐清它們與連續可調整大小之間如何互動，而 beta 4 時期圍繞 UIRequiresFullScreen 調整大小行為的那些已知問題，目前都被列在已解決的問題底下並標示為 Fixed。¹ 如果這些鍵還留在您的 Info.plist 裡，只是因為 2019 年做過的某個決定，那麼本月正是刻意重新做一次決定的時候。暫行做法的代價分析一文，整理了在放寬任何設定之前該檢查的方向集合副作用。

6. 為二階效應預留餘裕

可調整大小意味著：文字換行的方式變了，圖片裁切的方式變了，NavigationSplitView 會隨著某個人的心意收合又展開，而您細心調校過的空狀態畫面，會以從未預覽過的長寬比出現。這些事情單獨看都不難。但正是這一切，讓這份清單必須從現在開始，而不是等到硬體推出的那一週。

我會略過的部分

略過對特定裝置的臆測。可調整大小這份約定就在今天可以下載的 SDK 裡，寫在今天可以閱讀的發行說明中，也能用第一版 Xcode 27 beta 就已提供的工具測試。如果摺疊 iPhone 在今年秋天登場，做完上述清單的 App 已經就緒；若它明年春天才到，同樣的工作也會立刻在 iPad 多工，以及平台下一個要調整大小的場景中回本。為機制做準備，勝過為傳聞做準備。

重點整理

• 選擇加入的界線是 SDK 連結。 用 iOS 27 SDK 重新建置，可調整大小就同時成為您 App 的課題與機會；Device Hub 對舊 SDK 建置的 App 在 resize 模式下視為不支援。²
• 方向這道關卡已經解除。 宣告的方向不再決定能否調整大小——該問題在目前的發行說明中標示為 Fixed，UIKit 的已知問題清單也是空的。¹
• 這項工作是刪除假設，而不是增加功能。 螢幕尺寸的讀取、魔術數字佈局、方向替代指標、啟動時的快取：找出來，換成由容器推導的佈局，就完成了。
• 在真實的介面中測試。 Resizable Canvas 預覽與 Device Hub 的 resize 模式正是為此而存在；每個畫面在兩者中各走一遍，就能找出大部分日後會咬人的問題。

常見問題

我的 App 會自動變成可調整大小嗎？

Apple 畫的界線是 SDK 連結——Xcode 27 的發行說明稱，對 iOS 26 或更早 SDK 建置的 App 使用 resize 模式並不支援，而 iOS 的發行說明把每一項調整大小行為都以使用 iOS 27 SDK 建置為條件。¹² 之後會發生什麼，則取決於您的佈局：以容器驅動的 SwiftUI 多半能自行適應，固定尺寸的假設則會以錯誤的形式浮現。

為了達成連續可調整大小，我還需要宣告全部四個方向嗎？

不需要。目前的發行說明把方向這項條件標示為 Fixed（它在 beta 4 版與 beta 6 版之間獲得解決），並指出「所支援的介面方向不應再成為連續可調整大小的條件」。¹ 更早的 beta 確實需要「宣告全部四個方向」這個暫行做法，若您已經推出過它，那麼值得了解它對整個 App 的副作用。

UIRequiresFullScreen 現在被棄用了嗎？

沒有。它仍是受支援的鍵，而 beta 週期中圍繞其調整大小行為的已知問題，在目前的發行說明裡被列在已解決的問題底下並標示為 Fixed。¹ 但它恰恰屬於那種存在多年、值得在一個「可調整大小優先」的平台上鄭重重新決定的退出選項。

這件事什麼時候會變得急迫？

iOS 27 的正式版預計在 9 月推出，而依照 Apple 的秋季 SDK 要求週期，此後新送審的 App 會按 Apple 的慣例時程轉往 iOS 27 SDK。對多數 App 而言，上面這份清單是一週左右的專注工作——現在開始，就能從容地在上市季之前完成。

參考來源