iPhone Duo 怎么接入企业 iOS CI？2026 验收指南

CI 显示通过，但展开后的页面布局和应用扩展还没有验证。
最快处理：先把 iPhone Duo Simulator 纳入 Xcode 27.1 CI 的代表性构建与布局检查；模拟器通过不等于真实设备完整验收，须先核对已知限制，再按发布风险补做设备或人工验证。

企业 IT 与 CI 平台负责人：评估现有 Mac 构建环境、Xcode 和模拟器是否适合这条流水线。
应用团队负责人：把折叠、展开和窗口尺寸变化变成可重复检查的用例。
QA 与发布负责人：定义模拟器能证明什么、还缺什么，以及谁负责补测和签核。

最后更新于 2026 年 10 月 25 日；工具链要求与设备指导复核自官方系统要求、iPhone Duo 准备指南及 Xcode 27.1 发布说明。需要注意，公开发布说明页面标注为 27.1 RC，其中列出的已知问题不能未经核对就认定仍适用于最终安装版本。(developer.apple.com)

先明确验收对象：CI 要证明什么

“支持 iPhone Duo”不是可直接签核的测试条件。流水线应对应明确目标：检查工程能否构建、核心页面是否适应代表性尺寸，还是判断发布包是否满足团队的准入政策。把目标写成具体断言，才能避免把界面设计偏好误当作所有项目都必须遵守的 CI 规则。

对企业流水线，可把证据分成几层：

• 构建与启动：目标方案能否编译，应用能否在指定模拟器运行。
• 布局回归：展开、折叠及窗口尺寸改变后，关键控件是否仍可见、可操作，内容是否发生意外裁切。
• 交互检查：导航、表单、弹窗等核心流程是否在目标状态下可用。
• 发布验收：模拟器结果之外，是否还需要真实设备检查、人工复核或风险审批。

层次之间不能互相替代。构建成功证明不了布局正确；布局快照也不能证明所有硬件相关行为正常。项目应在测试报告中保留目标、测试状态和未覆盖范围，而不是只留一个绿色状态。

平台负责人：锁定工具链与运行条件

Xcode 27.1 的官方系统要求列出 macOS Tahoe 26.6 或更高版本。平台负责人应据此核对构建 Mac 的系统版本，并确认指定 Xcode 安装了所需的 iOS 模拟器运行时；不要只根据开发者电脑“能打开项目”就推定 CI 节点条件一致。(developer.apple.com)

流水线应记录实际使用的 Xcode 版本、构建节点系统版本、目标运行时，以及所选模拟器 destination。不同构建节点如果使用不同工具链，失败原因可能来自环境差异，而不一定是代码回归。将这些信息随测试结果保存，后续才能复现。

Xcode 27.1 的 iPhone Duo Simulator 能否放进自动化 CI？
可以将其用于代表性构建和自动化检查，但要先在目标节点实际确认模拟器运行时可用、测试方案可启动。不要把在开发机 Device Hub 中手动看到模拟器，等同于 CI 节点已完成可重复的无界面测试验证。命令行测试结果可通过 xcodebuild test 生成 .xcresults 测试结果包；目标 destination 应从节点当前可用设备中确认，而非凭设备名称猜测。(developer.apple.com)

目前公开的 Xcode 27.1 RC 说明列出几项模拟器限制：首次启动可能需要数分钟、StandBy 不可用，以及多数应用扩展无法在该模拟器运行或调试。由于页面标注的是 RC，这些条目适合作为试跑时的核查清单，不应不经验证地写成最终版的永久限制。涉及应用扩展或待机体验的测试，先用目标安装版本复核；若模拟器不能提供所需证据，就把补测条件和责任人写进发布记录。(developer.apple.com)

注意： Device Hub 支持在模拟器与实体设备之间切换测试，但界面操作方式相似，不意味着两种环境能覆盖相同的硬件行为。凡是依赖实际设备能力的场景，应单独标识为待补证，而不是通过模拟器截图代替。(developer.apple.com)

应用团队：把姿态和尺寸变化变成用例

准备指南指出，应用在 iPhone Duo 上会随设备展开或折叠而调整尺寸；只在启动时读取一次屏幕尺寸，可能无法应对会话中的尺寸变化。团队应检查是否存在硬编码屏幕尺寸、固定方向假设，或只依赖启动时几何信息的布局逻辑。尺寸应跟随视图、窗口或当前场景获取，并在环境变化时重新计算。(developer.apple.com)

用例不必为每一种外观状态设计一套完全独立的界面，而应覆盖产品真实支持的体验。至少确认外屏和内屏下的关键流程，再验证折叠与展开过程中内容是否随可用空间变化。若应用采用系统标准导航组件，也要确认栏位和内容在不同尺寸下的排列仍符合产品需求。官方设计指导强调根据空间与尺寸类别调整布局，而不是仅凭设备方向猜测界面尺寸。(developer.apple.com)

可以按以下方式形成可重复用例：

• 启动状态：冷启动后检查首页、登录态、关键入口是否正常显示。
• 展开状态：核对主要内容区、导航和操作按钮是否可见，检查内容是否被边缘或中间区域遮挡。
• 折叠状态：确认回到外屏后，当前任务、表单输入或导航状态是否符合产品预期。
• 尺寸变化过程：在不退出应用的情况下改变尺寸，确认布局重新计算，避免只在重启后才恢复。
• 关键交互：对最影响业务的操作增加自动化断言；截图比对可以发现视觉变化，但不能单独证明按钮可点击或流程正确。

Device Hub 能承担哪些检查？
它适合用于运行模拟器、观察界面及执行交互检查，也能调整模拟设备环境与尺寸；具体操作和能力以目标版本文档为准。对每个用例，QA 应保存测试条件、断言结果和必要截图。截图用来解释结果，不应替代可执行断言或真实设备验证。(developer.apple.com)

QA 与发布负责人：保留证据，设定准入分支

测试报告要让未参与执行的人也能判断：测了什么、在哪个环境测、结果如何、还有哪些风险没有覆盖。CI 可归档构建日志和 .xcresults，并补充用例标识、目标模拟器、Xcode 版本、运行时和未覆盖事项。Xcode 命令行测试会输出包含结果与日志等信息的结果包，可用作团队审查和复现材料。(developer.apple.com)

发布准入条件应由项目风险决定。例如，核心页面布局回归失败可设为阻断；模拟器不支持的应用扩展则进入设备补测或例外审批；未完成的高风险验证不能仅凭 CI 通过自动放行。例外记录应注明影响范围、批准人、补测期限或回退措施。发生回归时，发布负责人还需明确回退到哪个已验证构建，以及如何撤销当前准入。

模拟器测试通过后，还需要哪些发布验收？
先比对测试覆盖矩阵与发布风险：对必须依赖真实硬件的功能安排设备验证；对模拟器不支持的能力标记补测责任；对只涉及布局的低风险变更，也应留存目标状态和测试结果。模拟器通过只覆盖已执行的用例，不能自动证明尚未检查的设备行为。

IT 与采购：先试跑，再判断是否更换构建环境

远程 Mac 是否适合承载 iPhone Duo 测试，不能只看“支持远程访问”或笼统的性能描述。需要在拟用环境中验证所选 Xcode、运行时、模拟器启动、命令行测试和结果包导出。还应检查团队采用的访问方式、权限与凭据管理是否符合内部政策。

可先用团队现有流水线执行一条小范围试跑：确认节点能发现目标运行时、执行测试并保留结果，再评估运行稳定性、并发需求、环境复现和访问控制。没有实际试跑记录时，不应将远程 Mac 直接判定为可用或不可用。若需核对服务交付与访问方式，可查看 远程 Mac 环境说明；涉及项目资料处理规则时，再检查 数据与隐私说明。

决策条件：

• 若现有 Mac 已满足目标 Xcode 与系统要求，且模拟器任务可稳定复现，则先在现有流水线上接入代表性用例。
• 若当前节点无法提供目标运行时，先评估升级或隔离测试节点；未完成兼容验证前，不把模拟器测试列为强制发布门槛。
• 若模拟器不支持某项项目必测能力，则保留自动化覆盖已支持部分，并为缺口安排真实设备或人工验证。
• 若现有环境容量、复现或访问方式构成瓶颈，且远程环境能通过同一套试跑，再比较远程 Mac 与现有方案；试跑失败或不符合内部安全要求，就回退到已验证的构建环境。

验收与环境方案对照

下面的评分是用于团队决策的定性判断，不是性能测试结论。应以项目实际运行结果调整，尤其不能把模拟器的布局证据等同于设备行为证据。

团队可以用以下准入评分卡避免“支持新设备”成为没有证据的口号：

结语：用验证结果决定是否扩展 Mac 容量

对 iPhone Duo 企业 iOS CI 测试，合理做法是先让模拟器承担代表性的构建与布局检查，再以覆盖矩阵明确设备补测和发布签核范围。模拟器可能无法覆盖真实硬件行为；自管环境则需要团队维护版本、容量和一致性。若团队的主要问题是临时构建容量或难以复现的测试环境，可先按同一验收清单试跑远程 Mac，并对照 OrbVPS 远程 Mac 方案核对交付与访问方式；如果环境无法通过项目验证，继续使用现有 Mac 或实体设备更稳妥。