I just saw the following in the Xcode 27 release notes: Xcode can now serve asset packs to your app while debugging on devices by setting a Background Asset Packs folder in the Run scheme action’s Options tab. (165230494) And sure enough, the option is there. But what do I need to point this to? I tried everything: the path to the built .aar asset pack the path to the .json manifest file the path to the download-manifest.json (for self-hosted asset packs) the path to the directory that actually contains the assets (as also referenced by the manifest file) the path to the directory that contains the manifest file and the asset directory. Nothing works. I always get the same errors on the console: Checking for updates failed: DecodingError.dataCorrupted: Data was corrupted. Debug description: The given data was not valid JSON.. Underlying error: Error Domain=NSCocoaErrorDomain Code=3840 "Unexpected end of file" UserInfo={NSDebugDescription=Unexpected end of file} The asset pack with the ID “MyID” couldn’t be looked up: DecodingError.dataCorrupted: Data was corrupted. Debug description: The given data was not valid JSON.. Underlying error: Error Domain=NSCocoaErrorDomain Code=3840 "Unexpected end of file" UserInfo={NSDebugDescription=Unexpected end of file} The manifest couldn’t be refreshed: DecodingError.dataCorrupted: Data was corrupted. Debug description: The given data was not valid JSON.. Underlying error: Error Domain=NSCocoaErrorDomain Code=3840 "Unexpected end of file" UserInfo={NSDebugDescription=Unexpected end of file} I'm testing on a physical iPhone. Any advice would be appreciated!

I'm developing an iOS app that uses Apple-hosted Managed Background Assets to deliver regional offline mapping datasets. According to Apple's documentation, the limits are 200 GB of hosted data and 200 asset packs per app. However, I couldn't find a documented maximum size for an individual managed asset pack. Our use case requires automatic, on-demand downloads of geographic datasets, typically between 50 MB and 500 MB, depending on the region. I have a few questions: Is there a maximum compressed or uncompressed size for an individual Apple-hosted Managed Background Assets pack? Are on-demand downloads of 100–500 MB packs supported over Wi-Fi and cellular networks? Are there any additional restrictions on large packs, such as download frequency, storage requirements or background delivery policies? Can these packs be downloaded automatically when a user enters a new geographic region, without requiring the user to select or manually download the pack? I'm specifically asking about Managed Background Assets, not the legacy On-Demand Resources system. Any clarification from an Apple engineer would be greatly appreciated. Thank you!

Hello, With Xcode 27.1 RC 1, the Background Assets override inside of developer settings is now a blank page. I see there's a new setting for background assets under Scheme < Options. Will the URL replacement return? Thanks

Hello, I’m using Apple-hosted Background Assets to deliver resources for my app. Our design is to download asset packs on demand at app launch. Scenario: An asset pack has already been downloaded to the device. We then upload a new version of the asset pack with the same identifier to App Store Connect. Question: Is there a way to detect that an updated version of the asset pack is available, without actually starting the download? Our goal is to show the user the download size and ask for confirmation before the download begins. What I’ve tried: checkForUpdatesWithCompletionHandler: This immediately starts downloading the updated asset pack in the background, so we can’t show the size to the user beforehand. getAssetPackWithIdentifier:completionHandler: When an asset pack with the same identifier already exists locally, this returns the local asset pack instead of information about the updated version on the server. Background: I’m concerned about App Review Guideline 4.2.3 (ii): If your app needs to download additional resources in order to function on initial launch, disclose the size of the download and prompt users before doing so. https://developer.apple.com/app-store/review/guidelines/#minimum-functionality If there’s no way to obtain the size of an update before it downloads, I’m worried our implementation might conflict with this guideline. Is there a recommended API or approach for this? Or, if updates to already-downloaded asset packs are handled automatically by the system, does this guideline still apply to them? Any guidance would be greatly appreciated. Thank you.

Hello, We are developing a macOS app using Apple-Hosted Managed Background Assets (MBA). Our resources are strictly coupled to specific app binary versions (e.g., App v1.0 is incompatible with Asset Pack v2.0 due to data schema and data format changes). We plan to use Essential asset packs, but also plan to provide an in-app fallback using ensureLocalAvailability during initial launch to handle cases where background downloads fail or are delayed. We have questions regarding the version-resolution behavior and Apple's recommended architecture for version-coupled assets. Scenario A user installs App v1.0 (which targets Asset v1.0). The initial Essential download fails (e.g., network disconnect). The user opens the app without local assets. Later, Asset v2.0 is released to the App Store alongside App v2.0. The user on App v1.0 launches the app and calls ensureLocalAvailability. Questions [1] Version Resolution & Fallback Behavior When an app has no local asset pack installed and calls: try await AssetPackManager.shared.ensureLocalAvailability( of: appResources01, requireLatestVersion: false // or the legacy ensureLocalAvailability(of:) ) Does the system always fetch the latest live version in the App Store (v2.0), or is there any mechanism to retrieve the historical version compatible with App v1.0? Is it possible for an app to explicitly request a specific Asset Pack version rather than the currently active App Store version? [2] Scope of shouldDownload(_:) Does ManagedDownloaderExtension.shouldDownload(_:) get invoked during an explicit in-app call to ensureLocalAvailability? Or is shouldDownload(_:) exclusively called for system-initiated background download cycles? [3] Recommended Architecture for Version-Coupled Resources If an application cannot maintain backward compatibility within a single continuously versioned Asset Pack (v1 → v2 → v3), what is Apple's recommended design pattern? Option A (Separate Identifiers): Define distinct Asset Pack identifiers for each incompatible app generation (e.g., AppResources-v1, AppResources-v2)? Option B (Forced App Update): Use a single Asset Pack identifier and require older app versions to prompt a forced app update via the Mac App Store if assets are missing and incompatible? Option C: Is there another recommended mechanism within Background Assets for managing strict asset-binary version coupling? Thank you for your guidance!

I have an app that I am implementing background assets, using self hosted unmanaged. Everything compiles fine, and I get no errors. But I can't figure out how to trigger the 'install' phase into the extension. I have tried copying the app into /Applications without luck. I have deleted the entire DerivedData and all copies of the application. Nothing seems to work. I tried using the Apple provided sample app from here and got the same results. I don't understand why the CLI tool backgroundassets-debug only works with iOS based connected devices? Please let me know how can I test my BADownloaderExtension on Mac via XCode. Thank you.

We ship a ~6.2 GB Apple-hosted managed asset pack and request it with AssetPackManager.ensureLocalAvailability(of:). If the app goes to the background even once while the download runs, the transfer continues to the end and then fails with ManagedBackgroundAssetsProcessingPipeline.Dispatcher.PipelineNotFound. The system discards the resume data, and the next attempt starts again from byte 0. What the sysdiagnose shows: On backgrounding, backgroundassets.user logs allows BG activity, pausing any foreground downloads for background demotion and hands the download to nsurlsessiond. On return it logs re-promoted 1 previously-demoted foreground downloads. Each handoff moves the stream to another STExtractionService.privileged instance, which logs No processing pipeline with the ID "…" was found; defaulting to an extraction memory footprint of 50 MB. When the HTTP response ends: [Relay] No endpoint was found for the key "…" (fault) → The stream couldn't be finished: No processing pipeline with the ID "…" was found → Removing the resumption info → the download fails. This happened on every app-requested download that was backgrounded at least once. One run reached 100 % in the foreground and still failed. The only download that ever completed was the system's own prefetch download, which ran entirely in the background with the app never launched. Over one afternoon about 46 GB were downloaded for a single 6.2 GB pack. Questions: Is this a known issue with the demotion/promotion of foreground asset-pack downloads? Is AssetPack.download(for: nil) plus BADownloadManager.scheduleDownload(_:) a supported way to request a managed pack from the app, so the download never gets foreground priority? We're testing it now. Is there any other way to keep a download requested from a foreground app from being demoted? Filed as FB24888599.

We shipped Apple-Hosted Background Assets in our App Store app (iOS 26.0+, released September 12, 2026): 14 managed asset packs named ea-<system>-s1 (about 955 MB in total, all in “Ready for Distribution” in App Store Connect), on-demand download policy. The app downloads them sequentially with AssetPackManager.shared.ensureLocalAvailability(of:) (on iOS 26.4+ with requireLatestVersion:), observes statusUpdates, and runs a BGContinuedProcessingTask for foreground progress. In production the managed downloads fail for a large share of devices. Our analytics for the first three days (7,384 devices started the download): 68% completed; 6% ended in a hard failure that retries do not fix; about 25% never completed (many runs were cancelled because the BGContinuedProcessingTask expired). Failure classes (unique devices): NSURLErrorDomain -3007 “Download decoding failed” (NSURLErrorDownloadDecodingFailedToComplete), thrown by ensureLocalAvailability: 186 devices. Only on iOS 26.4+ (26.4/26.5: about 7% of devices that started; 26.6.x: about 1.3%; none on iOS 26.0–26.3). Free disk space is not a factor (median 74 GB free on failing devices). Users also see “The operation couldn’t be completed. (ManagedBackgroundAssetsProcessingPipeline.ProcessingPipelineError error 1.)”. The daily rate jumped 5x on September 14 (34 to 166 devices per day). ensureLocalAvailability returns successfully, but the pack’s files are not in the app-group namespace: AssetPackManager.shared.contents(at:searchingInAssetPackWithID:) fails for a file that is definitely inside the pack: 178 devices. Calling ensureLocalAvailability again returns immediately with the same result. Deleting and reinstalling the app fixes it. NSXPCConnectionInterrupted (4097) “Couldn’t communicate with a helper application”, XPC.XPCRichError error 1, ManagedBackgroundAssetsXPC.XPCInvocationError error 1: 74 devices. Rebooting the device fixes it. Downloads that never deliver a single progress event (stuck at 0% for minutes on Wi-Fi and cellular): about 100 devices. “The asset pack <Asset Pack | ID: ea-skeletal-s1 download size: 161205935 version: 1> is unavailable” (25 devices) and AMSErrorDomain error 203 (12 devices). Affected devices range from iPhone 11 to iPhone 17 Pro Max and several iPad models, in Russia, the US, Brazil and Kazakhstan alike, so this is not a regional network issue. The same packs work fine on the majority of devices, and they were uploaded with xcrun altool --upload-asset-pack and processed without errors. Questions: Is there a known issue with pack decoding/extraction in the managed pipeline on iOS 26.4–26.6, or on the Apple-hosted CDN side? The September 14 spike looks like a server-side change. What is the recommended recovery when the daemon reports a pack as available while its files are missing on disk: remove(assetPackWithID:) and ensureLocalAvailability again? Is there any way for developers to see per-download server-side errors for their asset packs? We had to ship a hotfix that bundles the 3D content inside the app again. We can provide a sysdiagnose from an affected device (a Feedback Assistant report will follow), the bundle ID and pack IDs privately, and exact timestamps of failed downloads.

Our new app needs an essential Background Assets asset pack (hosted by Apple) to work. The app is currently failing to get through App Review because the reviewer doesn't have access to the asset pack. We submitted the asset pack together with the application for review. The asset pack is already approved. However, the error the reviewer reported indicates that their device can't find or download the asset pack. Or to be precise, on macOS (Catalyst) the model information cannot be fetched—the model is not found. iOS seems to see the model and get the information, but the download fails or never proceeds past the first 0% progress. We already had the same issue with our TestFlight beta (see this post for details). In the end, App Review let it pass through without verification because it was a known issue. This will probably not work for the main app review. We even tried switching the download policy of the asset pack to essential (was preFetch before) in the hope that the reviewer will then automatically download the pack together with the app. But this still didn't work. We can't be the only ones having this problem, right? This is completely release-blocking for us, and we already have a close deadline...

Hello, I've been following the Background Assets documentation, and so far everything has worked. However, when I attempt to archive my asset pack in Terminal, I receive the following error: Error: Reading the contents of the file at “Manifest.json” failed. I've double checked the provided instructions, tried archiving in different directories, and tried every permutation of Manifest.json I could think to try. Same error every time. Here's my Manifest.json code in case the issue is there. Thanks in advance! "assetPackID": "classic", "downloadPolicy": { "essential": { "installationEventTypes": [ "firstInstallation" ] } }, "fileSelectors": [ { "directory": "audio" }, ], "platforms": ["tvOS"] }

On macOS 27.0 seed 6 (26A5421a) / Xcode 27 beta 6, the first touch of AssetPackManager.shared in a Managed Background Assets macOS app fatals at AssetPackManager.swift:360 with The app couldn't be validated: The app group with the ID "TEAMID.group.example.app" is inaccessible — with the app signed with exactly that group, BAAppGroupID matching, containerURL(forSecurityApplicationGroupIdentifier:) returning a real directory, and the container present on disk. I tried varying it and got the same result: App Sandbox on/off; the group spelled team-prefixed and iOS-style at every point of use. Notably, in the iOS-style build the message still names the team-prefixed identifier, which appears nowhere in that build — so the framework composes the prefixed form itself and validates that. The Mac provisioning profile authorizes group.example.app explicitly plus the auto-added TEAMID.* wildcard, and since the portal only registers group.-style IDs, no profile can list the prefixed form by name. Is this a known issue in seed 6? Is there a workaround? And does Managed Background Assets on macOS assume a Mac App Store / TestFlight distribution context for its app-group validation, in a way a development-signed app can't satisfy? Filed as FB24525451 with three crash reports (sandboxed, unsandboxed, iOS-style) and a sysdiagnose.

Hi, We are seeing Apple-hosted Managed Background Assets download failures on macOS 26.6.1 and would appreciate confirmation of whether this is a known issue or a configuration problem. Environment macOS app using Apple-hosted Managed Background Assets Apple Silicon Macs: M1 and M4 App version: 1.0.2 (build 10) App and downloader extension are sandboxed and use the same App Group No ba-serve development URL override is configured: xcrun ba-serve url-override reports that no override is set. Observations On the same M1 Mac: On macOS 26.5.2, Background Assets began transferring an asset pack successfully. The log recorded 136,586,876 bytes received before I manually cancelled the download. After upgrading to macOS 26.6.1, Background Assets reaches manifest resolution and download scheduling, but the asset transfer fails. The macOS 26.6.1 logs show: NSURLErrorDomain -1200 The certificate for this server is invalid / secure connection failed kCFStreamErrorDomainSSL -9816 server closed session with no notification NSURLErrorDomain -3007 Download decoding failed A separate M4 Mac running macOS 26.6.1 also reproduces the issue. One relevant variable: both the working 26.5.2 log and the failing 26.6.1 log show the Background Assets traffic passing through a local HTTP/S proxy at 127.0.0.1:6152. I am now testing a direct route for odr.itunes.apple.com and amp-api.apps.apple.com, but this proxy path was also present in the 26.5.2 transfer that started successfully. The asset pack IDs in the two captured logs are not identical, so this is not a strict same-pack A/B comparison. However, the failure is reproducible for Apple-hosted packs on 26.6.1, while the pre-upgrade log shows a real transfer on the same M1 Mac. Has anyone seen either of these on macOS 26.6 / 26.6.1? NSURLErrorDomain -3007 (Download decoding failed) for Apple-hosted Background Assets TLS error -1200 / kCFStreamErrorDomainSSL -9816 during a Background Assets pack transfer A change in support or behavior for HTTP/S proxy routing of Apple-hosted asset-pack downloads I have filed Feedback Assistant report FB24301118 with the relevant logs and diagnostic attachment. Thanks.

Hello, Apple’s documentation appears inconsistent about which App Store Connect API should be used to submit an Apple-hosted Background Asset version for external TestFlight review: In WWDC25 “Discover Apple-Hosted Background Assets”, Apple says that the asset pack version can be submitted using the POST /v1/betaBackgroundAssetReviewSubmissions. In Uploading and versioning Apple hosted background assets, the external beta review instructions link to “Submit an app for beta review,” which uses POST /v1/betaAppReviewSubmissions. These two resources have different behavior. betaBackgroundAssetReviewSubmissions I called the public API with the same resource structure used by the App Store Connect web UI: POST https://api.appstoreconnect.apple.com/v1/betaBackgroundAssetReviewSubmissions { "data": { "type": "betaBackgroundAssetReviewSubmissions", "relationships": { "backgroundAssetVersion": { "data": { "type": "backgroundAssetVersions", "id": "<BACKGROUND_ASSET_VERSION_ID>" } } } } } The public API returned 404 PATH_ERROR: The resource 'v1/betaBackgroundAssetReviewSubmissions' does not exist. However, the App Store Connect web UI uses the private endpoint below with the same payload and receives HTTP 201: POST https://appstoreconnect.apple.com/iris/v1/betaBackgroundAssetReviewSubmissions The public endpoint is also absent from the current App Store Connect OpenAPI specification. betaAppReviewSubmissions I also tested the public POST /v1/betaAppReviewSubmissions endpoint. When I supplied a backgroundAssetVersion relationship, the API returned 409: 'backgroundAssetVersion' is not a relationship on the resource 'betaAppReviewSubmissions'. You must provide a value for the relationship 'build'. The build relationship only accepts the builds resource type, not backgroundAssetVersions. Therefore, betaAppReviewSubmissions can submit an app build but cannot submit a Background Asset version. Could Apple please clarify: Which public API should be used to submit a Background Asset version for external TestFlight review? Is betaBackgroundAssetReviewSubmissions intended to be exposed through the public App Store Connect API? Is the link to betaAppReviewSubmissions in the Background Assets documentation incorrect? When will the public documentation and OpenAPI specification be updated? Thank you.

I have finished a new app that integrates Apple hosted background asset. I have tested and confirm that the assets are downloaded both locally and with a TestFlight build. App review is not able to access the background assets. I can see that the assets are updated with status "accepted". But app review is running into error "A server with the specified hostname could not be found.". These are Apple Hosted Assets. Did I miss any configuration?

I have a multi-platform app 1 (visionOS, macOS, tvOS) on the app stores. I am trying to add an iOS version but it got rejected. I have been trying to get another visionOS app 2 accepted but that was also rejected. After app 1 was rejected I retried the other app 1 versions and had some issue downloading Background Assets . After reinstalling the app 1 versions from their App Stores they worked as expected. The other app 2 was working for me via TestFlight but each time I submitted a new version of the app it was rejected with a black screen image, indicative of a downloading issue. I may need to do some coding work on app 2 but the behavior of accepted app 1 versions has me asking if others have seen issues with Background Asset downloads. This seems to be a relatively new technology so maybe stiill a work in progress.

We're evaluating Apple-hosted Background Assets for an app distributed on App Store and would like to understand the security model behind it before adopting it. So far the public documentation only mentions the HTTPS requirement for asset transport. We'd appreciate any additional documentation or guidance covering: How asset downloads are authenticated (e.g., is access tied to the app's entitlement/provisioning, or is there a separate token/credential mechanism?) How access to specific assets is controlled/scoped Where Apple-hosted assets are physically/logically hosted (e.g., is this CDN-backed, and is there any control or visibility over hosting region?) Any other security considerations typically associated with cloud-hosted content (encryption in transit and at rest, integrity verification, etc.) Is there a more detailed security/architecture document beyond the public developer documentation, or can someone from the team point us in the right direction?

Hello, We're evaluating Apple-hosted Background Assets for an app distributed on the public App Store. Is there any documentation or guidance on update latency, specifically: How quickly are asset updates propagated to devices once a new version is published? More specifically, is propagation near-immediate, or should we expect a delay (minutes/hours/days) before devices know they have to pick up the new version in the ideal condition of being connected to Wi-Fi, locked, charging and the app has been recently used? Are there any other factors other than the aforementioned ones that affect how fast an update reaches a device? Any official documentation, WWDC session, or guidance from the team would be appreciated, thanks in advance.

Hello, We are currently developing a macOS application and evaluating Managed Background Assets for delivering additional downloadable content. Our preference is to rely on Apple-hosted asset delivery as much as possible, rather than maintaining a separate CDN or server infrastructure. While reviewing the documentation and forum discussions, we found a few areas that are still unclear and would appreciate your guidance. 1. Scope of the 200GB Apple-hosted asset pack limit Some documentation and discussions seem to describe the 200GB limit as applying per Apple Developer Program team/account, while others suggest it is a per-app bundle limit. Could you clarify the exact scope of this limit? Is the 200GB quota applied per individual app bundle ID? Or is it shared across all apps under the same Apple Developer Program account? References: [LINK1] [LINK2] [LINK3] 2. Storage expansion and hybrid hosting Are there any plans to expand the Apple-hosted asset pack limits in the future, or is there an official process to request additional hosting capacity? If an app eventually exceeds the Apple-hosted limit, is it acceptable or technically possible to use a hybrid approach (i.e., using Apple hosting for some assets while self-hosting the rest)? 3. Recommended strategy for older macOS versions As we understand, Managed Background Assets are only available starting from newer OS releases. However, our application also supports older macOS versions, and we would ideally like to avoid maintaining a completely separate asset delivery backend for them. From Apple’s perspective, what is the recommended strategy in this situation? Is it expected that developers continue using Unmanaged Background Assets for older OS compatibility? Is it acceptable to support Managed Background Assets only on newer systems, while older OS versions simply do not receive the same downloadable-content functionality? Or is there another recommended migration/compatibility approach for apps supporting both newer and older macOS versions? Thank you in advance for your clarification!

Hello. I have a problem with the FoundationModels adapter and the Apple-hosted managed asset pack via TestFlight. I have created an adapter that works fine locally by creating a model via (fileURL: URL) on a real device, but I cannot create a model using background assets by downloading the adapter via TestFlight. Every time I try to get an adapter, the creation of the adapter is interrupted by the compatibleAdapterNotFound error. The aar. archive i created using a special command - xcrun ba-package foundation-models package --adapter-path aurelius1.fmadapter --asset-pack-id fmadapter-aurelius1-9799725 --output-path ./aurelius1.aar --platforms iOS --on-demand\ after that, I replaced "OnDemand": null with "OnDemand": {} in the manifest so that the Transporter could send my archive to the App Store Connect. I followed all the recommendations in this topic - https://origin-devforums.apple.com/forums/thread/823148 ...but unfortunately unsuccessfully I would appreciate any help in solving this problem. here is the code that I use in my app -

Hello, We are currently evaluating ways to reduce the app size of the my App. The app contains approximately 200~250 MB of bundled static resources, and we are considering converting these resources into On-Demand Resources（ODR） in order to reduce the initial download and installation size of the app. However, we noticed that ODR is currently marked by Apple as a Legacy Technology. Since we would like these resources to continue being hosted and distributed through Apple CDN / App Store infrastructure, the first alternative we considered is Managed Background Assets, rather than regular Background Assets. We understand that regular Background Assets are available on iOS 16 and later, but they mainly address background download scheduling for apps. What we are specifically looking for is the resource hosting and distribution capability, similar to ODR, where assets can be hosted and delivered through Apple’s infrastructure. This is why we are considering Managed Background Assets. However, my App currently supports devices starting from iOS 14, while the key capabilities of Managed Background Assets require newer iOS versions. As a result, this solution cannot fully cover users who are still on older iOS versions, such as iOS 14 through iOS 18. Given this background, we would like to ask Apple the following questions: Does Apple have any plan to discontinue ODR-related services in the future, especially the App Store-hosted ODR asset download service? If the ODR service is changed or discontinued in the future, would it affect already released App Store apps that rely on ODR asset downloads on older iOS versions? For apps that still need to support iOS 14 and later, while also relying on Apple CDN / App Store infrastructure for resource hosting and distribution, does Apple still recommend using ODR? For apps that cannot immediately raise their minimum supported iOS version to the version required by Managed Background Assets, is there a recommended transition strategy? If ODR services are discontinued in the future, will Apple provide an alternative resource distribution solution that supports older iOS versions, or would developers need to build and maintain their own resource hosting and download system? We would like to better understand the long-term availability and potential risks of using ODR on older iOS versions, so that we can make an appropriate decision for future app size reduction and asset delivery in the App. Thank you.