Device Hub 检查 iPhone Duo 时，VoiceOver 或 Accessibility Inspector 读不到屏幕内容。
最快处理：这是 Xcode 27.2 已记录的 Device Hub 读取限制，不应直接等同于应用缺陷；先拆分布局、辅助功能语义与真实交互验收，再为未覆盖项补证据。（Apple 的 Xcode 27.2 发布说明）
适合负责 iPhone Duo 布局与无障碍验收的企业 QA 负责人。
也适合需要划分 Mac CI 检查边界的平台工程师，以及必须建立可追溯放行依据的发布负责人。
先标记“未验证”，不要先填“通过”或“应用失败”。 Apple 的发布说明将该情况记为 Device Hub 的已知问题，并给出问题编号 187148389；这说明的是工具读取能力边界，不是应用质量结论。
Xcode 27.2 iPhone Duo 无障碍测试的边界
Xcode 27.2 发布说明明确指出，在 Device Hub 中，VoiceOver、Accessibility Inspector 等无障碍工具无法传达 iPhone Duo 的屏幕内容。该条目没有说所有 iPhone Duo 测试都不可用，也没有说应用必然存在缺陷。先按受影响的检查类型分类，再决定是否需要替代验证。
这条边界很重要：画面能显示，不代表读屏语义已验证；工具读不到，也不代表应用语义一定有错。 Device Hub 可用于观察界面、操作设备或模拟器；只是不能把受影响的无障碍工具读取结果当成完整验收。关于 Device Hub 如何呈现模拟设备与实体设备，可参考Apple 的设备管理说明。
版本环境也要留档。发布说明写明 Xcode 27.2 要求运行于 macOS Tahoe 26.6 或更新版本；因此复现记录至少应包含 Xcode 版本和 macOS 版本，避免把不同工具环境下的现象混为一谈。
视觉布局检查与语义检查分开
如果截图看起来异常，先判断问题是否随显示屏或布局状态出现，而不是直接把结果归入辅助功能失败。对外屏、内屏及团队实际验收的展开、折叠或方向状态分别留图，记录触发步骤、屏幕状态和预期表现。
Apple 面向 iPhone Duo 的设计资料建议使用尺寸类别、布局边距和安全区域适配变化，并提醒设备上的保留区域会影响可用空间；其资料也指出，不能只依赖设备方向推断应用窗口形状。发现控件被遮挡、内容裁切或焦点目标视觉位置不合理时，应作为布局问题单独复现和跟踪。（iPhone Duo 设计指南）
接着核查应用侧的辅助功能语义：交互控件是否有可理解的标签，元素角色是否正确，必要提示是否存在，以及焦点顺序是否符合关键任务的操作逻辑。Apple 的 VoiceOver 开发资料说明，标签用于描述被选中的元素，提示则补充操作上下文；这些属性检查能说明应用代码暴露了什么，但不等于 Device Hub 已成功读取该设备的屏幕内容。（Apple 的 VoiceOver 应用支持说明）
模拟器与真实设备各自能证明什么
模拟器适合快速观察布局、执行自动化用例，并在可用条件下检查应用提供的辅助功能属性；它不能证明真实设备上的所有辅助功能交互都已覆盖。Apple 的运行说明提示，模拟器不会复现所有真实设备的性能与功能，涉及硬件特性的验证应在真实设备上进行。（在模拟器或设备上构建并运行应用）
Accessibility Inspector 的审计可发现标签缺失、对比度、触控区域或文字裁切等常见问题，也能导出审计报告；但 Apple 同样提醒，清除审计问题不等于应用完全无障碍，仍应使用 VoiceOver 等辅助技术测试。审计通过只是证据的一部分，不是完整的真实交互结论。（为应用执行辅助功能审计）
建议按以下步骤补测并留档：
- 固定构建版本、测试账号和关键任务路径，避免不同构建的结果混在同一份记录中。
- 在模拟器中运行现有布局与 UI 自动化用例，分别保存截图、断言结果和失败日志。
- 按应用实现核查标签、角色、提示与焦点顺序；记录核查方法，注明是否由工具读取或代码检查得出。
- 对团队支持设备及关键任务，安排可行的真实设备辅助功能交互；保存设备环境、操作步骤和观察结果。
- 将无法执行的 Device Hub 读屏项标成“未验证”或“需替代验收”，为每项指定补测负责人和证据位置。
- 由 QA、无障碍负责人和发布负责人核对未覆盖项及替代证据，再按团队既定放行标准作决定。
如果当前团队只能使用模拟器，就应明确记录它能支持的布局观察、自动化断言或属性核查，并把真实设备交互留作未覆盖项；不要把模拟器结果改写成完整的 VoiceOver 验收。Apple 的辅助功能测试指南也建议结合不同辅助技术进行测试，并将自动化审计作为补充路径。（Apple 的应用辅助功能测试指南）
Mac CI 的失败分类与证据记录
CI 报告不要只保留一个“无障碍测试失败”状态。至少区分应用断言失败、视觉布局异常、应用侧语义问题，以及 Device Hub 无法传达屏幕内容导致的未验证项；前几类可按应用问题流程处理，最后一类则应安排替代验收，而不是误判为通过或缺陷。
可以在流水线开始时采集环境信息。下面的命令用于记录版本与可用模拟器清单；输出只作为记录模板，不代表本站或你的团队实测结果。
xcodebuild -version
sw_vers
xcrun simctl list devices available
报告中保留命令输出、构建标识、目标设备或模拟器、检查类型、复现步骤、截图或日志路径，以及最终判定。涉及 Device Hub 无障碍读取受限的用例，应单独列出“未验证原因”和替代证据位置，避免 CI 汇总把它折叠进一般失败统计。
对于仅在 Accessibility Inspector 审计中发现的问题，可保存审计报告并关联对应构建；但报告必须说明它验证了哪些页面、哪些审计项，以及是否完成真实 VoiceOver 操作。自动审计结果不能保证完整无障碍体验。
补验收与发布放行的决策条件
下面的分支用于把工具限制转换成团队可执行的决定，不是 Apple 强制规定的发布政策：
- 若失败仅是 Device Hub 无法传达屏幕内容，且没有独立证据显示应用异常：标记“未验证／需替代验收”，补充真实设备或团队认可的其他路径；不要仅凭这项结果判应用缺陷。
- 若布局问题能通过截图或界面复现：按对应显示状态提交布局缺陷，并复测修复前后的画面与关键控件位置。
- 若标签、角色、提示或焦点顺序问题能独立复现：提交应用侧无障碍缺陷，关联复现步骤和属性核查结果。
- 若关键任务已有团队要求的布局、语义和辅助功能行为证据：由 QA、无障碍负责人及发布负责人核对未覆盖风险，再按内部标准决定放行。
- 若关键任务仍缺证据，或无法明确责任人与风险接受方：回退为暂缓放行或限制发布范围，直到补验收完成。
| 验收项目 | 可用证据 | 不能据此单独证明 |
|---|---|---|
| 视觉布局 | 各显示状态截图、复现步骤、布局断言 | VoiceOver 朗读顺序正确 |
| 辅助功能语义 | 标签、角色、提示、焦点顺序的属性核查 | Device Hub 成功读取了 iPhone Duo 屏幕 |
| 自动化审计 | 审计结果、UI 测试日志 | 所有真实辅助功能交互均无问题 |
| 真实设备交互 | 关键任务的操作记录与观察结果 | 未测试的页面或路径也已覆盖 |
| CI 判定 | 报告状态建议 | 后续动作 |
|---|---|---|
| Device Hub 读屏受限，其他路径未补测 | 未验证／需替代验收 | 指定负责人并补证据 |
| 应用侧语义问题可独立复现 | 应用缺陷 | 修复后复测并关联记录 |
| 关键验收项有证据且风险已确认 | 按内部标准评估放行 | 留存审批与未覆盖项 |
FAQ：受限时怎么判断与补验
Device Hub 的无障碍工具为什么读不到 iPhone Duo 屏幕？
Xcode 27.2 发布说明将其列为已知限制，范围是 Device Hub 中的 VoiceOver、Accessibility Inspector 等工具无法传达 iPhone Duo 屏幕内容。它并未说明所有测试路径都不可用，也不能用来证明应用有缺陷。应保留版本和检查类型，再逐项安排其他验证。
VoiceOver 与 Accessibility Inspector 暂时无法用于该检查时，怎么补验？
先以截图和操作记录验证布局，再核查应用侧标签、角色、提示和焦点顺序；随后为支持设备和关键任务安排可行的真实设备交互。模拟器及自动化审计可以补足部分证据，但报告需标明各自覆盖范围，不能把布局观察写成真实读屏已通过。
Device Hub 无法读屏时，怎样区分工具限制和应用缺陷？
把屏幕传达能力与应用暴露的语义属性分开验证。若只有 Device Hub 读取失败，先标为工具限制或未验证；若缺少标签、角色不当或焦点顺序错误能由独立核查路径复现，再按应用缺陷处理。保存复现状态和对应证据，避免用单一失败结果替代原因分析。
这类检查结果可以单独作为 CI 放行依据吗？
不能。受影响的检查若没有补充证据，应保留为未验证或需替代验收；只有团队预先定义的关键项目有可追溯结果，并由相关负责人确认剩余风险，才依据内部发布规则评估放行。自动审计也不能保证应用完全无障碍。
最后核对：2026 年 11 月 14 日；事实依据为 Xcode 27.2 发布说明及 Apple 的 iPhone Duo 开发资料。若后续 Xcode 更新或相关文档改变，应重新核对工具限制；团队自己的补测结果则应标注测试环境与执行日期。
对企业团队而言，当前 Mac CI 自行搭建或沿用现有环境，可能需要承担工具链版本维护、设备配对和补验收证据分散等成本；但如果工作负载长期稳定且重负载，或必须连接专用物理接口，自购 Mac 也可能更合适。若需求是阶段性验证 Xcode 流程、扩展团队测试环境，可先通过 NodeMini 的 Mac 云算力方案评估远程 Mac 是否适配，再按团队实际测试目标确认环境；NodeMini 的服务入口可用于了解远程 Mac 的承载方式。租赁可以减少一次性购置及闲置设备管理负担，但不能替代真实设备无障碍交互验收，也不应被当作未经验证的 CI 放行依据。