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?
Background Assets
RSS for tagSchedule background downloads of large assets during app installation, when the app updates, and periodically while the app remains on-device.
Posts under Background Assets tag
35 Posts
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
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,
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.
Topic:
App Store Distribution & Marketing
SubTopic:
App Store Connect
Tags:
App Store Connect
Background Assets
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
Topic:
App & System Services
SubTopic:
iCloud & Data
Tags:
Files and Storage
On demand resources
Core Data
Background Assets
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
Topic:
App Store Distribution & Marketing
SubTopic:
General
Tags:
StoreKit Test
App Review
App Store Connect
Background Assets
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?
Hello,
I am encountering the following error when uploading a build to App Store Connect:
ITMS-90555: Thinned app size is too large – Your on-demand resources in the universal variant are 30 GB, which exceeds the maximum allowable size. After app thinning, the total size of your on-demand resource asset packs in any variant must be less than 30 GB.
Our application includes a large amount of font resources delivered via ODR.
Before making structural changes, I need clarification because the documentation does not fully explain how ODR size calculations work per variant.
Environment
Xcode: (latest stable)
Distribution method: App Store submission
ODR total size before thinning: approximately (28 GB)
Build processing fails immediately with the ITMS-90555 error
Questions
How exactly does App Thinning compute the size of ODR asset packs per variant?
Is ODR size evaluated:
Per device-specific variant,
Or is the “universal variant” treated as an additional variant that must independently stay under 30GB?
The documentation mentions a 30GB limit per variant, but the universal variant error message is ambiguous.
If device-specific variants are below 30GB but only the “universal variant” exceeds it, is the build still rejected?
In our case:
iPhone-only variants appear to be below the limit,
But the universal variant exceeds 30GB due to aggregated resources.
Is this expected behavior?
Best practices for managing very large ODR sets (e.g., fonts)
Fonts are small individually, but thousands of them produce very large ODR groups.
Is there recommended guidance from Apple for:
Structuring ODR bundles to avoid the universal variant exceeding the limit
Segmenting ODR by device class / feature sets
Any alternative packaging strategies
Are there tools or logs that reveal how App Store Connect decides variant groupings and ODR size?
At the moment, the failure only shows the ITMS-90555 error without further detail.
Case-ID for DTS reference
DTS advised submitting this question here.
Case-ID: 17273913
Any clarification from Apple engineers or community members who have navigated ODR size limits would be greatly appreciated.
Thank you very much!
Hello,
I'm trying to upload an asset pack that has the same identifier as an asset pack that I've archived.
I understand this isn't likely a common scenario, but I'd expect that uploading an archived Asset Pack to become un-archived. Reverting to the next newest version available for the Asset Pack.
Further, this restriction is not clear that you won't be able to reuse the assetPackID on the archive asset pack alert
Archive Asset Pack?
Are you sure you want to archive "[NAME]" asset pack? All versions of this asset will no longer be accessible by your app.
Errors:
Failed to create a new background asset pack version for '[NAME]'. (-19243)
operation not allowed (409)
Cannot create version for an archived background asset. (ID: 2cc6499a-83fa-4bbb-bc1f-0bb67d2a873d)
httpBody: {
"errors" : [ {
"id" : "2cc6499a-83fa-4bbb-bc1f-0bb67d2a873d",
"status" : "409",
"code" : "STATE_ERROR.ARCHIVED_BACKGROUND_ASSET",
"title" : "operation not allowed",
"detail" : "Cannot create version for an archived background asset."
} ]
Hello,
I have a question about when are asset packs actually updated?
For Essential Asset Packs, this only during the keys included in the pack? As in, only when the app is installed for
firstInstallation. And only when there's an app update for subsequentUpdate?
For On Demand Asset Packs, is this only when AssetPackManager.shared.checkForUpdates() is called?
Also, are any asset packs ever actually updated in the background? For example, if an On Demand Asset Pack has an update pushed, can the device automatically fetch and download the pack overnight?
Or is updating limited to only when the app is active?
Hello,
I have an Asset Pack that's a database. I need to use it in 2 apps.
I'm curious at the expected functionality of cross app Asset Pack distribution as I've seen conflicting behavior.
(1) Each app is required to have its own unique Background Assets Target.
(2) Uploading the asset pack requires the App ID to be included.
(3) I'm able to access the Asset Pack of App #1 inside of App #2 by using AssetPackManager.shared.ensureLocalAvailability(of:) with local testing (Not TestFlight)
This is a technical question as originally I planned to duplicate the upload of the Asset Pack to both individual apps.
Can anyone please confirm that Apple-hosted Background Assets still will NOT work unless the app is:
Installed from TestFlight, or
Installed from the App Store
Is it true Xcode-installed builds—Debug or Release—do not receive the App Store’s Background Asset metadata and cannot access the background asset packs?
I am getting the error when running the app in Xcode: The asset pack with the ID “VALIDPACKNAME” couldn’t be looked up: No asset pack with the ID “VALIDPACKNAME” was found.
Regarding the Background Assets capability on iOS:
In the install scenario, resources defined as the "install" type are incorporated into the App Store download progress. Do resources of the "update" type in the update scenario also get incorporated into the App Store download progress in the same way?
If an exception occurs during the download of install-type resources and the download cannot proceed further, will the system no longer actively block users from launching the app and instead enable the launch button?
Currently, if a user has enabled automatic updates on their device, after the app is updated and released on the App Store, will the Background Assets download start immediately once the automatic update completes? Or does Background Assets have its own built-in scheduling logic that prevents it from running concurrently with the automatic update?
Hi everyone,
I’m trying to register fonts system-wide using CTFontManagerRegisterFontURLs with the .persistent scope. The fonts are delivered through Apple-Hosted Background Assets (since On-Demand Resources are deprecated).
Process-level registration works perfectly, but persistent registration triggers a system “Install Fonts” prompt, and tapping Install causes the app to crash immediately.
I’m wondering if anyone has successfully used Apple-Hosted Background Assets to provide persistent, system-wide installable fonts, or if this is a current OS limitation/bug.
What I Expect
Fonts delivered through Apple-Hosted Background Assets should be eligible for system-wide installation
Tap “Install” should install fonts into Settings → Fonts just like app-bundled or ODR fonts
App should not crash
Why This Matters
According to:
WWDC 2019: Font Management and Text Scaling
Developers can build font provider apps that install fonts system-wide, using bundled or On-Demand Resources.
WWDC 2025: Discover Apple-Hosted Background Assets
On-Demand Resources are deprecated, and AHBAs are the modern replacement.
Therefore, persistent font installation via Apple-Hosted Background Assets appears to be the intended path moving forward.
Question
Is this a known limitation or bug in iOS?
Should .persistent font installation work with Apple-Hosted Background Assets?
Do we need additional entitlement, manifest configuration, or packaging rules?
Any guidance or confirmation from Apple engineers would be greatly appreciated.
Additional Info
I submitted a Feedback including a minimal reproducible sample project:
FB21109320
Topic:
App & System Services
SubTopic:
Processes & Concurrency
Tags:
Core Text
Background Assets
Typography
Concurrency
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?
I read on this documentation :
https://developer.apple.com/help/app-store-connect/reference/app-uploads/on-demand-resources-size-limits
that On Demand Resources a legacy technology.
Does this mean ODR will be deprecated?
If so, when will it officially take effect?
Our application is planning to use it, so we need more information to support our decision.
Hello,
I'm trying to figure out the behavior of AssetPackManager.shared.remove(assetPackWithID: ).
I'm working with MapKit tiles and currently working on trying projecting them correctly which involves serving the AssetPack locally, downloading, checking alignment, and then deleting and changing.
My question is that remove(assetPackWithID: ) completes successfully and the asset pack is removed. This is confirmed by trying to remove the AssetPack again which throws an error.
However, the asset is still appearing on MapKit after the removal. This is a bit odd as this persists not only with force killing, but also restarting the device.
Please advise on how to properly remove an AssetPack.
Thank you
iPhone 15 Pro Max (iOS 26.0.1)
iPhone 17 Pro Max (iOS 26.0.1)
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...