iOS do app slicing so that non-iPad may get lower resolution texture. Previously in Unity this mechanism is heavily relying on adding a tag on the (old) asset bundle system then setup in Player Settings > Variant Map For App Slicing
Now that Addressables system make asset bundle too and pack together with the app, what is the recommended way to utilize app slicing now? Any newer ways going forward?
My idea use case would be :
I have some textures I made into a SpriteAtlas. My atlas has a variant with smaller scale.
2 atlases are in the separated Addressable group. Both has the same addressable key for load. The original separated textures are not in any of the addressable group.
When building to Xcode they would be both in the Xcode project’s output side of StreamingAssets/com.unity.addressables, and then both uploaded to the store. Later when player download the game they would only get one Addressable bundle according to their device.
In the game I use Addressables.LoadAsset(key) with the same key. Because only one bundle comes with the app thining it would load the appropriate one.
The onto Android, I am also wondering how this would bridge to Android’s new App Bundle / Dynamic Delivery.
AAB works by assembling many smaller split APK into one large app. Ideally I would like each of the Addressables group to be its own split APK which player will get depending on device’s resolution via the new App Bundle support.
You can see it is able to split up by density (hdpi, mdpi, ldpi, etc.) Looks like the split was automatic based on res/ folder’s qualifier (App resources overview | Android Developers)
But Addressables output (StreamingAssets’s content) was put in main/assets/com.unity.addressables/... and not main/res. I believe it is not possible for the bundle builder to split anything in the main/assets/. It would be great if addressable can utilize this too. There is main/assets/raw folder support which could be appropriate for the bundle to be in.
Thank you for reaching out. All of the things you are describing can be done by extending the addressables system with custom providers, and in some instances, a custom build script. Long term, we definitely don’t want users to have to create custom systems to handle this, but for now you must. Apple ODR support is probably one of the first one’s we’ll tackle, but all of it is on the list.
@unity_bill since it’s already 4 months from your replay, I’m wondering how far is Apple ODR addressable builder and provider?
We’re working with addressable and we want to put it together with Apple ODR so I’m wondering if it’s better to write our own build and provider script or are you already finalizing it?
@unity_bill do you have a timeframe for when Addressables will be out of preview? Or, even better, when do you expect to have ODR supported out of the box?
Not much of one. The platform team is actively working on improved support for Android App Bundle as we speak. As they work through that, we are exploring some sort of addressables integration, but when and what are fairly fuzzy.
If you set up your AAB as install-time or fast-follow, then addressables integration is fairly straightforward as all the content should be downloaded by the time the app is running. If you want it to be on-demand, then you’d need a custom provider that asks Google for the content instead of asking a URL via UnityWebRequest. There’s a lot of other things going on in this sample, but the sync addressables sample shows how to use custom providers: https://github.com/Unity-Technologies/Addressables-Sample/tree/master/Advanced/Sync%20Addressables
@unity_bill any updates? Any sample project we could look at for integration between addressables and apple/android ODR without having to use custom providers?
The “app thinning” documentation still guides you through the classic asset bundle approach, could we at least get a variant of that page using addressables?