iPhone Duo 已发布、上市前，iOS APP 加固应该提前验证哪些兼容路径？
普通 iPhone 上通过，不能直接证明 iPhone Duo 通过；模拟器能启动，也不能代替外屏、内屏、折叠姿态、Split View、Camera、Extension 和最终签名 IPA 的完整测试。正确做法是固定同一业务版本，在同一 Xcode、SDK 和运行时中依次比较 Original、Yudun Basic、Yudun Target 与 Final Signed Release，并把模拟器结果与实体设备结果分开记录。
iPhone Duo 为什么现在就应该进入发布计划
Apple 已在 2026 年 9 月 9 日公布 iPhone Duo，预购从 10 月 16 日开始，正式上市时间为 10 月 23 日，产品将提供外屏、内屏和 iOS 27.1 运行环境。Apple iPhone Duo 发布信息。这不是一个只影响硬件评测的新闻：Apple 已经提供专门的 iPhone Duo 开发者准备资料，并在 Xcode 27.1 beta 中加入对应 SDK 与模拟器支持。依赖登录、支付、WebView、相机、视频、地图、扩展或企业工作流的 App，现在就需要把多显示环境放进候选发布门禁。
本文是一个发布与兼容性方法页，不声称御盾已经通过实体 iPhone Duo、任何客户候选包或任何 TestFlight 业务流程。本轮没有执行物理设备动态测试；未执行单元保持 NOT_TESTED，不能外推为“全面兼容”。
读者对象
本文面向需要在 iOS 27.1 与 Xcode 27.1 测试折叠屏形态的 iOS 研发、QA、发布工程、安全和企业移动应用团队。重点不是证明某个客户包已经通过，而是建立一条从原始归因到最终签名的可复核路径。
核心结论
本轮主目标是建立 iPhone Duo 的显示形态、Scene、业务路径与加固候选之间的发布门禁；非目标是声称已完成实体 Duo、客户 IPA、TestFlight 或 App Store 的动态兼容。没有运行记录的单元保持 NOT_TESTED。
| 目标 | 要回答的问题 | 当前状态 |
|---|---|---|
| 显示形态基线 | 外屏、内屏和折叠姿态是否分别覆盖 | NOT_TESTED |
| 候选归因 | Original、Basic、Target 的首次差异出现在哪里 | NOT_TESTED |
| 业务路径 | 登录、WebView、Camera、Extension 和升级是否闭环 | NOT_TESTED |
| 发布链 | 最终签名 IPA 是否与验收候选一致 | NOT_TESTED |
| 模拟器边界 | Simulator 限制与产品回归能否分开 | NOT_TESTED |
测试目标与非目标
这里的测试目标是把“普通 iPhone 通过”拆成可执行的 Duo 兼容问题：确认外屏与内屏的布局输入是否稳定，确认开合和窗口变化是否触发正确的 Scene 更新，确认 WebView、Camera、Extension 与后台恢复是否有独立结果，并确认加固候选和最终签名没有改变已经通过的业务路径。非目标包括：不逆向 Apple 私有实现，不把模拟器限制改写为实体设备缺陷，不凭一条启动结果评价全部 SDK，也不在没有实体设备和客户包的情况下发布全面兼容承诺。
| 测试目标 | 验收问题 | 结果边界 |
|---|---|---|
| 外屏与内屏适配 | Size Class、Safe Area、Reserved Region 是否正确 | 只覆盖已测显示区域 |
| 姿态与窗口 | 开合、半折、旋转、Split View 是否可恢复 | 不外推未测姿态 |
| 业务链路 | 登录、WebView、Camera、Extension、推送是否闭环 | 单一页面通过不代表业务通过 |
| 候选归因 | Original、Basic、Target、Final 的首次差异在哪里 | 需要同环境对照 |
| 发布身份 | 最终签名 IPA 是否对应验收过的候选 | 不代替 App Store 审核 |
先分清“能运行”和“完成适配”
旧 App 可能无需重新编译就能在新设备上启动，但这只能说明入口没有立即失败，不代表它已经正确处理了不同显示区域、窗口数量、场景生命周期和折叠姿态。Apple 的 Duo 资料将重点放在自适应布局、窗口与场景、Camera 和多任务体验上。对企业 Release 来说，至少要区分四个结论：
| 结论 | 可以支持什么 | 不能推出什么 |
|---|---|---|
| 能安装 | 签名、包结构与安装链在当前环境可用 | 登录、支付、扩展和升级一定正常 |
| 能冷启动 | 入口和基础初始化完成 | 展开、收起、后台恢复一定正常 |
| 外屏通过 | Compact Width 路径在已测候选中可用 | 内屏、Split View 或多窗口一定正常 |
| 模拟器通过 | 某个 Simulator Runtime 下的行为通过 | 实体 Duo、所有 SDK 和最终发布链都通过 |
因此“iOS 27 兼容”与“iPhone Duo 兼容”不是同一个标签。前者是平台版本结论，后者必须绑定显示形态、姿态、窗口和候选包。
技术拆解
Duo 的兼容问题通常同时来自显示区域、窗口生命周期、系统组件和第三方依赖。把这些层拆开，是避免“加固包不兼容”成为默认结论的前提。
外屏、内屏与折叠姿态要分别记录
Duo 兼容性不应只用“横屏/竖屏”两个字段表达。外屏和内屏可能提供不同的宽度类别、可用区域和交互密度；展开、半折、闭合或从一个显示区域切换到另一个显示区域时，Scene、Window、Safe Area 与视图层级都可能重新计算。建议在测试记录中固定以下字段：
Xcode / SDK
Simulator Runtime 或 Physical Device
OS Version
Pose: closed / partial / open
Display: outer / inner
Size Class / Trait Collection
Scene Count / Window Mode
Safe Area / Reserved Region
Original / Yudun Basic / Yudun Target / Final Signed
在 UI 路径上，应分别检查导航栏和工具栏、弹窗、键盘、WebView、相机预览、滚动容器、深链回跳和系统权限提示。一个外屏通过、内屏未执行的候选，只能标记为部分覆盖。
为什么固定尺寸和固定方向假设会暴露问题
折叠设备会让“屏幕只有一个固定矩形”的旧假设变得脆弱。Apple 的 Duo 技术讲座建议开发者使用 Size Class、Trait Collection、Scene Bounds、Safe Area 与保留区域来描述当前窗口，而不是把 UIScreen.main、固定像素尺寸或方向判断当作唯一依据。对 UIKit 项目，检查约束、容器控制器和 Scene 更新；对 SwiftUI 项目，检查环境值、可用布局空间和窗口切换后的状态保留。
这也是加固归因需要谨慎的原因：如果 Original 在同一 SDK、同一 Pose 下已经错位，Yudun 候选不应被直接判定为根因；如果 Original 正常而某个保护级别首次出现稳定错位，才进入资源、符号、运行时注入或视图生命周期的定向排查。
Xcode 27.1 Simulator 的边界
开发者应先阅读 Xcode 27.1 beta Release Notes。Apple 已记录 Duo Simulator 的已知限制，包括初次启动耗时、部分系统体验尚未可用，以及部分 App Extension 在模拟器中可能无法正常运行或调试。模拟器的失败需要先判断是 Runtime limitation、原始 App 问题、第三方 SDK 问题，还是加固候选回归。
推荐把结果拆成三类：
SIMULATOR_TESTED：只代表当前模拟器 Runtime 与候选在已测路径上的结果；SIMULATOR_LIMITATION：有官方已知限制，不能外推到实体设备；PHYSICAL_DEVICE_NOT_TESTED：尚未有实体 Duo 证据。
只有在同一业务版本完成实体设备验证后，才可以对实际硬件路径单独下结论。不要把 Simulator 的 PASS 写成“已全面兼容”，也不要把 Extension 的模拟器限制写成“御盾导致崩溃”。
工程落地：APP 加固的单变量验证顺序
建议采用以下候选链，并在每一级保存签名与摘要信息：
A. Original Archive
↓
B. Original Final IPA
↓
C. Yudun Basic
↓
D. Yudun Target
↓
E. Final Signed Release
固定 Xcode 版本、iOS SDK、Bundle Version、业务后端、账号类型、测试数据和运行时。A 失败时，先检查 Apple Runtime、布局、SDK、Camera、WebView 或业务基线；A 通过而 C/D 首次失败时，才检查保护对 Mach-O、资源、动态调用、Scene 生命周期和 Native 依赖的影响；D 通过而 E 失败时，重点检查最终签名、安装、渠道和权限声明。
| 结果模式 | 优先解释 | 处理动作 |
|---|---|---|
| A 失败，后续都失败 | 平台、原始 App、SDK 或业务基线 | 先修复基线，不归因加固 |
| A 通过，C 失败 | 基础保护、资源、符号或启动差异 | 缩小保护变更并复现 |
| A/C 通过，D 失败 | 目标保护与 WebView、Camera、Scene 或 Native 交互 | 按模块和路径定位 |
| A-D 通过，E 失败 | 最终签名、安装或发布链 | 检查签名与分发记录 |
| 只有某个 Pose 失败 | 布局、窗口、Safe Area 或生命周期差异 | 交叉验证同一候选的其他 Pose |
NOT_TESTED、SIMULATOR_LIMITATION 和 NOT_COVERED 不能改写成 PASS。候选摘要、签名状态和回滚对象也不能缺失，否则后续无法区分代码变化、保护变化和发布变化。
哪些业务路径必须纳入 Duo Release Gate
对于金融、游戏、企业协作和工具类 App，建议至少覆盖：
- 首次安装、冷启动、热启动和从后台恢复；
- 登录、Token 刷新、退出、重新认证和深链回跳；
- 外屏到内屏、内屏到外屏、展开、闭合、半折和旋转；
- Split View、第二窗口、弹窗、键盘、Safe Area 与保留区域；
- WebView、Cookie、OAuth、JS Bridge、文件上传和支付回跳；
- Camera、麦克风、定位、照片选择器和系统权限提示；
- Push 到达、点击通知、前后台切换和场景重建；
- App Extension、分享、Widget 或企业配置路径；
- Native/Framework 加载、ABI、视频和图形路径；
- 覆盖升级、卸载重装、数据迁移、最终签名与回滚。
测试报告应把每条路径绑定到具体候选和显示姿态。仅验证首页或单次启动时，结论只能是“入口已检查”，不能写成“Duo 兼容”。
事实依据与脱敏证据
| # | 事实或来源 | 可确认内容 | 对验收的意义 | 当前状态 |
|---|---|---|---|---|
| 1 | Apple iPhone Duo 发布信息 | 产品于 2026-09-09 公布，预购 10-16、上市 10-23，出厂系统为 iOS 27.1 | 研发需要在上市前准备候选与矩阵 | 官方来源已核对 |
| 2 | Apple Duo 开发者中心 | Apple 提供 Duo 的适配与开发资料 | 兼容工作有官方 API 与界面指导 | 官方资料已核对 |
| 3 | Duo 技术讲座 | 重点涉及自适应布局、窗口与显示形态 | 不能继续依赖固定屏幕假设 | 官方资料已核对 |
| 4 | Xcode 27.1 beta Release Notes | Simulator 存在已知限制 | 模拟器结果必须与实体设备分开 | 官方资料已核对 |
| 5 | App Attest 权威页 | App Attest 是服务端证明，不能替代客户端保护 | 高价值请求仍需叠加候选与后端证据 | 既有公开页 |
| 6 | iOS Runtime 与注入边界 | 运行时、重签名和设备证据需要拆层 | Duo 兼容记录不能混成越狱判断 | 既有公开页 |
| 7 | XCFramework 供应链与签名身份 | SDK 来源身份与最终 App 签名身份应分开 | 发布链需要保存最终 IPA 身份 | 既有公开页 |
| 8 | 本轮执行边界 | 没有实体 Duo、客户 IPA 或真实 TestFlight 动态测试 | 只能发布方法与待测矩阵 | NOT_TESTED |
报告事实映射（公开来源）
下面只映射 Apple 公开资料与本轮内容中可核对的事实，不把规划中的模拟器或实体设备测试写成已完成结果。
| # | 公开事实 | 工程含义 | 当前状态 |
|---|---|---|---|
| 1 | Apple 已公布 iPhone Duo 及 10 月上市安排 | 上市前应冻结兼容矩阵和回滚对象 | 官方来源已核对 |
| 2 | 产品同时提供外屏与内屏 | 显示区域必须拆分记录 | 官方资料已核对 |
| 3 | 出厂系统为 iOS 27.1 | SDK 与运行时字段进入发布门禁 | 官方来源已核对 |
| 4 | Apple 提供 Duo 开发者准备资料 | 适配工作应以公开 API 指导为基线 | 官方资料已核对 |
| 5 | Xcode 27.1 beta 提供 Duo 模拟器支持 | 可先做模拟器对照，但不能代替实体机 | 官方资料已核对 |
| 6 | Apple 文档强调自适应布局和窗口行为 | 固定尺寸假设需要专项排查 | 官方资料已核对 |
| 7 | Simulator 存在部分已知限制 | Extension 等失败不能直接归因加固 | 官方说明已核对 |
| 8 | 本轮没有客户 IPA 和实体 Duo | 所有动态候选单元保持未测试 | NOT_TESTED |
动态时间线与字段时间线
| 阶段 | 记录字段 | 复核动作 | 当前状态 |
|---|---|---|---|
| 官方准备 | source_url, release_date, sdk_version |
核对 Apple 发布与开发资料 | 已核对公开来源 |
| 工程准备 | xcode, ios_sdk, bundle_version |
固定构建与签名输入 | NOT_TESTED |
| 模拟器基线 | runtime, pose, display, size_class |
Original 先跑完整路径 | NOT_TESTED |
| 基础保护 | basic_digest, protection_version |
只改变保护阶段并复跑 | NOT_TESTED |
| 目标保护 | target_digest, module_set |
检查布局、Scene、WebView、Camera、Native | NOT_TESTED |
| 最终签名 | signing_mode, ipa_digest, distribution |
检查安装、升级与回滚 | NOT_TESTED |
| 实体设备 | device, os, pose |
复核模拟器与真实硬件差异 | NOT_TESTED |
| 结果解释 | failure_class, rollback_ref |
绑定候选、姿态和业务路径 | NOT_TESTED |
攻防视角与责任边界
御盾负责 App 自身的代码与二进制保护、完整性、运行时边界和候选追踪；Apple 平台与系统负责显示、Scene、窗口、相机、系统组件和签名验证；客户后端负责账号、会话、权益与高价值业务动作。任何一层都不能替代另外两层。
App Attest 或其他服务端证明可以帮助后端判断请求是否来自预期 App 实例，但它不是布局测试，也不是加固兼容性的自动结论。反过来，Yudun Candidate 通过也不代表 Apple 的 Simulator、TestFlight、App Store 或实体 Duo 路径全部通过。最终报告应同时保留候选、显示姿态、运行环境、签名与业务路径。
风险边界
本文不把模拟器结果包装成实体设备结论，不把一条启动成功记录包装成完整业务通过，也不把 App Attest、签名或加固候选中的单个信号解释为整台设备或整条发布链的绝对可信。真正的结论必须绑定 Xcode、SDK、运行时、姿态、显示区域、候选摘要、签名和业务路径。
公开来源与当前验证状态
本轮只核对 Apple 公开发布信息、开发者资料和既有公开技术页；没有采集客户账号、真实设备标识、签名私钥、完整模拟器日志或生产凭证。对外展示时只保留脱敏字段与状态。
| 证据对象 | 当前状态 | 说明 |
|---|---|---|
| iPhone Duo 发布信息 | 已由 Apple 公开资料核对 | 仅确认公开产品与时间信息 |
| iOS 27.1 可用性 | 已由 Apple 公开资料核对 | 不等于客户 App 已通过 |
| Duo 开发者指导 | 已发布 | 用作适配基线 |
| Xcode 27.1 Simulator | 已有官方说明 | 受模拟器限制约束 |
| 实体 iPhone Duo | NOT_TESTED |
本轮未执行 |
| 客户 IPA / TestFlight | NOT_TESTED |
本轮未执行 |
| Yudun Basic / Target | NOT_TESTED |
本轮未执行 |
上述状态卡只表达公开资料和本轮范围；它不包含客户账号、设备标识、签名材料或内部日志。
常见误区
误区一：普通 iPhone 上能启动就算 Duo 兼容。 只能证明一个基础入口，不能覆盖内屏、姿态、多窗口和相机。
误区二：Simulator 失败一定是加固问题。 先检查 Xcode 27.1 beta 的已知限制，并在 Original 上复现。
误区三：iOS 27.1 只有一个兼容结果。 结果必须绑定 SDK、Runtime、Pose、Display、候选和签名。
误区四：加固前后直接比较不同业务版本。 变量没有冻结，就无法做保护归因。
误区五：把 NOT_TESTED 写成“支持”。 未执行的矩阵单元只能保留未测试，并安排下一步验证。
工程落地：如何建立一份可复核的 Duo 记录
一份可复核记录至少要能从结果回到输入。首先冻结业务版本、Bundle Version、Xcode、iOS SDK、签名方式和候选摘要；其次为每一个 Pose 与 Display 记录运行时、Size Class、Scene 数量、Window 模式、Safe Area 和 Reserved Region；最后把每条业务路径的结果与候选阶段绑定。这样当一个页面在内屏错位时，团队可以判断是布局约束、第三方 SDK、系统限制还是保护候选改变了调用时序。
建议把记录拆为四层：
- 构建层：Xcode、SDK、编译配置、Bundle Version、架构和签名方式；
- 环境层：Simulator Runtime 或实体设备、iOS 版本、姿态、显示区域和系统组件；
- 业务层：登录、支付、WebView、Camera、Extension、推送和覆盖升级；
- 证据层：Original、Basic、Target、Final 的摘要、首次失败点、复核动作、回滚对象和最终边界。
当只有模拟器而没有实体设备时，报告应明确写“模拟器范围内已执行，实体设备未测试”。当 Extension 在模拟器受限时，可以记录 Apple 的已知限制，并安排 TestFlight 或实体设备复核；不能用一条 SIMULATOR_LIMITATION 结论替代客户发布结论。
当前首轮矩阵
| 场景 | Original | Yudun Basic | Yudun Target | Final Signed |
|---|---|---|---|---|
| 外屏冷启动 | NOT_TESTED | NOT_TESTED | NOT_TESTED | NOT_TESTED |
| 内屏冷启动 | NOT_TESTED | NOT_TESTED | NOT_TESTED | NOT_TESTED |
| Open to Close | NOT_TESTED | NOT_TESTED | NOT_TESTED | NOT_TESTED |
| Partial Fold | NOT_TESTED | NOT_TESTED | NOT_TESTED | NOT_TESTED |
| Split View | NOT_TESTED | NOT_TESTED | NOT_TESTED | NOT_TESTED |
| WebView / Camera | NOT_TESTED | NOT_TESTED | NOT_TESTED | NOT_TESTED |
| Extension | SIMULATOR_LIMITATION | SIMULATOR_LIMITATION | SIMULATOR_LIMITATION | NOT_TESTED |
| 覆盖升级与回滚 | NOT_TESTED | NOT_TESTED | NOT_TESTED | NOT_TESTED |
这张表不是宣传兼容性的替代物，而是下一轮执行的入口。只要某个单元从 NOT_TESTED 变成结果，就必须同时记录环境、候选和业务路径；如果环境改变，旧结果不能自动复制到新设备。
FAQ
旧 App 不重新编译，能不能先发 Duo？
可以先验证是否能安装和启动，但不能把这个结果当作完成适配。应至少补齐外屏、内屏、开合、旋转、Split View、WebView、Camera 和前后台路径，并确认最终签名包与回滚链。
App 加固后内屏错位，是否一定是保护策略？
不一定。先在同一 Xcode、SDK、Runtime、Pose 和业务版本上验证 Original；只有原包通过而某个保护级别首次稳定失败，才进入加固、资源、Scene 或 Native 归因。
模拟器能否替代实体 iPhone Duo？
不能。模拟器适合早期布局、生命周期和候选对照，但 Apple 已列出部分 Extension 等已知限制；实体硬件、系统版本和最终分发链仍需独立验证。
御盾是否已经全面兼容 iPhone Duo？
本文不作该承诺。本轮没有实体设备和客户候选的动态结果，矩阵中的未执行项保持 NOT_TESTED。可用脱敏 Demo 申请 Original、Basic、Target、Final 的分阶段 PoC。
发布前的最小复核清单
在进入 TestFlight 或正式发布前，建议把每个候选的构建输入和运行结果放在同一张记录中。构建输入包括 Xcode、SDK、Bundle Version、架构和签名方式；运行结果包括外屏、内屏、姿态、Split View、WebView、Camera、Extension、后台恢复和覆盖升级。若某一项只在模拟器中执行，就在结果后标明 Runtime；若某一项等待上市后的实体设备，就保持 PHYSICAL_DEVICE_NOT_TESTED。
当报告需要交给客户、QA 或后端团队时，优先提供“场景、候选、观察、复核、边界”五列，而不是堆积无法还原的日志。观察到内屏布局变化后，应先在 Original 上重复同一姿态，再切换 Basic 和 Target；观察到 Camera 或 Extension 异常时，应同时核对 Apple 的模拟器限制、第三方 SDK 版本、签名和权限。这样的记录既能缩短工单定位，也能避免把平台行为误写成保护产品缺陷。
结论
iPhone Duo 给 iOS 发布带来的核心变化不是多了一块屏幕，而是让显示区域、Scene、窗口、姿态、Camera、Extension 和最终签名成为同一条兼容链。御盾应把普通 iPhone 的“能启动”升级为可复核的 Duo Release Gate：固定 Xcode 与 SDK，先跑 Original，再逐级比较 Basic、Target 和 Final Signed，并把 Simulator 与 Physical Device 结论分开。
在实体设备上市前，最可靠的公开表达不是“已经全面兼容”，而是明确哪些官方事实已核对、哪些模拟器路径已执行、哪些实体路径仍为 NOT_TESTED，以及下一步如何用同一业务版本完成复核。对于需要上线金融、游戏或企业 App 的团队，可提交脱敏的 Bundle、候选摘要与业务路径，申请 iOS 折叠屏兼容性 PoC。
**适用边界：**本文用于发布规划、兼容性归因和候选验收方法。没有执行的设备、姿态、扩展、Camera、WebView、签名或业务路径，不构成通过结论。