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.