Background Assets Directory Collision

Question

StonedStudio OP

Created 5h

Replies 1

Boosts 0

Participants 2

Hello,

I'm trying to use multiple Background Assets Packs to host map tiles.

This is problematic for a few reasons.

MKTileOverlay requires a method that returns a URL.
AssetPackManager.shared.url() throws, but it's unrelated to the url. It will return a URL even if it points to nothing.
There's no name-spacing. Everything appears to be flattened. (See Error below)
Simultaneously, this also is not the case as the documentation states: if there’s a path collision across multiple asset packs, then it’s undefined from which asset pack an individual file will be resolved.
AssetPackManager.shared.url() doesn't have an optional parameter to explicitly declare the asset pack you want to access, like AssetPackManager.shared.contents(at: FilePath) does

For example, I have multiple different tiles I'm trying to overlay for z: 10, x: 239, and y: 414.

Foo/10/239/414.png
Bar/10/239/414.png

And even when explicitly stating the fold directory, it appears that the assets are flattened down. As I'm receiving this error.

The URL for “Foo/10/239/414.png” couldn’t be retrieved: “414.png” couldn’t be copied to “239” because an item with the same name already exists.

Answered by Frameworks Engineer in 862176022

The system effectively merges all of your asset packs into a single directory hierarchy. You can think of it as your app’s single, shared asset-pack namespace. The system expects that every individual file have a relative path from the root of that shared namespace that’s unique across all of your app’s asset packs (though not necessarily across multiple apps). An asset pack’s ID is not part of the unique path, but every other path component is. In your case, Foo/10/239/414.png and Bar/10/239/414.png are distinct paths that shouldn’t collide.

You didn’t say in your post, but I suspect that you’re testing your app on OS 26, not OS 26.1. There’s a known issue with AssetPackManager.url(for:) in OS 26 that we fixed in OS 26.1 beta. A workaround on OS 26 is to request the URL for the path to one of the containing (sub)directories rather than to the file itself. You can then manually construct the final URL to the file by appending the necessary path components to the returned directory URL.

If you’re indeed testing on OS 26, then please update to OS 26.1 beta and retest. If it still doesn’t work or if you’re already testing on OS 26.1, then please file a feedback report in Feedback Assistant and reply to this thread with the feedback ID so that we can investigate the problem and follow up with you. Thanks!

Boost

Answer 1

Frameworks Engineer OP

Apple

3h

Recommended

The system effectively merges all of your asset packs into a single directory hierarchy. You can think of it as your app’s single, shared asset-pack namespace. The system expects that every individual file have a relative path from the root of that shared namespace that’s unique across all of your app’s asset packs (though not necessarily across multiple apps). An asset pack’s ID is not part of the unique path, but every other path component is. In your case, Foo/10/239/414.png and Bar/10/239/414.png are distinct paths that shouldn’t collide.

You didn’t say in your post, but I suspect that you’re testing your app on OS 26, not OS 26.1. There’s a known issue with AssetPackManager.url(for:) in OS 26 that we fixed in OS 26.1 beta. A workaround on OS 26 is to request the URL for the path to one of the containing (sub)directories rather than to the file itself. You can then manually construct the final URL to the file by appending the necessary path components to the returned directory URL.

If you’re indeed testing on OS 26, then please update to OS 26.1 beta and retest. If it still doesn’t work or if you’re already testing on OS 26.1, then please file a feedback report in Feedback Assistant and reply to this thread with the feedback ID so that we can investigate the problem and follow up with you. Thanks!

0