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.

Refer to Group Update Restriction settings for more information.

Update a Previous Build setting

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

Setting	Description
Check For Update Issues	Informs the system on whether it should run the Check For Content Update Restrictions check automatically, and how to handle issues that are detected.
Content State Build Path	This location serves two purposes: - Indicates where new Content Builds put the previous state file. - This is the location that Update a Previous Build 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 does not 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 group, and its assets, are handled in a content update as follows:

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

Choose the setting based on the content type in a group and how frequently 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, Addressables 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 in groups set to groups with Prevent Updates. 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.

Set any groups that you intend to load from the local load path to Prevent Updates. Likewise, set any groups that produce large, remote bundles sto Prevent Updates so that your users only need to download the changed assets if you do end up changing assets in these groups.

Prevent Updates Disabled (dynamic content)

When a group doesn't have Prevent Updates, then a content update rebuilds the entire bundle if any assets inside the group have changed. The Update a Previous Build script sets the catalog up 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. Because all the assets in these groups are republished when any single asset changes, you should set up these groups to produce smaller bundles containing fewer assets.

Unique Bundle IDs setting

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

Enabling the Unique Bundle IDs option allows you to 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 running into 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.