Apple-hosted Managed Background Assets fails on macOS 26.6.1 with -1200 / -3007

Question

Created Aug ’26

Replies 4

Boosts 0

Views 1.4k

Participants 2

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.

Answer 1

Sean_Fu OP

Aug ’26

The App is BABANE https://apps.apple.com/us/app/babane/id6795485067

Answer 2

Frameworks Engineer OP

Apple

Aug ’26

Hi, @Sean_Fu! Thanks for filing the feedback report. We’ll look into the issue on our side and follow up with you in Feedback Assistant.

Answer 3

Sean_Fu OP

4w

It still fails on macOS 26.6.2

Answer 4

Sean_Fu OP

3w

I have new evidence from BABANE 1.0.3 build 15 and a confirmed recovery procedure. Before cleanup, the TestFlight build successfully fetched and installed the Apple-hosted asset-pack manifest. macOS reported that pack-hy-mt2-ane-lut4mixed was scheduled or currently downloading, but the app received no Background Assets status callback. After 60 seconds, the app reported BA_NO_STATUS_TIMEOUT. Reset Download then used the public cancellation and per-pack removal APIs. Removal failed with “No record of the asset pack with the global ID was found.” A new availability request was subsequently accepted and scheduled, but again produced no status callback and timed out after 60 seconds. An ordinary restart had not resolved the problem previously. The issue was finally cleared by this exact sequence:

Quit BABANE.
Uninstall BABANE.
Restart the Mac before reinstalling or launching another copy.
Reinstall the same TestFlight build.
Start one normal download.

After this sequence, the same build and asset pack succeeded on the first attempt. The new debug log confirms:

All six runtime configuration checks passed.
Asset-pack lookup returned version 3.
A new system download was created.
The app received waiting, progress, and finished status updates.
The approximately 1.6 GB pack downloaded and extracted in about 67 seconds.
Model compilation completed in approximately 895 ms.
Installation completed successfully with no BABANE lifecycle error.

This new A/B result strengthens the hypothesis that the failure was caused by persistent, inconsistent Managed Background Assets state associated with the previous app installation. The upper managed database reported no removable record, while the lower system layer still treated the pack as downloading or scheduled. Please investigate whether per-pack removal or app uninstall can leave an orphaned underlying download. A supported per-app API for inspecting and clearing this state would also be helpful.

I have uploaded relavent logs to FB24301118