Managed Background Assets: Version Resolution & Compatibility

Hello,

We are developing a macOS app using Apple-Hosted Managed Background Assets (MBA).

Our resources are strictly coupled to specific app binary versions (e.g., App v1.0 is incompatible with Asset Pack v2.0 due to data schema and data format changes).

We plan to use Essential asset packs, but also plan to provide an in-app fallback using ensureLocalAvailability during initial launch to handle cases where background downloads fail or are delayed.

We have questions regarding the version-resolution behavior and Apple's recommended architecture for version-coupled assets.

Scenario

1. A user installs App v1.0 (which targets Asset v1.0).
2. The initial Essential download fails (e.g., network disconnect). The user opens the app without local assets.
3. Later, Asset v2.0 is released to the App Store alongside App v2.0.
4. The user on App v1.0 launches the app and calls ensureLocalAvailability.

Questions

[1] Version Resolution & Fallback Behavior

When an app has no local asset pack installed and calls:

try await AssetPackManager.shared.ensureLocalAvailability(
    of: appResources01,
    requireLatestVersion: false // or the legacy ensureLocalAvailability(of:)
)

• Does the system always fetch the latest live version in the App Store (v2.0), or is there any mechanism to retrieve the historical version compatible with App v1.0?

• Is it possible for an app to explicitly request a specific Asset Pack version rather than the currently active App Store version?

[2] Scope of shouldDownload(_:)

• Does ManagedDownloaderExtension.shouldDownload(_:) get invoked during an explicit in-app call to ensureLocalAvailability?

• Or is shouldDownload(_:) exclusively called for system-initiated background download cycles?

[3] Recommended Architecture for Version-Coupled Resources

• If an application cannot maintain backward compatibility within a single continuously versioned Asset Pack (v1 → v2 → v3), what is Apple's recommended design pattern?

  • Option A (Separate Identifiers): Define distinct Asset Pack identifiers for each incompatible app generation (e.g., AppResources-v1, AppResources-v2)?

  • Option B (Forced App Update): Use a single Asset Pack identifier and require older app versions to prompt a forced app update via the Mac App Store if assets are missing and incompatible?

  • Option C: Is there another recommended mechanism within Background Assets for managing strict asset-binary version coupling?

Thank you for your guidance!