截至 2026 年 11 月 12 日，Apple 公布的限制时间是“2027 年初”，但尚未给出具体生效日。结论先行：新应用及此前从未使用过 ODR 的应用，应避免上传含 On-Demand Resources 的内容；已经使用 ODR 的存量应用并非因此立即停用，但应开始盘点并规划迁移。新项目优先评估 Background Assets，迁移完成后用 Xcode 本地模拟服务和项目实际发布流程验收，不能把这次迁移当成一键转换。(Apple 的 App Store Connect ODR 说明)
最后更新于 2026 年 11 月 12 日；限制范围核实自 Apple 的 App Store Connect 说明，技术流程按 Apple 开发文档复核。
这篇适合需要核对 ODR 上传资格的 iOS 应用或游戏开发者。
也适合负责资源下载架构、维护 NSBundleResourceRequest 调用，或管理 Xcode 构建与发布验收的工程师。
On-Demand Resources 迁移 Background Assets：先判断上传边界
“弃用”“上传限制”和“已上线应用停止运行”是三件事。Apple 说明，ODR 自 iOS 27、iPadOS 27、tvOS 27 与 visionOS 27 起弃用，并建议迁移到 Background Assets；上传限制则针对新应用及此前未使用过 ODR 的应用，且仅涉及含 ODR 内容的上传。Apple 同时表示，已经使用 ODR 的应用近期仍可继续运行。不要把这几项合并成“所有旧应用都会在某天失效”。
| 项目状态 | 上传边界与判断 | 当前处理方向 |
|---|---|---|
| 新应用，归档中含 ODR | 属于已公布的限制范围；生效时间为“2027 年初”，没有具体日期。 | 上传前移除 ODR 内容，或优先设计 Background Assets 方案。 |
| 既有应用，历史版本从未使用 ODR，归档中含 ODR | 仍属于限制所指的项目类型。当前能构建，不代表后续上传符合要求。 | 确认资源是否必须在线下载，再调整资源交付架构。 |
| 既有应用，历史上已使用 ODR | 不属于上述“新应用或从未使用过 ODR”的描述；Apple 表示近期仍可运行。 | 盘点调用和资源生命周期，按版本计划迁移。 |
| 归档与历史版本都不含 ODR | 这次 ODR 上传限制不构成直接阻断。 | 留存构建检查结果；引入相关资源能力前重新核对规则。 |
以上边界来自 Apple 的公开说明，不是对某个应用审核结果的保证。Apple 将 ODR 标为弃用并推荐迁移，因此存量项目可以利用迁移窗口，但不应把“近期仍可运行”理解成长期兼容承诺。
项目适用性核验
不要只看 Xcode 项目设置里的开关。上传判定要同时检查当前工程、归档产物和历史发布记录。只检查代码可能漏掉仍被打进包里的资源；只检查当前归档，也无法证明应用过去是否实际使用过 ODR。
按下面顺序做一次发布前核验：
- [ ] 确认项目配置。 检查 target 的资源标签设置，以及构建配置中与 ODR 相关的能力是否仍启用。记录发现的位置。
- [ ] 搜索调用点。 全仓检索
NSBundleResourceRequest、beginAccessingResources、conditionallyBeginAccessingResources和endAccessingResources。找到调用点后，继续追踪它如何判断资源可用。Apple 已将NSBundleResourceRequest标为弃用并推荐 Background Assets。(NSBundleResourceRequest 官方文档) - [ ] 检查实际归档。 对准备上传的 archive 做资源清单检查，确认是否仍包含 ODR 相关资源包。不要用“编译成功”代替归档检查。
- [ ] 核对历史发布。 对照 App Store Connect 历史构建和团队发布记录，确认应用此前是否实际使用过 ODR。代码里留有未执行的旧实现，不足以证明线上版本已使用该功能。
- [ ] 保存判定依据。 记录应用状态、归档检查结果、历史版本证据和负责人。若无法证明历史使用情况，先标记为“资格待确认”，不要假定已获得豁免。
这能避免团队在提交时才发现归档仍含 ODR，继而临时改资源方案、重跑测试并调整发布排期。多 target、多个平台或游戏关卡包项目，还要覆盖所有参与上传的构建产物。
旧标签与下载策略的迁移范围
Background Assets 不是把旧标签换个名字。旧代码可能把标签、关卡解锁、界面状态和资源请求绑在一起；若只替换下载 API，容易漏掉资源必须何时可用、下载失败后用户能做什么，以及资源完成下载后如何读取。
先按用户场景拆分旧 ODR 标签，而不是照搬原有命名：
- 安装后立即需要的内容： 例如首次启动流程依赖的基础素材。评估是否属于
essential，并处理资源未就绪时的应用状态。 - 适合后台预取的内容： 例如用户很可能随后访问的资源。评估
prefetch是否符合使用节奏，并保留未完成时的等待或重试路径。 - 进入场景后才需要的内容： 例如关卡、角色模型或可选语言包。评估
onDemand；请求触发时显示加载状态，在资源尚未本地可用时阻止依赖它的逻辑继续执行。
Apple 的 Managed Background Assets 通过 asset pack 和 manifest 描述资源与下载策略，提供 essential、prefetch 和 on-demand 等策略。一个旧标签可能要拆成多个 asset pack，多个标签也可能合并。分组应由资源何时可用、哪些资源一起使用、失败时能否降级来决定，而不是机械复制标签名称。Apple 文档列出的 Apple-hosted 资源包压缩资源容量上限为 200 GB；这是服务上限，不代表每个项目都需要或能用满该容量。(Managed asset packs 创建说明)
下载策略还决定了托管责任。Apple-hosted 方案需要按流程单独上传并在 App Store Connect 维护资源包；self-hosted 方案则要求团队负责资源清单和托管交付。系统管理下载不等于网络请求必定成功，应用仍要提供失败状态和恢复路径。(Apple-hosted 下载配置；self-hosted 项目配置)
构建、托管与验收步骤
Xcode 本地测试可以验证应用与资源包的交互，但不能替代上传处理、TestFlight 分发或 App Review。我们建议把应用构建、资源托管和运行时可用性分开验收，避免把其中一项成功当成整体发布通过。
- 冻结现有行为基线。 记录关键资源的下载触发条件、读取路径、缓存清理规则和失败反馈。覆盖首次安装、更新后启动、用户进入资源场景等路径。
- 建立资源映射表。 为每个旧 ODR 标签记录关联文件、调用位置、依赖场景、可接受等待方式和失败降级，再分配到目标 asset pack。这是迁移依据，不是自动转换结果。
- 明确托管模型和维护责任。 使用 Apple-hosted 时，按 Apple 的流程上传资源包、检查处理状态，并核对资源包与应用构建的发布关系；self-hosted 时，则要验证自己的资源服务器、发布版本和客户端清单更新。
- 在 Xcode 本地测试资源交付。 配置 mock server 和资源包目录，逐项检查下载请求、状态反馈、文件读取及异常路径。Apple 提供了随 Xcode 使用的本地 asset pack 测试流程。(Background Assets 本地测试文档)
- 核验上传和测试分发。 对 Apple-hosted 资源，确认资源包已上传并处理，再检查 TestFlight 测试所用的应用构建与资源包版本是否匹配。(Apple-hosted 资源包上传流程；TestFlight 资产包测试流程)
- 走项目实际发布路径。 使用计划采用的上传工具、流水线和测试分发环节完整跑一遍，留存构建号、manifest 版本、资源包版本、处理状态和测试结果。mock server 通过只说明本地模拟链路正常，不代表 App Store Connect 已处理成功或 App Review 已通过。
- 设置回滚与监控。 为资源缺失、下载失败、网络中断和版本错配定义可观察的错误状态及恢复路径。上线后用项目现有的日志、崩溃监控或用户反馈检查资源可用性。
如果团队缺少可用的 macOS 与 Xcode 构建节点，先判断本地机器是否能覆盖归档、模拟服务和分发验收；临时验证也可了解 metalvnc 的远程 Mac 环境 与远程连接和使用说明。是否需要独立环境，取决于权限要求、测试周期和持续使用频率。远程节点不会代替审核判断，也不能替代真实项目验收。
常见问题
On-Demand Resources 的上传限制从什么时候开始？
Apple 公布的时间是 2027 年初，没有列出具体日期。限制针对新应用，以及此前从未使用过 ODR 的应用上传含 ODR 内容的构建。发布排期应继续核对 App Store Connect 更新，不要自行认定某一天就是截止日。(Apple 的 App Store Connect ODR 说明)
已经上线并使用 ODR 的应用需要马上迁移吗？
不需要把上传规则误读为已上线应用立即失效。Apple 表示，已使用 ODR 的应用近期仍可继续运行；这不是永久兼容保证。建议先盘点资源包、标签和请求调用，再结合版本节奏安排迁移与回归测试。
Background Assets 能直接替换 NSBundleResourceRequest 吗？
不能按旧标签做一对一替换。NSBundleResourceRequest 围绕标签和资源请求生命周期工作；Background Assets 以 asset pack、manifest 和下载策略组织资源。迁移需要重新设计资源分组、触发时机、失败处理和读取路径，再逐个场景验证。
怎么在 Xcode 里测试 Background Assets 资源包？
先生成并打包资源，再使用随 Xcode 提供的本地 mock server 验证下载和读取。除了成功路径，还要测试资源缺失、请求失败和状态反馈；之后再走项目实际上传与 TestFlight 或发布流程。本地测试通过不等于 App Store 审核通过。
如果当前方案仍依赖旧 ODR 标签和已弃用的请求 API，资源边界容易不清晰，失败处理难以统一，发布资格也需要额外确认；迁移到 Background Assets 则需要投入重构和验收时间。我们建议按项目实际测试方式与持续使用需求决定是否配置独立 Mac 环境：若只需阶段性运行 Xcode、打包资源和验证发布流程，可评估 metalvnc 的远程 Mac 方案与计费信息；若需要长期稳定的重负载运行或特定物理接口，应先比较自购设备及其他适合项目的基础设施。
常见问题
On-Demand Resources 的上传限制从什么时候开始？
Apple 当前公布的时间是 2027 年初，没有给出具体生效日。限制针对新应用，以及此前从未使用过 On-Demand Resources 的应用上传含 ODR 内容的构建。发布排期应以 App Store Connect 后续更新为准，不要自行假定某一天是截止日。
已经上线并使用 ODR 的应用需要马上迁移吗？
不需要把这次上传规则理解成已上线应用立即失效。Apple 表示，已经使用 ODR 的应用近期仍可继续运行；但这不等于长期继续使用没有风险。建议先记录现有资源包、标签和调用路径，再按产品迭代节奏安排迁移与回归测试。
Background Assets 能直接替换 NSBundleResourceRequest 吗？
不能按 API 名称或旧标签做一对一替换。NSBundleResourceRequest 围绕标签、请求生命周期和资源访问工作；Background Assets 则按 asset pack、manifest 下载策略及资源可用性组织。迁移时要重写资源分组、请求触发、失败处理和界面状态，逐场景验证。
怎么在 Xcode 里测试 Background Assets 资源包？
先按 manifest 生成并打包资源，再在 Xcode 的运行方案中配置本地 asset pack 目录，让随 Xcode 提供的 mock server 为调试会话提供资源。检查首次下载、按需请求、失败反馈及资源读取；之后仍需走项目实际的上传和 TestFlight 或发布流程，本地通过不代表审核通过。