2026 折叠屏 iPhone Ultra 测试：没有真机怎么测 App？

截至 2026 年 8 月 5 日，Apple 官方已经展示了 Xcode 27 的可调整尺寸预览和 Device Hub resize mode，但仍未确认折叠屏 iPhone、iPhone Ultra 名称、折叠状态 API 或外屏规则。(developer.apple.com)

获胜者：Xcode 27 的动态尺寸测试，适合现在验证布局、状态连续性和全屏内容；它不能替代折叠屏真机，也不能证明传闻设备参数。 当前最稳妥的做法是：先用 SwiftUI Previews 和 Device Hub 做通用自适应回归，把折叠姿态、外屏行为和专属交互列为“等待 Apple 确认”的项目。

这篇内容适合三类人：

• 维护 SwiftUI 或 UIKit 存量 App，担心宽屏和动态尺寸导致页面失效的 iOS 工程师。
• 需要制定移动端回归范围，并把传闻转成可执行测试项的测试负责人。
• 希望新品发布后快速交付兼容版本，但目前没有足够本地 Mac 测试资源的研发主管。

固定尺寸通过，不等于动态尺寸通过

一个典型失败案例是：App 在常规 iPhone 模拟器中启动、登录、下单都正常，截图验收也通过；但运行过程中把窗口从窄拖宽后，顶部导航仍按旧宽度计算，右侧按钮被截断，返回栈中的页面出现错位。重新启动 App 后问题暂时消失，于是团队误以为只是模拟器异常。

这类假阴性来自测试目标错误。固定设备尺寸只能回答“App 在某个初始边界内是否能显示”，不能回答“可用空间发生变化时，布局和状态是否仍然有效”。

Apple 在 iOS 27 的适配说明中强调，运行环境可能出现可调整的窗口尺寸；UIKit 开发者应把布局判断回到当前视图空间、trait collection 和 size class，而不是继续依赖接口方向。(developer.apple.com)

现在可以验证的项目包括：

• 宽度和高度变化时，约束、间距、文本换行是否重新计算。
• compact 与 regular size class 切换时，导航、侧栏和工具栏是否改变。
• 场景进入后台、断开、重连后，草稿和深层导航是否保留。
• 播放器、地图、相机和绘图画布是否更新渲染尺寸。
• 大字号、深色模式和本地化长文本叠加后，是否出现内容截断。

现在不能下结论的项目包括：

• 折叠与展开是否产生某种官方事件。
• 外屏是否运行独立任务，或与内屏共享同一个场景。
• 折痕、铰链区域是否存在专属安全区。
• 传闻屏幕尺寸、比例、厚度和性能是否准确。

据媒体报道，折叠屏 iPhone 可能在 2026 年 9 月 与 iPhone 18 Pro 同台亮相，也有供应链报道声称产品已进入量产阶段；这些信息尚未获得 Apple 官方确认，发布与开售时间也可能分离。(macrumors.com)

SwiftUI：从固定画布切换到连续预览

SwiftUI 项目最适合先做动态尺寸验证。Apple 已在 Xcode 27 的 Live Previews 中加入可交互的 resize handles，开发者可以连续改变预览尺寸，而不是为每一个传闻设备建立一张固定画布。(developer.apple.com)

建议按以下顺序检查：

1．先找出硬编码宽度

搜索并逐项复核：

• frame(width:)、frame(height:) 是否真的需要固定值。
• GeometryReader 是否被当成全局布局容器滥用。
• UIScreen.main.bounds 是否参与页面布局。
• 横竖屏判断是否直接控制按钮位置。
• 图片、视频和自定义绘制区域是否假定固定比例。

固定尺寸并非绝对错误。问题在于，固定值是否会阻止内容根据父容器重新计算。按钮高度、触控区域可以有明确边界；主内容区域则应尽量采用内容驱动和容器驱动布局。

2．连续拖动，而不是只看两个端点

在 Xcode 27 的预览中，先观察窄尺寸，再逐步拖宽，最后恢复到原始尺寸。连续变化更容易暴露这些问题：

• HStack 中的文本把操作按钮挤出屏幕。
• ScrollView 的内容宽度没有跟随父容器变化。
• NavigationStack 的目的地视图仍保留旧的内边距。
• LazyVGrid 的列数变化后，选中状态与单元格位置不一致。
• 弹窗尺寸只在首次出现时计算，后续变化没有更新。

3．叠加 size class 和 Dynamic Type

只测试宽度，仍然不够。应至少覆盖 compact、regular 两种水平 size class，并把默认字号与大字号分别执行。size class 是环境特征，不是设备名称；同一设备也可能因为窗口空间变化而得到不同的布局条件。

本地化文本也要加入压力场景。中文、英文长词、德语复合词和带数字的金额文本，会触发不同的换行和压缩行为。对于支付、订单、表单类 App，长标题和错误提示往往比主界面更容易暴露问题。

UIKit：运行中缩放比启动时适配更关键

UIKit 存量 App 的主要风险，通常不是“启动后显示不出来”，而是“启动时正确，尺寸改变后没有重新布局”。

Apple 在 WWDC26 的 UIKit 适配说明中明确展示了 Device Hub 的 resize mode：App 运行后可以直接拖动模拟器边缘改变尺寸，不必为每个尺寸创建独立模拟器。官方同时提醒，在可调整环境中，interface orientation 不应被用于布局计算，相关判断应迁移到 size class。(developer.apple.com)

建议把检查拆成四层：

• 视图层：检查 Auto Layout 约束、safeAreaInsets、layoutMargins 和 preferredContentSize 是否随空间更新。
• 场景层：检查 UISceneDelegate、sceneDidEnterBackground、sceneWillEnterForeground 和场景重连逻辑。
• 特征层：检查 traitCollectionDidChange，确认 horizontal 和 vertical size class 变化能触发正确更新。
• 遗留假设层：搜索 UIDevice.current.orientation、UIScreen.main.bounds、userInterfaceIdiom 和旧的横竖屏分支。

userInterfaceIdiom 可以描述界面类别，但不能告诉布局当前还剩多少空间。一个仍被识别为 iPhone 的 App，在可调整环境中可能拥有更宽的窗口；如果代码只看到“这是 iPhone”，就可能继续使用窄屏导航和固定按钮位置。

对于场景尺寸限制，UIKit 提供了 UISceneSizeRestrictions，可读取或设置窗口的最小尺寸、最大尺寸以及是否允许全屏。它适合检查 App 是否错误地把尺寸限制得过窄，但不应拿来伪造某个尚未公布的折叠设备规格。(developer.apple.com)

状态连续性：尺寸变化不能重置用户任务

布局没有错，不代表 App 适配完成。折叠屏形态最可能放大的是任务连续性问题，所以当前应先用现有场景做替代压力测试。

重点覆盖以下状态：

• 正在编辑但尚未提交的草稿。
• 长列表中的滚动位置。
• 被选中的商品、图层或地图标记。
• 已打开的弹窗、菜单和分享面板。
• 深层导航中的页面栈。
• 正在执行的网络请求、上传任务和异步图片加载。
• 从前台切到后台，再回到前台后的页面状态。

测试时不要只拖动尺寸一次。可以采用“打开任务—改变尺寸—继续操作—后台—恢复—再次改变尺寸”的连续路径。若页面恢复后重复提交、重新拉取数据、弹窗消失或滚动位置跳回顶部，就应记录为状态缺陷，而不是单纯的视觉问题。

UIKit 的 UIScene 代表一个独立的用户界面实例，场景状态变化会通过代理和通知传递给应用。(developer.apple.com) SwiftUI 项目则应检查状态对象的生命周期，避免因为视图重建而意外清空任务数据。

验收证据不要只留一张截图。每个缺陷至少保留：

• 尺寸变化前后的 UI 录屏。
• 关键状态的日志，例如任务 ID、导航路径、选中项和请求状态。
• 可重复的操作步骤。
• Xcode、SDK、测试分支和构建号。
• 触发问题的最小窗口范围或 size class 条件。

全屏内容：游戏、视频和画布单独回归

游戏、播放器、相机预览、地图和绘图画布不能与普通表单页面混在一起验收。它们经常依赖方向、渲染尺寸、输入坐标或全屏假设。

游戏

检查尺寸变化过程中：

• Metal 或 SpriteKit 的 drawable size 是否及时更新。
• 触控坐标是否仍对应正确的游戏世界坐标。
• 虚拟摇杆和操作按钮是否被内容层遮挡。
• 帧率下降时，逻辑时间步进是否出现跳变。

视频和相机

检查播放器控制层是否随着可用空间移动，字幕是否被裁切，预览画面是否出现拉伸。相机 App 还要验证预览层、取景框和拍摄按钮是否使用同一个坐标空间。

地图和绘图

地图缩放、标记位置和绘图笔刷不能依赖启动时的屏幕边界。尺寸变化后，内容可能需要重新计算可视区域，但用户当前选中的对象和绘制路径不能因此丢失。

iOS 27 的官方测试方向支持可调整尺寸环境，但这不等于 Apple 已公布折叠屏的铰链位置、折痕区域或安全边距。(developer.apple.com) 因此，当前不要在代码里加入“折痕左侧”“外屏专用区域”之类的硬编码判断。那会把传闻写进产品逻辑，发布后反而增加回滚成本。

现在可执行的回归清单

下面这份清单适合直接放进测试任务或合并请求模板：

• [ ] 在 Xcode 27 的 SwiftUI Preview 中连续拖动尺寸，而不是只验证固定设备画布。
• [ ] 在 Device Hub 中进入 resize mode，记录窄、宽和连续变化时的页面表现。
• [ ] 检查固定 frame、UIScreen.main.bounds 和方向判断是否参与布局。
• [ ] 分别验证 compact、regular size class。
• [ ] 叠加 Dynamic Type、大字号、深色模式和长本地化文本。
• [ ] 在 UIKit 中检查 traitCollectionDidChange 和场景生命周期回调。
• [ ] 验证草稿、滚动位置、选中项、弹窗、导航栈和异步任务。
• [ ] 对播放器、游戏、地图、相机和画布执行渲染尺寸与输入坐标回归。
• [ ] 保存录屏、状态日志、复现步骤、Xcode 版本和测试分支。
• [ ] 将结果分为“通用自适应已通过”“等待官方确认”“必须真机复测”。
• [ ] 禁止把测试报告写成“iPhone Ultra 兼容认证”。

团队如果需要核对远程 Mac 的账号权限、环境准备和访问流程，可以先查看 ProxyMac 帮助中心。涉及多人协作时，应提前确认成员的访问权限、Xcode 与 SDK 版本、并发测试数量和交付周期，再决定采用本地设备、云端环境或混合方案。为了避免把测试资源问题混同为适配问题，建议先整理成员权限、构建任务和回归范围，再进行环境比较。

在执行多人回归时，也可以在测试计划中再次引用 ProxyMac 帮助中心，统一记录账号进入方式、环境交接和故障反馈路径。这样不会把某个尚未官宣的折叠设备能力误写成现有服务承诺。

官宣后的补测优先级

Apple 一旦发布官方模拟器设备、折叠状态事件或外屏规则，测试顺序应从“通用能力”切换到“设备专属行为”。

第一优先级是替换传闻假设。把此前的宽窄窗口测试保留，把未知设备尺寸、比例和状态事件替换为官方定义。

第二优先级是验证状态迁移。重点观察折叠、展开、外屏切换时，导航栈、草稿、播放器进度、异步任务和弹窗是否按照官方规则连续。

第三优先级是真机性能。模拟器可以发现布局和状态缺陷，但不能证明真实设备上的 GPU 渲染、相机、传感器、耗电、热量和动画流畅度。

第四优先级是发布流程。将 Xcode、SDK、测试分支、失败截图和复现路径保留在同一回归记录中，官宣后更新原文章和原测试报告，不要另建一篇相同搜索意图的内容。

FAQ：无真机测试的边界

没有折叠屏 iPhone 真机，开发团队现在能先测什么？

可以先测 App 对动态可用空间的响应，包括宽度变化、size class、Dynamic Type、本地化文本、导航层级、滚动位置和异步任务。不能提前确认真实折叠姿态、外屏规则、铰链区域或专属手势，这些必须等待 Apple 的正式文档、模拟器或真机。

不同窗口尺寸在 Xcode 27 中如何构造？

运行 App 后，在 Device Hub 或 Xcode Previews 中进入 resize mode，直接拖动边缘改变可用空间。测试重点不是复刻某个传闻尺寸，而是覆盖窄、宽、连续拖动和尺寸恢复等变化，并记录每次变化后的布局、状态和日志结果。

SwiftUI 宽屏预览应该怎样设计？

不要创建一个写死的“展开屏幕”画布。应在 Live Preview 中连续拖动预览尺寸，检查 HStack、Grid、NavigationSplitView、固定 frame 和内容驱动布局。再叠加大字号、深色模式、本地化长文本，确认宽屏增加后内容不会异常拉伸或挤压。

UIKit 存量项目怎样验证运行时尺寸变化？

用 Device Hub 的 resize mode 让已运行的 UIKit App 改变窗口大小，并观察 viewWillTransition、traitCollectionDidChange、UISceneDelegate 和约束更新是否正常。布局判断应依赖当前视图空间和 size class，不应继续把 UIDevice 方向或 userInterfaceIdiom 当作唯一条件。

哪些折叠屏专属行为需要等 Apple 定义？

折叠与展开事件、外屏和内屏之间的任务连续性、折痕或铰链安全区、外屏独立交互、专属拖放手势以及设备性能边界都不能靠传闻推断。团队可以先保留测试接口和日志字段，但不要把模拟结果写成 iPhone Ultra 兼容认证。

当前方案与 Mac 测试方案

只在本地固定 iPhone 模拟器上测试，主要缺点有三个：尺寸覆盖窄，运行中变化难以复现；团队成员各自维护环境，Xcode 和 SDK 容易不一致；需要并行回归时，本地 Mac 的设备窗口、日志和构建任务会互相争抢资源。

如果团队只是维护一个轻量 App、长期稳定重负载，或必须连接特定物理接口，自购 Mac 或本地真机仍然更合适。若目标是新品前扩大多尺寸回归覆盖，尤其需要临时增加 Xcode 27、Device Hub 和 UIKit 测试环境，租赁 ProxyMac 的 Mac 环境通常更灵活。开始前应先确认 Xcode、SDK、并发测试和交付条件。

最后更新于 2026 年 8 月 5 日，资料核实自 Apple Developer 官方 WWDC26 视频与文档，以及 MacRumors、9to5Mac 等媒体报道。 折叠屏 iPhone 的名称、形态、状态 API、发布时间和开售安排仍应以 Apple 后续公告为准。