iPhone Duo 适配现在做什么？2026 远程测试准备清单

iPhone Duo 适配测试不能只看 App 能不能启动。我们建议把任务拆成下面三层，分别交给开发、测试和发布负责人。

现在就做：代码与素材风险盘点

• 检查是否依赖固定屏幕宽度、固定设备型号或固定方向值。
• 检查是否直接读取主屏幕尺寸，再用这个尺寸计算卡片、工具栏和弹窗位置。
• 记录所有忽略 safe area、写死 frame、强制单列导航的页面。
• 为内屏、外屏、横向、纵向和分屏状态建立测试用例名称。
• 预留内外屏截图模板，但不要提前替换 App Store Connect 中的正式素材。

Xcode 27.1 beta 开放后做：模拟器与布局验证

• 安装受支持的 Xcode 版本和 iPhone Duo 模拟器运行时。
• 在 Device Hub 中确认模拟设备、运行时和项目 Scheme 是否可见。
• 验证打开、闭合、窗口缩放、旋转和并排显示。
• 保存每个姿态下的截图、控制台日志和复现步骤。
• 将模拟器结果与普通 iPhone 回归结果放在同一份记录中。

实体设备到手后做：硬件相关验收

• 回归相机、视频、游戏、横屏工具和外接硬件流程。
• 检查输入位置、旋转动画、显示区域变化和状态恢复。
• 验证性能、相机能力、系统权限和真实触控行为。
• 用最终构建产物重复关键任务，而不是只运行 Debug 版本。

Apple 的设计指南强调，iPhone Duo 具有两个显示屏、中央铰链和多种持握姿态；使用系统组件并正确支持尺寸调整的 App，更容易适应这些状态，但“能够自适应”仍不等于已经完成业务验收。Apple 的 iPhone Duo 设计指南 已将动态布局、姿态和多显示区域列为设计重点。

SwiftUI：从固定尺寸改成容器驱动

SwiftUI 开发者应优先搜索这些高风险写法：

• 用固定数字决定内容宽度，而不是读取容器可用空间。
• 用设备型号判断是否显示某个按钮。
• 只根据 UIDeviceOrientation 改变布局。
• 假设左右安全区域始终对称。
• 把 NavigationStack、NavigationSplitView 或 TabView 固定成单一层级。
• 让 Sheet 和 Popover 默认出现在屏幕中央，却没有验证缩放后的可用区域。

更稳妥的判断依据是 size class、容器尺寸和布局环境。对于核心页面，我们建议至少记录以下结果：

✅ 内容是否随容器变宽，而不是被拉伸或裁切。
✅ 工具栏是否在外屏和内屏都保留主要操作。
✅ Sheet、Popover 是否会遮住提交、购买或确认按钮。
✅ NavigationSplitView 在窄窗口和宽窗口之间切换时，状态是否丢失。
✅ 页面从纵向切换到横向时，输入内容是否仍然保留。

不要只截一张全屏页面作为证据。登录、搜索、编辑、支付、上传和错误恢复页面，应分别覆盖至少一个窄容器和一个宽容器。这样才能发现“首页看起来正常、关键流程已经不可用”的问题。

UIKit：定位 frame、safe area 和转场假设

UIKit 或自定义界面维护者，风险通常更集中。先在代码库中搜索 UIScreen.main.bounds、固定 CGRect、固定导航栏高度、强制横屏和直接修改 safeAreaInsets 的逻辑。

这些实现容易在双屏形态中出问题，原因并不只是屏幕变大：

• 显示区域可能发生动态变化，原来的 frame 不会自动重新计算。
• 内外屏的安全区域可能不对称，左右边距不能默认相等。
• 自定义工具栏可能覆盖系统提供的操作区域。
• 转场动画若只处理一次布局，窗口缩放时可能留下错误位置。
• 直接按设备型号分支，容易让普通 iPhone 回归出现新的路径。

接下来检查 traitCollection、Auto Layout、UISplitViewController 和自定义转场。每项修复都要绑定一个普通 iPhone 回归用例，禁止为了 iPhone Duo 单独复制一套业务页面。

经验：发现一个硬编码尺寸后，不要只改成“更大的固定尺寸”。先确认这个尺寸究竟描述的是内容宽度、可视区域、点击区域还是系统安全区域，再决定是否交给 Auto Layout 或容器环境计算。

普通表单页面与媒体页面不能共用一份验收标准。相机、视频、游戏和横屏工具会同时受到显示区域、方向、输入位置和硬件能力影响。

多场景 App 至少要验证：

• 新窗口创建后，路由和登录状态是否正确恢复。
• 窗口缩放或并排显示时，列表与详情是否仍可操作。
• 场景进入后台再恢复时，编辑内容是否丢失。
• 两个场景同时存在时，通知、深链接和共享状态是否串线。
• 关闭一个场景后，另一个场景是否承担了错误的状态。

相机和视频页面则要单独记录预览区域、拍摄按钮、焦点位置、旋转方向和权限弹窗。游戏或横屏工具还要检查触控映射、手势区域和暂停恢复。

截至当前时间，不能根据产品宣传或媒体猜测去推断铰链状态、多显示区域或相机能力的 API 行为。涉及新接口时，只引用 Apple 已公开的设计指南、开发者视频和正式文档；没有公开说明的行为，标记为“待工具或实体设备验证”。

如果现有 Mac 是正式打包机，不建议直接把 beta 工具链覆盖到生产环境。Xcode 系统要求会随版本变化，Apple 当前的系统要求页显示，不同 Xcode 版本对应不同的 macOS、SDK、部署目标和模拟器支持范围；Xcode 27.1 的最终要求应以开放后的官方页面为准。

远程 Mac 的准备重点不是“能不能打开 Xcode”，而是测试结果能不能被团队复用。

先按下面步骤执行：

第 1 步：建立独立环境

为 iPhone Duo 适配准备独立主机、独立系统卷或至少独立的 Xcode 目录。正式发布使用稳定工具链，iPhone Duo 适配使用隔离目录或独立系统环境。

第 2 步：确认 Apple silicon 与系统基线

在 Xcode 27.1 beta 开放后，先核对 Apple silicon 架构、macOS 版本、磁盘空间和模拟器运行时要求。没有官方支持结论前，不要把现有 Intel 环境视为可用测试节点。

第 3 步：验证图形会话

通过远程桌面打开 Xcode 和 Device Hub，检查模拟器画面是否能持续显示。Device Hub 的官方说明显示，它用于管理模拟和实体设备，并提供设备画面、运行状态、诊断文件等操作。查看 Device Hub 官方文档

第 4 步：固定项目同步方式

项目同步应使用可追踪的提交版本。不要在远程 Mac 上直接修改未提交文件，也不要把包含账号、Bundle ID、设备标识、项目路径和截图内容的日志原样发到群组。

第 5 步：保存交付产物

每次测试至少保存构建版本、模拟器姿态、页面截图、关键任务结果和日志。截图与日志文件名使用脱敏后的项目编号，避免暴露团队账号、证书路径或真实用户数据。

第 6 步：模拟断线恢复

主动中断远程连接，再重新进入图形会话。确认任务是否仍在运行、日志是否完整、截图是否已落盘，以及团队能否从最后一个记录点继续定位。没有这一步，远程 Mac 只能算临时桌面，不能算可交付的测试环境。

Apple 的 Device Hub 介绍也区分了模拟设备和实体设备：模拟器适合快速评估界面，实体设备更适合硬件依赖和性能问题。远程 Mac 可以承担前一类工作，但不能替代最终实体设备回归。Apple 关于 Device Hub 的 WWDC26 介绍 对这一使用边界有更完整说明。

旧版构建能运行，不代表完成适配

现有 App 是否能在 iPhone Duo 上启动，取决于系统兼容性、当前构建和最终设备支持。即使旧版构建能够启动，也不能证明它正确处理了双屏、动态尺寸、场景恢复和新导航布局。

因此，旧版构建可以作为第一轮兼容性观察对象，但不能作为发布验收对象。完整判断要等支持 iPhone Duo 的 SDK、模拟器和实体设备条件齐备后完成。

Xcode 27.1 的开放时间不要写死进排期

截至 2026 年 9 月 12 日，Apple 的 iPhone Duo 专页将 Xcode 27.1 beta、对应模拟器和部分文档标为本月稍晚开放，没有提供可替代官方公告的固定使用日期。查看 Apple 的 iPhone Duo 工具状态

项目排期可以设置“工具开放后 1 个工作日内完成环境验证”，但不应写成某个未经确认的具体日期。这样即使开放时间变化，也不会让测试计划失效。

内外屏截图应按正式规格分别管理

当前 App Store Connect 截图规格页列出了 iPhone Duo 的不同尺寸：

• 外屏：1398 × 2034 或 2034 × 1398 像素。
• 内屏：2007 × 2853 或 2853 × 2007 像素。

这些数字来自 Apple 当前截图规格页，不是本站实测。查看 iPhone Duo 截图尺寸要求

素材管理上，建议把内屏、外屏、横向、纵向和本地化版本拆成独立命名。上传入口正式开放前，不要替换当前正式版本资产；可以先完成设计模板、截图脚本和素材验收规则。

App Store Connect 支持上传每个设备尺寸的截图集，API 也要求按照截图集和显示目标管理资源。查看 App Screenshots API 文档 这意味着后续自动化时，不能只生成一批图片后无条件覆盖所有设备目标。

下面这组判断用于决定当前环境，不用于替代 Xcode 27.1 开放后的正式验收。

• 若现有 Mac 能安装受支持的 Xcode 27.1、保留稳定打包链路，并有足够空间保存多个模拟器运行时：
  先在本地建立双轨环境。正式发布使用稳定工具链，iPhone Duo 适配使用隔离目录或独立系统环境。

• 若现有 Mac 只有一套生产环境，升级后会影响当前发版，或无法长期保留模拟器运行时：
  不要直接升级生产打包机。准备一台隔离的远程 Mac，用于阶段性适配、姿态测试和截图验证。

• 若团队只需要完成一次短期布局检查，且没有持续运行测试任务：
  选择短期远程 Mac 环境，测试结束后导出截图、日志和问题清单。不要为一次性任务维护长期常驻节点。

• 若团队需要每天运行回归、保留模拟器状态并让多人轮流访问：
  再评估常驻远程 Mac。重点核对图形会话稳定性、磁盘保留、账号权限、日志交付和断线恢复，而不是只比较 CPU 参数。

如果需要临时准备独立环境，可以先查看 MESHLAUNCH 的 Mac 远程租赁方案。对于只需要一台 Apple silicon Mac 做阶段性验证的团队，先按测试周期选择环境，再决定是否长期保留，比直接改造正式打包机更稳妥。

适配任务只有在下面五层都留下记录后，才能关闭：

✅ 代码构建： 项目能在目标 Xcode 与 SDK 下完成 Build、Archive。
✅ 模拟器姿态： 内屏、外屏、横竖方向、窗口缩放和分屏状态都有结果。
✅ 关键任务： 登录、导航、编辑、支付、上传、相机或媒体流程均完成。
✅ 截图素材： 内外屏尺寸、方向、文案、本地化和排序均已核验。
✅ 实体设备： 最终构建在真实设备上完成关键流程和硬件相关回归。

发布负责人还要确认素材上传入口是否已经开放。Apple 的上传说明显示，截图只能在特定版本状态下上传或修改，提交后若要更新截图，通常需要创建新版本。查看 App Store Connect 截图上传流程

当前方案如果只有一台本地 Mac，常见缺点是生产打包与 beta 适配互相抢环境、模拟器运行时难以长期保留，远程团队也缺少统一的日志和截图交付位置。直接购买另一台 Mac 又会把一次性的热点适配变成长期硬件投入，还要自行处理系统升级、磁盘和远程访问。

因此，更合理的路径通常是：正式环境继续保持稳定版本，iPhone Duo 适配单独使用隔离的远程 Mac。若当前只是临时算力、模拟器和截图验证需求，可以先通过 MESHLAUNCH 的 Mac mini M4 租赁页面评估周期；等实体设备和发布入口都完成验证后，再决定是否转为长期常驻测试方案。