可调整大小的 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 模式，不会再让设备屏幕卡住直到重启）。²

在两个界面中，各把每一个主要页面走一遍。你找到的 bug 会集中在那些做过缓存、做过假设或做过推断的页面上。

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 大多能自动适应，固定尺寸的假设则会以 bug 的形式浮现。

为了实现连续可调整大小，我还需要声明全部四个方向吗？

不需要。当前发行说明把方向这一条件标记为 Fixed（它在 beta 4 版与 beta 6 版之间得到解决），并指出”所支持的界面方向不应再成为连续可调整大小的条件”。¹ 更早的 beta 确实需要”声明全部四个方向”这一临时方案，如果你已经发布了它，那么有必要了解它对整个 App 的副作用。

UIRequiresFullScreen 现在被弃用了吗？

没有。它仍然是受支持的键，而 beta 周期中围绕其调整大小行为的已知问题，在当前发行说明里被列在已解决的问题之下并标记为 Fixed。¹ 但它恰恰属于那种存在多年、值得在一个”可调整大小优先”的平台上郑重重新决定的退出选项。

这件事什么时候会变得紧迫？

iOS 27 的正式版预计在 9 月发布，而按照 Apple 的秋季 SDK 要求周期，此后新提交的 App 会依照 Apple 的惯常时间表转向 iOS 27 SDK。对大多数 App 而言，上面这份清单是一周左右的专注工作——现在开始，就能从容地在发布季之前完成。

参考来源