Content update build settings

To publish content updates, your application must already use a remote catalog and host its remote content on an accessible server. Refer to Enabling remote distribution for information about setting up content hosting and distribution.

You should also consider how to set each group's Update Restriction settings. These settings determine how the Check for Content Update Restriction tool treats changed content in your groups. Choose appropriate settings to help minimize the download size of your content updates.

For more information, refer to Group Update Restriction settings.

Update a Previous Build setting

The Addressable Asset Settings also has a section for updating a previous build:

Setting	Description
Check For Update Issues	Informs the system on whether to run the Check For Content Update Restrictions check automatically, and how to handle any issues the system detects.
Content State Build Path	This location serves two purposes: - Indicates where new Content Builds put the previous state file. - This is the location that the Update a Previous Build process attempts to pull the previous state file from automatically.

The Content State Build Path can be a remote location, if you want to have a shared previous state file on a server. The system handles remote locations for the previous state file differently:

• New content builds place the previous state file to the ContentUpdateScript.PreviousContentStateFileCachePath, which is Library/com.unity.addressables/AddressablesBinFileDownload/ by default.
• Update a Previous Build downloads the remote previous state file to ContentUpdateScript.PreviousContentStateFileCachePath and then reads the file like normal. If the file doesn't exist at the remote location, but one has already been placed in the cache path, the system loads the local file.

Group Update Restriction settings

For each group in your project, the Update Restriction schema determines how a content update handles the group and its assets as follows:

• Prevent Updates: When enabled, the system treats assets in that group as static content that you expect to update infrequently, if at all. Use this setting for all local content.

Choose the setting based on the content type in a group and how often you expect to update that content between full player builds of your application.

You can change content in a group no matter which setting you choose. The difference is how the Check for Content Update Restrictions and Update Previous Build tools treat the assets in the group and how the installed applications access the updated content.

Important

Don't change the Update Restriction setting of a group unless you are performing a full build. If you change your group settings before a content update, the Addressables system can't generate the correct changes needed for the update build.

Prevent Updates Enabled (static content)

When you enable Prevent Updates, the Check for Content Update Restrictions tool moves any changed assets to a new group, which is set to build and load from your remote paths. This is the same check that can be automatically integrated with Updating a Previous Build. Regardless of if you manually run the tool, or let Update a Previous Build handle the check automatically, the content update sets up the remote catalog so that the changed assets are accessed from the new bundles, but the unchanged assets are still accessed from the original bundles.

Note

Although the update build produces versions of the original bundles without the changed assets, installed applications don't download these bundles unless the locally cached version is deleted for some reason.

Organize content that you don't expect to update often into groups with the Prevent Updates property enabled. You can safely set up these groups to produce fewer, larger bundles because your users usually won't need to download these bundles more than once.

Enable the Prevent Updates property for any groups that you intend to load from the local load path and for any groups that produce large, remote bundles. This only requires your users to download changed assets when assets in the group change.

Prevent Updates Disabled (dynamic content)

When a group doesn't have Prevent Updates enabled, then a content update rebuilds the entire bundle if any assets inside the group have changed. The Update a Previous Build script sets up the catalog so that installed applications load all assets in the group from the new bundles.

Organize content you expect to change often into groups with Prevent Updates disabled. The Addressables system republishes all the assets in these groups when any single asset changes. To minimize the number of assets that need republishing, set up these groups to produce smaller bundles containing fewer assets.

Unique Bundle IDs setting

If you want to update content at runtime rather than at application startup, use the Unique Bundle IDs setting. Enabling this setting can make it easier to load updated AssetBundles in the middle of an application session, but can make builds slower and updates larger.

With this setting enabled, you can load a changed version of an AssetBundle while the original bundle is still in memory. Building your AssetBundles with unique internal IDs makes it easier to update content at runtime without creating AssetBundle ID conflicts.

However, when enabled, any AssetBundles containing assets that reference a changed asset must also be rebuilt. More bundles must be updated for a content update and all builds are slower.

You typically only need to use unique bundle IDs when you update content catalogs after the Addressable system has already initialized and you have started loading assets.

You can avoid AssetBundle loading conflicts and the need to enable unique IDs using one of the following methods:

• Update the content catalog as part of Addressables initialization. By default, Addressables checks for a new catalog at initialization as long as you don't enable the Only update catalogs manually option in Addressable Asset settings. Choosing this method does preclude updating your application content in mid-session.
• Unload all remote AssetBundles before updating the content catalog. Unloading all your remote bundles and assets also avoids bundle name conflicts, but could interrupt your user's session while they wait for the new content to load.