外屏与内屏切换后，按钮偏位、内容留白或被裁切。 最快解法：用 Xcode 27.1 的 iPhone Duo 模拟器复现，再查固定尺寸、方向假设和工具栏避让；多数情况先修布局，不必重写整套界面。
这篇适合仍以旧 SDK 构建 App、想确认 iPhone Duo 显示效果的独立开发者。 使用固定宽高、自定义导航栏或固定方向的 SwiftUI／UIKit 项目，可以按场景逐项排查。 负责远程构建与提交的小团队，也可以据此判断模拟器验收应放进发布流程的哪些位置。
**先分清 SDK 边界：**旧 SDK 构建的 App 能运行，不代表它会自动扩展到全部屏幕空间。Apple 对不同 SDK 构建的显示方式有明确区分，应先确认当前包的构建 SDK，再决定是否重建与适配。[Apple 的 iPhone Duo 准备指南](https://developer.apple.com/iphone-duo/prepare/)说明，iOS 26 SDK 或更早版本构建的 App 在内屏会以熟悉的窗口尺寸居中显示；iOS 27 SDK 可动态适配并填充大部分内屏；iOS 27.1 SDK 或更新版本则可使用完整显示区域，并采用垂直工具栏与标签栏布局。
先按构建 SDK 判断：旧 App 能运行，是否需要重新构建？
先记录 App 实际使用的构建 SDK，不要把部署目标版本当成构建 SDK。前者决定 App 可安装运行的系统范围；后者关系到系统如何为新屏幕布局提供适配行为。若旧版构建在内外屏都能完整操作，且你不需要利用更大的内屏空间，可以先保留现有构建；若出现留白、控制项被遮挡，或你希望界面延伸至屏幕边缘，就应使用新 SDK 重新构建并复测。
| 构建 SDK | Apple 确认的 iPhone Duo 显示方式 | 适配空间评分* | 适合的判断 |
|---|---|---|---|
| iOS 26 SDK 或更早 | 内屏以熟悉尺寸居中；外屏内容位于状态栏与相机区域左侧 | 2/5 | 能正常运行但有留白，评估是否需要重建 |
| iOS 27 SDK | 动态适应尺寸，填充内屏大部分区域；右侧仍避开状态栏 | 3/5 | 已适配尺寸变化，但需检查边缘布局 |
| iOS 27.1 SDK 或更新 | 使用完整显示区域；工具栏与标签栏可垂直排列 | 5/5 | 想充分利用显示空间，继续做界面验收 |
第一步：在内屏与外屏切换时抓住错位证据
iPhone Duo 上 App 为什么会显示不全或留下空白？常见原因不是“模拟器把界面弄坏了”，而是界面仍依赖固定宽高、固定屏幕比例，或用设备型号推断可用空间。窗口尺寸变化后，这些假设可能让内容没有扩展、被裁切，或仍停留在旧位置。Apple 的设计指南建议按可用空间适配，并结合尺寸类别、安全区域和边距，而不是绑定某个具体显示尺寸；折叠区域也会改变可用内容空间。部分系统组件会自动避让，但自定义组件仍需检查。
在模拟器中先选一个最容易出问题的页面，例如自定义导航栏、表单、横向滚动区或内容较密的首页。分别记录外屏、展开后的内屏，以及改变窗口尺寸后的界面：同一页面、同一数据、同一操作路径，才能看出差异来自布局，而不是页面状态变化。保存复现步骤和对照截图，不要只记“看起来偏了”。
重点检查这三类隐藏成本：
- 固定尺寸成本：写死宽、高或边距，可能让内屏留下大片空白，也可能让较窄区域中的内容溢出。
- 方向假设成本：只按竖屏或横屏设计时，姿态切换后控件可能重叠，滚动区域也可能无法到达底部。
- 设备判断成本：依赖设备型号决定布局，遇到新的窗口尺寸或分屏空间时，代码可能走错分支。
第二步：从外屏切换到内屏，改为依据可用空间布局
内屏和外屏切换后的适配重点，不是为每种姿态另做一套界面，而是让当前布局响应容器和环境变化。SwiftUI 可读取水平与垂直尺寸类别；Apple 的尺寸类别文档说明，尺寸类别会受设备类型、方向以及窗口空间等因素影响，并可能在运行期间变化。
如果你用 UIKit，先检查视图是否读取当前 trait，而不是只在初始化时确定布局。UITraitCollection 提供尺寸类别等界面环境信息；Apple 的UIKit trait 文档说明，可以依据这些 trait 变化调整布局。
| 发现的现象 | 优先检查 | 验收标准 |
|---|---|---|
| 内屏边缘留白明显 | 固定宽度、固定边距、内容容器最大宽度 | 内容按当前容器扩展；留白是设计选择，而非旧尺寸残留 |
| 折叠或调整窗口后内容被裁切 | 固定高度、裁切容器、滚动区域约束 | 主要内容可见，超出部分可滚动到达 |
| 同一控件随方向切换跳位 | 设备型号判断、只在初次加载时计算的 frame | 改变尺寸后重新布局，控件仍可见且操作有效 |
| 屏幕边缘内容被系统控件挡住 | 安全区域、边距、手动避让偏移 | 文字与可点控件不进入被遮挡区域 |
safeAreaLayoutGuide 文档](https://developer.apple.com/documentation/uikit/uiview/safearealayoutguide)。
第三步：检查 iOS 27.1 SDK 下工具栏与标签栏的位置变化
iOS 27.1 SDK 的工具栏变化可能暴露旧 App 的空间假设：工具栏与标签栏改为垂直排列后，原本沿屏幕边缘放置的内容、按钮或自绘导航条，可能和系统控件争用空间。使用系统标准组件通常更容易获得平台适配；如果你自绘了导航栏或工具栏，就要单独核对遮挡、点击区域和常用操作是否仍然可达。
按以下次序检查，不要先重排整页：
- 打开主要页面，确认返回、关闭、提交等关键操作没有被内容覆盖。
- 检查标签栏是否遮住滚动内容，或因固定底部边距留下不必要的空带。
- 点按工具栏每个按钮，确认视觉位置与实际响应区域一致。
- 比较外屏、内屏和不同姿态下的主操作顺序；如果自定义栏与系统布局冲突，先考虑回到系统组件，而不是增加更多固定偏移。
**排查边界：**如果布局正常、但按钮点击后执行了错误动作，先查状态管理、路由或操作逻辑。把所有异常都归因于模拟器，会让真正的功能缺陷漏过验收。
第四步：在自定义界面中分别验证遮挡、交互与状态
自绘控件、固定方向页面和复杂内容容器需要拆开检查。第一遍只看内容是否被裁切、折叠区域附近是否有重要信息；第二遍测试按钮、滑动区和输入控件的实际操作范围；第三遍在内外屏或姿态切换后，检查编辑内容、选中项和滚动位置是否保持合理。
若你的页面本身有双栏或重叠结构，可先评估它是否适合系统提供的自适应排列，而不是为每种姿态复制一套完整页面。Apple 的设计建议是使用灵活布局、适应可用空间，并避免把界面绑定到特定显示尺寸；具体改法仍应以可复现的界面问题为依据，不能把单一代码写法当成所有项目的通用解法。
第五步：建立 Xcode 27.1 模拟器验收矩阵，再作提交判断
把模拟器检查纳入界面回归时，沿用同一操作路径，并把模拟器结果与真机验收分开记录。以下步骤可以直接加入你现有的验收流程：
- 核对工具链。确认项目实际使用的 Xcode 与 SDK，并检查运行 Xcode 的 macOS 是否满足 Apple 要求。Xcode 27.1 发布说明列出 iOS 27.1 SDK，并注明需要 macOS Tahoe 26.6 或更新版本；具体要求见 Xcode 27.1 发布说明及 Apple 的Xcode 系统要求页面。
- 建立基线。在修改前保存旧构建的模拟器截图、构建设置和复现路径，便于判断变化来自 SDK 还是代码。
- 复现代表场景。依次打开外屏与内屏，改变窗口尺寸或姿态；每次只改变一个条件，并记录留白、裁切、错位或遮挡发生的位置。
- 修最小范围。先移除不合理的固定尺寸或设备判断，再依据当前容器、尺寸类别和安全区域调整。避免同时改导航结构、状态逻辑和布局，否则难以定位回归原因。
- 重复相同操作。使用修改前的路径重测，检查主要内容可见、按钮可达、切换后状态合理，并确认其他页面没有因共享组件改动而受影响。
- 区分验收结论。模拟器通过只证明这组模拟环境中的布局表现符合预期，不等于真机体验已验证，更不保证 App Store 审核通过。发布前仍要按团队的真机与提交流程确认。
最后按三个判断收口：旧 SDK 版本显示稳定、无需充分利用内屏空间，可以暂缓重建；需要内屏动态扩展或工具栏完整适配，就用 iOS 27.1 SDK 构建并完成上述回归；模拟器布局通过但功能逻辑仍异常，则继续查应用代码，不能据此宣告真机或提交流程全部通过。
如果本地没有符合要求、可运行 Xcode 27.1 的 Mac，远程 Mac 可以作为临时复测与构建环境；但网络访问延迟、远程会话稳定性和凭据管理都要纳入你的发布安排。你可以先从 MACGPU 的 Mac 环境选项核对是否适合自己的模拟器验证需求；若布局工作会长期持续，购买本地 Mac 也值得与租赁方案比较，可参考现有 Mac 机型选项。若你需要的是短期复测而非长期常驻构建，优先按实际使用周期评估远程环境；若工作负载长期稳定或依赖本地物理接口，则本地设备可能更合适。
最后更新于 2026 年 10 月 23 日；版本与系统行为核实自 Apple 的 iPhone Duo 准备指南、设计指南、Xcode 27.1 发布说明及 Xcode 系统要求页面。