How to Handle On-Demand Resources Upload Limits in 2027? 2026

An upload containing On-Demand Resources can still build successfully while becoming ineligible under a later upload rule.

Fastest path: new apps and apps with no ODR usage history should remove ODR from upload contents before the restriction begins in early 2027; existing ODR apps are not being ordered to stop immediately, but should start migration planning. Background Assets is a migration target, not a one-click conversion. Verify it with Xcode’s local mock server and the project’s actual distribution workflow.

This runbook is for iOS and game developers checking whether their app falls within the upload rule.
It is also for engineers responsible for resource delivery, download behavior, and migration scope.
Apple-platform CI and release engineers can use it to plan validation before changing a production pipeline.

Last updated November 12, 2026. We checked the scope and timing against Apple’s App Store Connect ODR upload guidance and reviewed the migration workflow against Apple’s Background Assets documentation.

Separate the upload rule from platform deprecation

Apple’s notice sets the upload restriction to begin in early 2027. It covers uploads containing ODR from new apps and apps that have not previously used ODR. Apple has not announced a specific effective date, so release plans should use “early 2027” as the published window—not a guessed day. Recheck the release notes before committing a cutoff to a deployment schedule. Apple’s upload guidance is the source to monitor.

There are three related, but distinct, issues:

• Upload eligibility: whether an app’s submission includes ODR and falls within the newly described restriction.
• Platform direction: Apple says ODR is deprecated beginning with iOS 27, iPadOS 27, tvOS 27, and visionOS 27, and recommends Background Assets for migration. See Apple’s ODR upload and platform guidance.
• Existing app behavior: Apple says apps already using ODR can continue to run in the near term. That is not the same as a guarantee that every future upload, OS release, or project configuration will remain unaffected.

Do not turn “deprecated” into “the app stops working now.” Do not turn “still runs” into “the upload rule cannot affect us.” The first mistake can trigger a needless emergency migration; the second can leave a release blocked when the team has no tested fallback.

Determine whether this project is in scope

Start with the project’s upload history and the actual archive. A project setting alone is not enough: old targets, generated resource bundles, and release branches can leave ODR content in a build even after the main development branch appears to have moved on.

Use this checklist before choosing a migration path:

• [ ] Check whether ODR is enabled in the project. Review target settings and build configuration for ODR-related setup. Include release and maintenance branches, not just the default branch.
• [ ] Inspect the archive and upload contents. Confirm whether the produced app or related upload includes ODR content. A successful local build only establishes that the build completed; it does not establish eligibility under a later upload rule.
• [ ] Check actual historical use. Review released app versions and the team’s release records. Determine whether the app has previously used ODR, rather than inferring its history from the current project file.
• [ ] Trace resource requests. Search for NSBundleResourceRequest and the tags passed to it. Apple documents the existing API in its NSBundleResourceRequest reference.
• [ ] Record who owns each resource. Identify the feature, level, screen, or content-unlock flow that depends on each tag. Note what the app does when retrieval is delayed or fails.
• [ ] Keep evidence with the release record. Save the archive inspection result and the historical-use decision so release engineers can repeat the scope check for a later branch.

The decision is based on both facts: whether the app has used ODR before and whether the upload contains ODR content. If either fact is uncertain, treat the project as unresolved. Verify the archive and release history before declaring that the restriction does or does not apply.

Choose a path using project history and release needs

The table is a routing aid. It does not replace checking Apple’s latest upload guidance or validating the project’s archive.

For new work, we recommend evaluating Background Assets before adding more ODR-dependent code. For an established app, prioritize inventory and architecture mapping rather than attempting a rushed rewrite. Apple’s recommendation is a migration direction; the correct pack boundaries and availability rules still depend on how the app uses its resources.

Map ODR behavior to a new resource-delivery design

An ODR tag is not automatically equivalent to a Background Assets pack. A tag may represent a game level, optional content, or resources that several screens use. A new asset pack should be organized around when the content must be available and how the app will confirm that it is ready.

Document these behaviors before changing code:

1. When does the app need the files? Separate resources required at launch from content that can arrive later. A resource needed to render a first screen has a different availability requirement from an optional level.
2. What event starts retrieval? Identify whether the existing request is triggered by navigation, a user action, a feature flag, or another application event.
3. What proves local availability? Define the app-side check that prevents code from trying to read a file before it is ready. Do not equate a request being scheduled with the resource being present.
4. What happens on delay or failure? Specify a retry, fallback, progress state, or user-facing error that fits the feature. System-managed retrieval does not mean every download succeeds at the exact moment the app wants it.
5. Who hosts and maintains each pack? Decide whether the project will use Managed Background Assets with Apple-hosted packs or an unmanaged, self-hosted setup. These options have different configuration and operational responsibilities.

For Managed Background Assets, follow Apple’s managed asset-pack creation guide. If packs are Apple-hosted, configure retrieval using Apple’s Apple-hosted asset-pack download documentation. If the team will host packs itself, use the unmanaged Background Assets project guidance and make hosting, versioning, and availability part of the release plan.

This is an architecture migration, not a file-format conversion. A practical mapping document can connect each existing tag to its new pack, triggering event, availability check, failure behavior, and owner. Review it with both application developers and release engineers. That catches hidden dependencies such as a UI transition that assumes a resource request has completed or a content-unlock state that is stored separately from the downloaded files.

Validate build, hosting, and distribution as separate stages

A resource package can be correct while the app-to-pack relationship or release workflow is wrong. Test these layers independently, then test them together.

1. Build the app and packs from the intended project configuration. Use the same target and build settings planned for release. Record which app build is associated with the packs.
2. Run Apple’s local mock-server procedure. Apple documents local asset-pack testing with the mock server supplied with Xcode. Follow its Background Assets local testing steps. Check that the app requests the expected content and does not read files before they are locally available.
3. Exercise delayed and unsuccessful retrieval. Confirm the app’s loading, retry, fallback, and error handling. A happy-path local run does not establish what the UI does when a resource is unavailable.
4. Verify hosting responsibilities. For Apple-hosted packs, follow Apple’s App Store Connect upload process. For self-hosted packs, verify the team’s own publication and availability process.
5. Test the project’s distribution route. For Apple-hosted packs, include the intended beta distribution path and follow Apple’s TestFlight asset-pack testing guide. For other project workflows, repeat the checks in the route that will actually deliver the app and its resources.
6. Record the release acceptance result. Keep the app build, pack configuration, test outcome, and distribution result together. If local testing passes but distribution testing fails, investigate the handoff between build, hosting, and release rather than changing resource code blindly.

A local mock-server test answers a limited question: does the app behave correctly against the local test setup? It does not prove that an App Store submission will pass review, that a hosted pack is configured correctly, or that every distribution step is sound. Keep those outcomes separate in CI and release reporting.

Use a migration decision that can be revisited

The upload rule has a published timing window, but no exact effective day. Keep the decision record easy to update when Apple publishes a date or revises the applicable upload conditions. We recommend documenting:

• the app’s ODR-use history and the evidence supporting it;
• whether the current archive contains ODR;
• which targets and release branches still reference ODR;
• the proposed Background Assets pack boundaries and hosting model;
• local mock-server results and distribution acceptance results;
• unresolved failure handling or ownership questions.

For a new app that has not used ODR, do not add an ODR upload path on the assumption that it will remain acceptable until a particular date. For a live app with verified ODR use, avoid treating the announcement as an immediate shutdown notice. Instead, put migration discovery and validation on the engineering plan while preserving a clear release path for the current implementation.

Migration FAQ

When should a team stop uploading ODR?

Apple has announced an early-2027 start for the restriction on uploads containing ODR from new apps and apps that have not used ODR before. It has not specified a day. Keep the release plan tied to Apple’s published wording, check the App Store Connect guidance before the relevant submission, and avoid coding a guessed date into internal policy.

Does an app already using ODR need an emergency rewrite?

No immediate rewrite follows from the announcement alone. Apple says existing ODR apps can continue to run in the near term. The engineering risk is different: a project may have hidden tag dependencies, fragile failure handling, or no migration test path. Inventory those now, then schedule a migration according to release risk and product needs.

Can a team replace each NSBundleResourceRequest with one Background Assets call?

No. The APIs and delivery models are not a direct mapping. Revisit the resource grouping, retrieval trigger, local-availability check, and failure behavior. One old tag might need to become part of a differently structured pack, while some resources may not need remote delivery at all. Preserve the feature behavior, not merely the old request shape.

What does a passing local Background Assets test establish?

It shows that the app can exercise the tested pack behavior in the Xcode-provided local mock-server setup. It does not establish that Apple-hosted upload, beta distribution, App Store review, or a self-hosted production endpoint is configured correctly. Validate those release stages separately using the path intended for the project.

If the migration requires a reliable macOS environment to run Xcode, build packs, and repeat project-specific checks, first compare that need with the team’s existing machines and CI capacity. A local Mac may be the better choice for continuous, heavy workloads or physical-device access; a Linux cloud host cannot replace a macOS toolchain for Xcode-based work. When the bottleneck is an underpowered workstation, a shared machine, or a temporary validation cycle, those options can mean limited concurrency, environment drift, and hardware tied up between releases. A remote Mac can provide a separate environment for those runs without buying another machine; review the available Mac environment and rental plans, then decide based on how often the project needs it.

Frequently asked questions