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.

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, 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?

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?

Hi, anyone managed to make this work? https://developer.apple.com/documentation/backgroundassets Trying for past few days and can't make it work. Following their official documentation, also this video https://www.youtube.com/watch?v=M3jpgZrB1uo, but it seems I am stuck at: try await AssetPackManager.shared.ensureLocalAvailability(of: assetPack) What I did: Manifest files created, info.plist configured, asset pack created and uploaded to appstoreconnect via transporter, successfully assigned to app and ready for internal testing. Added to my code: let assetPack = try await AssetPackManager.shared.assetPack(withID: "Tutorial") try await AssetPackManager.shared.ensureLocalAvailability(of: assetPack) let videoData = try AssetPackManager.shared.contents(at: "Videos/Introduction.m4v") but no luck at all.... is anywhere any demo project available to download to compare with my project?

Hello, I have followed the instructions in https://developer.apple.com/documentation/backgroundassets to setup background asset to work on the iPhone. I am able to confirm successfully test the asset packs locally on the iPhone. However, when I try to run the my test code on the Mac (Designed for iPad), I get this error. BackgroundAssets/AssetPackManager.swift:206: Fatal error: The app couldn’t be validated: The bundle’s info dictionary lacks a string value for the key “BAAppGroupID”. Is this feature not supported on the Mac?

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.

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.