iOS 27 的 iPad 尺寸连续调整：变通方案是有代价的

Apple 在 iOS 27 发行说明中，为那些无法连续调整尺寸的 iPad App 给出了一句话的变通方案：在 Info.plist 里声明支持全部四个界面方向。¹ 这句话没有提到的是，系统会把这份 App 级声明与每个视图控制器所支持的方向取交集。² 一旦放宽 App 级的集合，各处都会随之放宽，iPhone 也不例外——除非每一个需要受限的视图控制器都重写了 supportedInterfaceOrientations。

而这项变更被广为流传的那个版本，对现状的描述同样是错的。 Apple 的意图是让已声明的方向不再成为尺寸连续调整的前提条件。但记录这一意图的发行说明条目被归在“已知问题”之下，因为在 Beta 4 中，它们依然是前提条件。¹

这两点都要紧。当前行为是一个 bug，它正走在一次有意变更的路上；而修补这个 bug 的变通方案有副作用，却没人把它写在同一页上。

一句话总结

在 iOS 与 iPadOS 27 Beta 4 中，凡是使用 iOS 27 SDK 构建、且 UISupportedInterfaceOrientations 缺少四个方向中任意一个的 iPad App，都会被当作不可连续调整尺寸——Apple 把这条列为已知问题，同时又声明方向“不应再成为尺寸连续调整的条件”。¹ 文档给出的变通方案是四个方向全部声明。这样做会在整个 App 范围内放宽方向集合，而系统正是通过比对 App 级方向与各视图控制器的方向来决定是否旋转。² 另有四条已知问题与 UIRequiresFullScreen 有关：本应以离散 UIScreen 变更方式送达的更新，却以连续调整尺寸的形式送达。¹ UIRequiresFullScreen 与 UISupportedInterfaceOrientations 均未被弃用。³⁴

发行说明究竟写了什么

iOS 与 iPadOS 27 Beta 4 发行说明的 UIKit 部分，有六条与此相关，其中五条尚未解决。¹

限制条件本身，归在“已知问题”之下：

“在 iPad 上，如果您的 iPad App 使用 iOS 27 SDK 构建，且其 UISupportedInterfaceOrientations 未包含全部四个界面方向，该 App 会被视为不可连续调整尺寸。自 iOS 27 起，所支持的界面方向不应再成为尺寸连续调整的条件。”

留意第二句的措辞。“不应再成为条件”描述的是预期行为。这一条之所以以已知问题的形式存在，正是因为已发布的行为尚未与意图对齐。

这个区分决定了您该怎么做。假如方向真的已经不再限制尺寸调整，那么建议就该是移除变通方案。但既然它们仍在起限制作用，建议就是先用上变通方案，同时预期它存在的理由终将消失。

围绕 UIRequiresFullScreen 的四条已知问题：

使用 iOS 27 SDK 构建、并设置了 UIRequiresFullScreen 的 iPad App 会收到连续的尺寸调整更新，而“每次尺寸变化本应作为一次离散变更，送达一个带有更新后 bounds 的新 UIScreen”。同样的情况也出现在 iPad 上运行的纯 iPhone App 上，以及 iPhone 镜像中。¹

第四条涉及 iPhone 镜像中的方向处理：使用 iOS 27 SDK 构建的 App 会得到一个支持全部方向的 scene，“无论 UISupportedInterfaceOrientations 中声明了什么，也无论 UIViewController.supportedInterfaceOrientations 返回了什么”，而这些声明“本应在用户开始调整窗口尺寸之前一直得到遵守”。¹

已解决一条： 此前那条关于 UIRequiresFullScreen 下 UIScreen.main bounds 在调整尺寸时发生变化的问题，如今已出现在“已解决问题”中。¹ 它在此前的 beta 中还是一条有效的已知问题。如果您手头的笔记是几周前记的，先核对这一条，别再照抄。

尺寸连续调整究竟带来了什么

在权衡代价之前，值得先把被限制的那件事说清楚，因为“可连续调整尺寸”这个说法承载着具体的含义。

iPad 窗口有两种改变尺寸的方式。它可以在若干离散状态之间跳变——这正是处于兼容模式的 App 所得到的待遇：用 Apple 的话说，系统“为您的 App 维持一个一致的 scene 尺寸，但不会以全屏方式呈现 App 的 scene”。³ 或者，它可以跟随拖拽，在用户移动尺寸控件的过程中持续接收中间尺寸。

差别体现在用户的手上。可连续调整尺寸的 App 会随窗口移动实时重排布局。不可连续调整的那种则保持原布局，最后一刻才吸附到位——与不这么做的系统 App 摆在一起，就显得迟钝。

多年来，Apple 一直在收窄兼容路径。UIRequiresFullScreen 于 iOS 9 引入，用于彻底退出 iPad 多任务与动态尺寸调整。³ iPadOS 16 的台前调度与 iPadOS 26 的窗口化 App 模式各自扩展了窗口的能力边界，而文档如今对兼容模式的描述，重心已从“它给了什么”转向“它不给什么”。

所以变通方案回答的问题其实是：您的 iPad App 是参与现代窗口化，还是停留在一个 Apple 持续收窄的模式里。这值得改一次 Info.plist。但不值得毫无防护地改——这正是下一节要说的。

变通方案的代价

Apple 的变通方案只用一句话交代：在 Info.plist 中声明全部四个界面方向。¹ 而它的后果写在另一个页面上。

UIViewController.supportedInterfaceOrientations 记录了旋转是如何被决定的：²

“为判定是否旋转，系统会比较视图控制器所支持的方向、App 所支持的方向（由 Info.plist 文件或 App delegate 的 [方法] 确定）以及设备所支持的方向。”

三个集合，取交集。Info.plist 中的声明是天花板，不是指令。一个仅靠在 Info.plist 里列出单一方向来维持竖屏、且从未在视图控制器层面做过任何重写的 App，在套用变通方案的那一刻就失去了约束。

对通用 App 而言，影响会同时落在 iPhone 和 iPad 上。而 Apple 自己的指引恰恰反对在 iPhone 上做这种宽泛声明：关于倒置竖屏方向，“最佳做法是仅为 iPad idiom 启用它。没有 Home 键的 iOS 设备，例如 iPhone 12，并不支持这一方向。您应当为 iPhone idiom 彻底禁用它。”² Info.plist 文档从另一个角度说了同样的话，指出系统会在“没有 Home 键的设备上”忽略倒置竖屏。⁴

所以老实的做法是两步，而不是一步：

<!-- Info.plist: the ceiling. Required for continuous resizability on iPad. -->
<key>UISupportedInterfaceOrientations</key>
<array>
    <string>UIInterfaceOrientationPortrait</string>
    <string>UIInterfaceOrientationPortraitUpsideDown</string>
    <string>UIInterfaceOrientationLandscapeLeft</string>
    <string>UIInterfaceOrientationLandscapeRight</string>
</array>

// And the floor, on every controller that must stay constrained.
final class CaptureViewController: UIViewController {
    override var supportedInterfaceOrientations: UIInterfaceOrientationMask {
        UIDevice.current.userInterfaceIdiom == .pad ? .all : .portrait
    }
}

跳过第二步，等于是为了换取 iPad 上的一种窗口化行为，让一个通用 App 在 iPhone 上也能倒置旋转。故障不会表现为崩溃或构建报错，而是有人正在使用相机取景时，画面突然翻了过来。

另外还要注意，supportedInterfaceOrientations 的默认值因 idiom 而异，而且只有当 shouldAutorotate 返回 true 时系统才会去查询它。² 如果您重写过后者，在断定自己的约束仍然成立之前，值得把这两者的相互作用重读一遍。

判断自己是否受影响

这一切都不会产生构建错误，所以排查只能靠手工。三项检查，按省时程度从高到低排列。

逐个 target 查看 Info.plist 到底声明了什么。 方向相关的键往往在建项目时设过一次，之后再没人回头看；而通用 App 还可能通过 UISupportedInterfaceOrientations~ipad 为 iPhone 和 iPad 携带两套不同的声明。两边都要读。

# Every orientation and fullscreen declaration across the project
rg -l 'UISupportedInterfaceOrientations|UIRequiresFullScreen' --glob '*.plist'

# And what each one says
/usr/libexec/PlistBuddy -c "Print :UISupportedInterfaceOrientations" Info.plist
/usr/libexec/PlistBuddy -c "Print :UIRequiresFullScreen" Info.plist

键不存在时 PlistBuddy 会以非零状态退出，而这本身就是 UIRequiresFullScreen 的答案：没有这个键，说明您从未进入过兼容模式。

找出在代码里约束方向的那些控制器。 它们是 Info.plist 改动之后仍然有效的部分；而它们的缺席，正是这项改动危险的原因。

rg 'supportedInterfaceOrientations|shouldAutorotate' --type swift

搜索结果为空、同时 Info.plist 声明又很窄——这正是会出问题的典型画像：App 完全依靠属性列表才保持竖屏，一旦放宽，唯一存在过的约束就没了。

然后在两种 idiom 上实地看看这个 App。 故障是视觉上的，自动化信号很弱。一个驱动界面并断言其内容的 UI 测试，在任何方向下都会通过。您要找的是一个此前不能旋转、现在却旋转起来的视图，这意味着改完 Info.plist 后要跑一次 iPhone 构建，并真的把设备或模拟器转一转。

媒体采集、文稿扫描、签名输入、游戏，以及任何具有固定宽高比画布的界面，是意外旋转代价最高的地方，也最明显地属于该做逐控制器重写的地方。

UIRequiresFullScreen 正在被掏空，而不是被弃用

五条未解决问题中有四条涉及 UIRequiresFullScreen。¹ 这个用来让 App 退出 iPad 多任务的键，如今却成了尺寸调整更新送达出错的条件。

它并未被弃用。UIRequiresFullScreen 的文档显示可用性为 iOS 9.0 与 iPadOS 9.0，没有弃用标记、不可用标记或 beta 标记。³ UISupportedInterfaceOrientations 同样如此，自 iOS 3.2 起可用。⁴

这个组合值得点破。一个在 2026 年仍设置 UIRequiresFullScreen 的 App，编译时不会有警告，发布时不会有迁移提示，却落进了一个 Apple 持续收窄的兼容模式。文档已经写明这个模式在现代系统上意味着什么：在支持窗口化 App 模式的 iPad 上运行 iPadOS 26 及更高版本时，以及在支持台前调度的 iPad 上运行 iPadOS 16 及更高版本时，系统“为您的 App 维持一个一致的 scene 尺寸，但不会以全屏方式呈现 App 的 scene”。³

这个键已经不再做它名字所说的事。它没有被淘汰，而您的构建过程也不会告诉您这一点。

规律：SDK 链接决定一切

上面每一条都共享同一个前提，而这个前提并不是操作系统版本。每一条适用的都是“使用 iOS 27 SDK 构建”的 App。¹

同一份源码，不同的二进制，不同的行为。这一点在本次发布中反复出现：菜单项图片取决于您链接的是哪个 SDK，跨两代 SDK 共有三种不同行为。而 macOS 27 的跨团队容器访问拒绝 看起来是相反的情形——一项没有 SDK 限定的系统级策略。这恰恰说明，这个区分值得逐条核实，而不是想当然。

对测试的实际影响是：针对 iOS 26 SDK 的构建与针对 iOS 27 SDK 的构建是两个不同的对象。如果您的 CI 矩阵只有一个 Xcode 版本，那它只测了其中一个。

现在该做什么

先判断您是否真的需要尺寸连续调整。 如果您的 iPad App 本来就声明了全部四个方向，这里所说的一切都与您无关。变通方案只在您有意收窄过方向时才有意义。

如果套用变通方案，务必同时配上逐控制器的重写。 Info.plist 的改动只是天花板；约束必须转移到那些需要它的控制器的 supportedInterfaceOrientations 中，并按 idiom 区分。

单独排查 UIRequiresFullScreen。 有四条未解决问题与它相关，而构建过程不会给出任何提示。把所有 Info.plist 文件都 grep 一遍，包括那些您根本没当成 iPad App 的 target——因为其中一条问题涉及的正是在 iPad 上运行的纯 iPhone App。

预期这道限制终将消失。 Apple 明确表示方向不应再成为尺寸连续调整的条件。等这一变化落地，声明全部四个方向的理由随之消失，但被放宽的方向集合会一直留在您的 Info.plist 里，直到有人把它删掉。留一条注释，说明它当初为什么在那儿。

动手之前重新核对发行说明。 这六条中已经有一条从“已知问题”移到了“已解决”。本文反映的是截至 2026 年 8 月 2 日的 Beta 4 状态。

要点回顾

给 iPad App 开发者： - 在 Beta 4 中，已声明的方向仍然限制着尺寸连续调整，尽管 Apple 声明它们不应如此。请把它当作一个带变通方案的 bug，而不是新行为。 - 变通方案会放宽整个 App 的方向天花板。请补上逐控制器的 supportedInterfaceOrientations 重写，否则您的 iPhone 版本就会开始旋转。 - 有四条未解决问题涉及 UIRequiresFullScreen 送达连续而非离散的尺寸调整更新。

给维护老 App 的人： - UIRequiresFullScreen 未被弃用，也不会产生任何警告，而它所请求的那种行为却在不断收窄。请明确地把它排查一遍。 - 这里的每一条问题都以“使用 iOS 27 SDK 构建”为前提，而不是以用户运行的系统版本为前提。

常见问题

已声明的方向是否已经不再限制尺寸连续调整？

在 Beta 4 中还没有。Apple 声明“自 iOS 27 起，所支持的界面方向不应再成为尺寸连续调整的条件”，却把这句话归入了已知问题——因为当前行为仍然以它们为限制条件。¹

具体的变通方案是什么？

在 UISupportedInterfaceOrientations 中声明全部四个界面方向。¹ 同时，在那些必须保持受限的视图控制器上重写 supportedInterfaceOrientations，因为系统会把 App 级集合与各控制器的集合取交集。²

这会影响我的 iPhone 构建吗？

如果您发布的是通用 App，且仅靠 Info.plist 来约束方向，会。Apple 建议为 iPhone idiom 彻底禁用倒置竖屏，并指出系统会在没有 Home 键的设备上忽略它。²⁴

UIRequiresFullScreen 被弃用了吗？

没有。其文档显示可用性为 iOS 与 iPadOS 9.0，没有弃用标记。³ 这里的未解决问题中有四条与它相关，所以别把“没有弃用标记”读成一种背书。

Apple 修好这道限制之后，我该把变通方案撤掉吗？

撤掉不再需要的那部分，保留能保护您的那部分。当已声明的方向不再成为尺寸连续调整的条件，列出全部四个方向的理由就消失了，您可以把 UISupportedInterfaceOrientations 收回到 App 真正支持的范围。而逐控制器的 supportedInterfaceOrientations 重写无论如何都该保留——把方向约束表达在约束真正归属的地方，比依赖一个 App 级天花板要经久得多。

要避免的失败模式恰恰是反过来：把 Info.plist 收窄回去，却忘了那些重写才是唯一让采集界面保持正立的东西。

我怎么知道自己的 App 现在是不是可连续调整尺寸？

在 iPad 上调整窗口尺寸，看布局是跟随拖拽实时变化，还是到最后才吸附到位。跟随拖拽即为可连续调整。如果是吸附，检查两件事：是否设置了 UIRequiresFullScreen（它会彻底退出动态尺寸调整），以及 UISupportedInterfaceOrientations 是否列出了全部四个方向（这正是这条已知问题所描述的条件）。¹³

针对更旧的 SDK 构建，能否规避这一切？

每一条都以使用 iOS 27 SDK 构建为前提。¹ 更旧的 SDK 可以规避这些具体问题，但那只是把最终的变更往后推，并不能阻止它。

参考来源