Has anyone seen Managed Background Assets get stuck before any download progress is reported on iPadOS 26.3 / TestFlight? We are using Apple-hosted managed asset packs for a large on-demand model download. The app can resolve the asset pack metadata: we can show the asset pack’s download size in the UI, so AssetPackManager.assetPack(withID:) appears to work. But when we call ensureLocalAvailability(of:), the UI stays at 0% indefinitely. We also do not receive any useful terminal state from statusUpdates(forAssetPackWithID:): no .began, .downloading, .failed, or .finished. The app remains responsive. The issue also appears persistent on the affected device/account. Reinstalling the app does not help, reinstalling TestFlight does not help, logging out and back in does not help, and restarting the device does not help. After each attempt, the app can still resolve the asset pack metadata/download size, but the actual download remains stuck before any progress or failure status is delivered. The suspicious part of the device log is that the managed helper starts normally, fetches/installs the manifest from TestFlight, but repeatedly fails to create its helper directory inside the app container: OurApp Initializing the asset-pack manager… OurApp Creating a proxy object for the helper service… OurApp activating connection ... name=com.apple.backgroundassets.managed.helper.service kernel Sandbox: no system container path found for ID "com.apple.backgroundassets.managed.helper.service" Managed Background Assets Helper Service Starting the Managed Background Assets Helper Service… Managed Background Assets Helper Service Configuring the directory suffix… Managed Background Assets Helper Service The directory suffix was successfully configured. Managed Background Assets Helper Service The extension token "<...>" was consumed. kernel Sandbox: Managed Background Assets Helper(...) deny(1) file-write-create /private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service Managed Background Assets Helper Service mkdir: path=/private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service/ mode= -rwx------: [1: Operation not permitted] After that, manifest fetching still seems to work: OurApp The asset-pack manager has been initialized. OurApp The system download-manager delegate has been assigned to the download manager. OurApp The app was installed for internal beta testing; checking for updates automatically… OurApp Refreshing the manifest… Managed Background Assets Helper Service The app with the bundle ID "..." is configured to use Apple hosting. Managed Background Assets Helper Service Asking the TestFlight extension via the App Store Daemon for the URL request... Managed Background Assets Helper Service Fetching the download manifest ... from TestFlight… Managed Background Assets Helper Service Installing a manifest at ".../Library/Application Support/.../Manifest.json"... But during/after manifest install, the same mkdir failure appears again: Managed Background Assets Helper Service Installing a manifest at ".../Manifest.json"... Managed Background Assets Helper Service mkdir: path=/private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service/ mode= -rwx------: [1: Operation not permitted] kernel duplicate reports for Sandbox: Managed Background Assets Helper(...) deny(1) file-write-create /private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service So the behavior seems to be: TestFlight/internal beta install Apple-hosted managed asset pack Manifest fetch succeeds Asset pack metadata resolves, including download size Actual local availability request never starts reporting progress No visible Background Assets failure reaches the app Logs show repeated sandbox file-write-create denial for the Managed Background Assets Helper trying to create /tmp/com.apple.backgroundassets.managed.helper.service inside the app container Reinstalling the app/TestFlight, logging out and back in, and restarting the device do not clear the stuck state On devices with 26.4, the issue doesn’t seem to exist Has anyone else seen this on iOS/iPadOS/macOS versions before 26.4? Is this a known issue in the Managed Background Assets helper/runtime? I noticed 26.4 added more local status APIs for asset packs, so I’m wondering whether this area changed in 26.4. Any hints on whether the sandbox denial is expected/noisy, or whether it could explain ensureLocalAvailability(of:) never progressing, 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.

Hi, I'm stuck distributing a custom FoundationModels adapter as an Apple-hosted managed asset pack via TestFlight. Everything looks correctly configured end to end but the download just never starts and the statusUpdates sequence is silent. Here's my configuration: App Info.plist: <key>BAHasManagedAssetPacks</key><true/> <key>BAUsesAppleHosting</key><true/> <key>BAAppGroupID</key><string>group.com.fiuto.shared</string> Entitlement com.apple.developer.foundation-model-adapter on both the app and the asset downloader extension. The asset downloader extension uses StoreDownloaderExtension , returning SystemLanguageModel.Adapter.isCompatible(assetPack) from shouldDownload , and the app group on app and asset download extension is the same. I have exported the adapter with toolkit 26.0.0, obtaining: adapterIdentifier = fmadapter-FiutoAdapter-1234567 I have packaged the asset pack using xcrun ba-package and uploaded it to App Store Connect via Transporter, and I get the "ready for internal and external testing" state on App Store Connect, and I have uploaded my app build on TestFlight after the asset pack was marked as ready. I used this code: let adapter = try SystemLanguageModel.Adapter(name: "FiutoAdapter") let ids = SystemLanguageModel.Adapter.compatibleAdapterIdentifiers(name: "FiutoAdapter") // ids == ["fmadapter-FiutoAdapter-1234567"] for await status in AssetPackManager.shared.statusUpdates(forAssetPackWithID: ids.first!) { } I expect the download to start and the stream to yield first .began, then .downloading(progress) and .finished. Actually, compatibleAdapterIdentifiers returns the correct ID, the stream is correctly acquired but i get zero events, so no .began/.downloading/.failed/.finished. Important things: I don't get any error in Console as well; I tested this as an internal tester on TestFlight Tested on iPhone 16 Pro, running iOS 26.3.1 - more than 50GB of free space Apple Intelligence is enabled and set in Italian Background downloads are enabled. I've already checked if the adapter identifier matches regex fmadapter-\w+-\w+ , i tried to reinstall the build, rebooting the device, reupload the asset pack, and also checked that the foundation models adapter entitlement is present on both targets. Is there a known way to diagnose why statusUpdates is silent (no log subsystem seems to show why) in this exact configuration? Is there maybe any delay between asset pack approval on App Store Connect and availability to TestFlight internal testers that I do not know of? I've checked other threads for applicable solutions and I've found that this is similar to the symptom reported in this thread: https://developer.apple.com/forums/thread/805140 / (FB20865802) and also i'm internal tester and on stable iOS 26.3.1, so the limitations from this thread: https://developer.apple.com/forums/thread/793565 shouldn't apply. Thanks

Hello, I've run into an issue where AssetPacks being served locally are downloading but unable to complete. try await AssetPackManager .shared .ensureLocalAvailability(of: assetPack) This method is called but never appears to complete. Even 10 minutes after the download is finished. <NSProgress: 0x10fb4fc80> : Parent: 0x0 (portion: 0) / Fraction completed: 1.0000 / Completed: 2462633379 of 2462633379 This however does not appear to be an issue in production, as the method completes 30-60 seconds after the download has finished. Issue happens across multiple devices running 26.4.1

Hello, Because our app package size is relatively large, part of our resources needs to be delivered through Apple-hosted asset packs. If we use the Background Assets framework to download these Apple-hosted packs, our app would only be able to support devices running iOS 26 or later. To maintain compatibility with a broader range of iOS versions, we chose to use iOS On-Demand Resources instead. However, during actual use, we found that even when these packs are marked with the initial install tag, there is still a fairly high probability (around 40%) that they are not available on the first screen after the app is launched for the first time. When we try to access them through conditionallyBeginAccessingResourcesWithCompletionHandler, the resources are unavailable, which forces us to download them again. During testing, we added event tracking and found that out of 22 users who downloaded the app, 9 had to re-download these resource packs on first launch. Each of these packs marked with the initial install tag is about 300 MB in size. We have also made sure to follow the NSBundleResourceRequest limitation that no more than 2000 × 1000 × 1000 bytes of resources should be accessed at the same time. We would like to understand why these packs, even though they are marked as initial install, still have such a high probability (around 40%) of being unavailable on the first screen at first launch.

We are trying to upload the first Apple-hosted Managed Background Assets pack for our macOS app, but Transporter rejects the asset pack ID during upload. App details: App name: DistillApp Apple ID: 6760288806 Bundle ID: cn.rkbkosp.DistillApp Asset pack ID: distill.pipeline.zh-baseline Platform: macOS Transporter: 1.4 Xcode: 26.2 macOS: 26.3.1 What we see in Transporter: Apple ID: 6760288806 App Name: DistillApp App Bundle ID: cn.rkbkosp.DistillApp No background assets found. And when we try to upload the first asset pack, Transporter fails with: 获取 Apple ID “6760288806”的资源包列表失败。 (-19243) There is an error with a URL parameter (400) Found invalid values: distill.pipeline.zh-baseline What we have already confirmed locally: The app resolves correctly in Transporter, so the Apple ID and bundle ID appear to be correct. The app Info.plist includes: BAHasManagedAssetPacks = YES BAUsesAppleHosting = YES BAAppGroupID = 8U6DAJ62JT.group.cn.rkbkosp.DistillApp.assets The asset pack manifest uses: assetPackID = distill.pipeline.zh-baseline This is intended to be the first Apple-hosted background asset pack for the app. Our understanding is that No background assets found is expected before the first successful upload, so the actual problem seems to be that Transporter/App Store Connect refuses to accept the initial asset pack ID. Questions: Has anyone seen Transporter reject the first Apple-hosted background asset pack for an app with -19243 and 400 invalid values? Does the first Managed Background Assets upload require any additional App Store Connect state beyond having BAHasManagedAssetPacks and BAUsesAppleHosting in the app? Does the app need a newly processed build in App Store Connect after enabling those plist keys before the first asset pack upload will work? Is there any known issue in Transporter 1.4 or App Store Connect for first-time Apple-hosted MBA uploads on macOS apps? If useful, I can also share the exact asset pack manifest and a redacted upload log.

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?

I've followed the setup process to get Apple Hosted Background Assets configured for my project. (https://developer.apple.com/documentation/backgroundassets/downloading-apple-hosted-asset-packs) But when I build and run the app I get the following error... BackgroundAssets/AssetPackManager.swift:174: Fatal error: The process lacks a team ID. I've checked the Signing->Team for both targets and they both have my Team associated. Any help or advice would be appreciated...

Summary I'm using Background Assets to download Apple-hosted Asset Packs(downloadPolicy = onDemand). The first download cancellation succeeds, but on the second and subsequent downloads, progress.cancel() fails to work and the download completes to the end. Environment iOS 26.0 – 26.3 RC (all produce the same result) Xcode Version 26.2 (17C52) Using Apple-hosted Asset Packs Steps to Reproduce Start downloading an Asset Pack Call progress.cancel() during download → Succeeds Start downloading the same Asset Pack again Call progress.cancel() during download → Fails (download completes to the end) Observed Error Logs After 1st cancellation: A download with the ID "X-XXXXXXXX-XXX" failed: Error Domain=NSURLErrorDomain Code=-999 "cancelled" ↑ This is expected (cancellation succeeded) The fact that version 0 of the asset pack with the ID "X-XXXXXX-XXX" finished being downloaded couldn't be reported: Error Domain=NSCocoaErrorDomain Code=3851 "Property list invalid for format: 200 (property lists cannot contain objects of type 'CFError')" ↑ Problem: Unable to serialize CFError to plist 2nd cancellation attempt: The download with the ID "X-XXXXXX-XXX" couldn't be canceled: Error Domain=BAErrorDomain Code=113 "The requested download operation failed because the download object did not exist." ↑ The download object we're trying to cancel supposedly doesn't exist Implementation Code // Cancel implementation func cancel(tag: String) async { let statusUpdates = AssetPackManager.shared.statusUpdates(forAssetPackWithID: tag) for await statusUpdate in statusUpdates { if case .downloading(_, let progress) = statusUpdate, progress.isCancellable { progress.cancel() } } } Analysis It appears that when the first cancellation occurs, the system internally tries to save the cancellation state to a plist, but fails to serialize the CFError object. This seems to cause an inconsistent internal state, preventing the system from correctly recognizing the download object on subsequent downloads. Questions Is there a workaround? Is there a planned fix for a future iOS version?

Hello there, Our application has HLS VOD download option. Users can download VOD which has DRM protection and watch content when device is offline. We use aggregateAssetDownloadTask to download HLS VOD. We want to resume download after Wifi/LTE change but it does not resume. Download is starting from beginning. We use some token algorithms to start download. That's why, our playlist url and chunks urls may change. But playlist and chunk urls' content is unique. If user start to download via Wifi and changed to LTE. Download request responds 403 Forbidden because of some token algorithms after some time func urlSession(_ session: URLSession, task: URLSessionTask, didCompleteWithError error: Error?) AVAssetDownloadDelegate function triggered by system. If we resume it does not resume at this point. It is starting from beginning if we start new download process for same content. Is there any way to resume unfinished HLS Download processes? Thanks

This is a question as I don't found any related documents or posts anywhere about this. Does anyone know how and when will this "pop up" shown?

Hi all, I have set up a trivial test project to try Apple-hosted background assets following the instructions in the three articles at https://developer.apple.com/documentation/backgroundassets. When I run the local mock server with xcrun ba-serve and set the URL override in Settings as described in the "Testing asset packs locally" article, I am able to download a test pack on my iOS devices. On the Mac that I use to run the mock server, however, the same call to AssetPackManager.shared.assetPack(withID: "TestAssetPack") that works on iOS always reports The asset pack with the ID “TestAssetPack” couldn’t be looked up: No asset pack with the ID “TestAssetPack” was found. even when not running the mock server, which led me to believe that it may not be hitting it at all. In fact, the macOS app will download asset packs uploaded to App Store Connect even when running the local server and setting the xcrun ba-serve url-override to the exact same string as in Settings on iOS. My initial suspicion was that something is wrong with the URL override, so I have tried all combinations of the Mac's hostname, IP address or "localhost" (with the corresponding SSL certificates) with and without port 443, always prefixing with "https://" for the url-override. All the same. Does anyone have an idea what may be the issue here? My asset pack has the following manifest: { "assetPackID": "TestAssetPack", "downloadPolicy": { "onDemand": {} }, "fileSelectors": [ { "file": "TestAsset.txt" } ], "platforms": [ "iOS", "macOS" ] } I am running v26.1 for macOS, iOS & Xcode. Edit: Just to be clear, my assumption here is that the URL overrides (in Settings on iOS or via ba-serve on macOS) is what should cause the app to hit the mock server. Is that correct or am I missing something?

Hi Everyone 🙌 Who knows, additional content that downloads in install time are summarized to total app size in App Store page ? If yes, additional size going to WiFi/Cell download recommendations ? And what the limit ? Will be appreciate of all information, maybe someone using Background Asset extension :pray:

Hello, I've just been unfortunate enough to discover a critical issue. I have two apps using Asset Packs, and I believe both apps had an Asset Pack with the same identifier. In App Store Connect for App B, I archived this Asset Pack. However, the Asset Pack has been archived for both Apps. This shouldn't happen.

Hello, I have an asset pack that I'm use to periodically distribute a sqlite database thats being used to an NSPersistentStore. Because the database is over a few GBs, and the files in an AssetPack are not mutable, I have to stream the database into a temporary file, then replace my NSPersistentStore. This requires that the user has 3x the storage available of the database, and permanently uses twice to storage needed. I'd like: To be able to mark a URL/File to be accessible for read/write access To be able to mark a file / URL as consumed when it's no needed. So that it can be cleared from the user storage while still maintaining an active subscription to the asset pack for updates. Thank you

I have a total of 100 asset packs associated with my app but I have archived 5 of them. Unfortunately I am now unable to upload any more asset packs (the reported error is "backgroundAsset limit reached -- This app has already reached the maximum number of active backgroundAssets. Maximum allowed is 100.") I assumed that archiving asset packs would make them inactive (and thus not count against the limit). This seems to not be the case and I'm not sure how I can upload new asset packs.

Is there a way to enumerate all files within a folder of an asset pack or just all files in general? My application is using the Apple demo code to load a file from an Apple hosted asset pack: let descriptor = try AssetPackManager.shared.descriptor(for: "NAV/NavData.db3") defer { try descriptor.close() } if let path = path(for: descriptor) { self.database = try Database(path: path) } As my "Navigation Data" is updated each month with an updated asset pack I would like to have the name of the .db3 file reflect the current data cycle (e.g. NAV2601.db3, NAV2602.db3, ...) Ideally I would like to iterate over all files within the NAV folder of the current asset pack and pick the most recent one. Unfortunately, neither the AssetPackManager nor the AssetPack object seem to include an API for this. It would be cool to have something like: let files = try AssetPackManager.shared.files(for: "NAV/") for file in files { //Check and load }

Hello, I have an app with a few essential asset packs currently totaling to ~8GB. I've noticed that when trying to install the app fresh from TestFlight, there is a significant delay between tapping install and the app appearing on the device in the loading state. The delay is long enough where it's hard to tell what's happening, or if the installation has failed. This also appears to be an issue in App Review, as I've had my app rejected twice due to the app not loading on the reviewers device. The reason they gave is UIRequiredDeviceCapabilities is blocking the installation, but UIRequiredDeviceCapabilities is empty. Note: I'm not looking for App Store review help, simply sharing the extent of the issue. Thank you

Hello, I was just installing an app from TestFlight that has an Essential Asset Pack that's a few GBs in size. It appears the Call To Action inside of TestFlight doesn't take into consideration the Background Asset download status before it changes from Installing to Open. I can't test if this is also the case for apps on the App Store, but I'd expect that it is.

Background Assets can support a maximum of 200G. Will the Apple server perform file comparison? For example, file0 is included in both a.aar file and b.aar file. On the Apple server, does it occupy twice the size of a single file?