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.

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 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.

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!

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.

I have created and tested background assets (Apple Hosted) with both "essential" and "onDemand". They works on the iPhone and iPad following the "Testing asset packs locally" steps. However, when I upload to TF; the iPad fails to download. The iPhone is able to download both "essential" and "onDemand" fine. I am adopting the manifest from xcrun ba-package template -o Manifest.json Manifest.json

We have an on-demand asset pack that we download at the start of the app. We first present the user with the download size and the option to download the asset. The iOS version of our app went through review just fine, but the macOS version (Catalyst) is stuck. The reviewer reports an error that indicates that even the lookup of the asset pack (assetPack(withID:)) doesn't work. On all our test devices we don't have that issue. It seems the reviewer is running the app in an environment that is unable to load the asset pack information from TestFlight. We don't know what to do here. Any help would be appreciated!

Platform: iOS 26 (23E254) Xcode: 26.0 Reproduces on: Debug builds AND TestFlight Summary: I'm using Apple-Hosted Managed Background Assets with on-demand download policy. The .aar archives download successfully (correct file size, status = downloaded), but the contents are never extracted into the asset pack namespace. AssetPackManager.shared.contents(at:) returns fileNotFound for all path variants, and url(for: FilePath(".")) returns a URL that exists but contains zero children. Root Cause from Sysdiagnose: The backgroundassets.user daemon logs reveal this error on every download attempt: A bundle record couldn't be looked up for the application identifier "AtlasDrift.SnapTrail": Error Domain=NSOSStatusErrorDomain Code=-10814 "(null)" UserInfo={_LSFile=LSBindingEvaluator.mm, _LSLine=1973, _LSFunction=runEvaluator} Error code -10814 is kLSApplicationNotFoundErr. The BA daemon downloads the .aar blob, then attempts to find the app bundle via LaunchServices to locate the extension for extraction — but the LS lookup fails. Without the extension, extraction never occurs. Verified Configuration Everything matches the documentation and WWDC sessions: Extension embedded at SnapTrail.app/Extensions/BackgroundDownloadExtension.appex Bundle IDs: App = AtlasDrift.SnapTrail, Extension = AtlasDrift.SnapTrail.BackgroundDownloadExtension (correct parent-child pattern) Extension point: com.apple.background-asset-downloader-extension Product type: com.apple.product-type.extensionkit-extension Protocol: StoreDownloaderExtension from StoreKit (for Apple-hosted packs) App group: group.AtlasDrift.SnapTrail (matching in both app and extension entitlements) Info.plist keys: BAAppGroupID, BAHasManagedAssetPacks = YES BAUsesAppleHosting = YES (no BAInitialDownloadRestrictions or other BA keys) .aar Packaging Archives built with xcrun ba-package from the Assets directory. Manifest format: { "assetPackID": "ireland", "downloadPolicy": { "onDemand": {} }, "fileSelectors": [{ "directory": "POIRegions/ireland/IR" }], "platforms": ["iOS"] } Uploaded via App Store Connect API with assetType: "ASSET". Diagnostic Observations AssetPackManager.shared.assetPack(withID:) returns valid metadata (correct download size) ensureLocalAvailability(of:) completes without error assetPackIsAvailableLocally(withID:) returns true url(for: FilePath(".")) returns a URL that exists but has zero children (empty namespace) contents(at:) returns fileNotFound for all path variants tested The extension never runs — breadcrumb file written in init() is never created The -10814 error appears in daemon logs for every download cycle Questions Has anyone successfully used Apple-Hosted Managed Background Assets on iOS 26 beta? Is the daemon's LaunchServices integration known to be broken in this seed? Is there anything about the bundle identifier format or provisioning profile setup that could cause the BA daemon's LS lookup to fail, even though the app installs and runs fine otherwise? Are there any additional Info.plist keys or entitlements beyond what's documented that might be required for the daemon to locate the app bundle? Any guidance would be appreciated. I've filed a Feedback report with the full sysdiagnose attached.

Does the App Review process have access to Apple-Hosted Asset Packs during review? My app uses Asset Packs to offer a library of data to the end-user (with a workaround, if unavailable), but I am frequently seeing the workaround screen in App Review with errors I haven't seen elsewhere. The latest error I encountered (via the App Review team's feedback) was: "A server with the specified hostname could not be found." thrown from (to my belief) AssetPackManager.shared.ensureLocalAvailability. This is unexpected to me, as both this code as well as the asset packs have already been released and are working reliably in production. Has anyone else experienced these issues?