Shipping Incremental Unity Patches with Addressables Content Update Restriction

Patch Without Rebuilding the Whole Game

Your live mobile game is already on store shelves. A player on version 1.0 needs a corrected texture and a new event banner, but pushing a full binary update means another store review cycle and a 150 MB re-download. The useful takeaway is that Unity Addressables can ship incremental content patches through its Content Update Restriction (CUR) workflow: mark stable asset groups as immutable, build an update catalog, and ask players to download only the bundles that actually changed.

Group Mutability and the Update Catalog

Addressables builds assets into AssetBundles with deterministic hashes. Each group can be marked "Cannot Change Post Release." When you enable this for a group, Unity treats its contents as locked for live patching. Groups left mutable can still change between updates. The build process produces a catalog.json that maps addresses to bundle hashes. A client with an old catalog requests bundles by hash; the server returns only bundles whose hashes differ from what the client already holds.

Group setting	Post-release behavior	Best for
Cannot Change Post Release	Locked; changes require a new app build or coordinated catalog update	Core textures, levels, shared UI
Mutable (default)	Can be updated through a content patch	Weekly events, promotional banners, live-ops content

Worked Example: Patch a Single Texture

Configure two groups in the Addressables Groups window:

• Core_Assets — Cannot Change Post Release enabled; contains ui_main_texture.
• LiveOps — mutable; contains event_banner.

To ship a texture fix, replace the source asset in Core_Assets, open Window > Asset Management > Addressables > Groups, select Build > Build Update, and publish the new catalog.json plus changed bundle files to your CDN. The client keeps its existing catalog until the app signals a content update, then downloads only the bundle with the new hash. Assets referenced by the old bundle remain valid until the new bundle is loaded and the old handle is released.

Limitation: Catalog Drift Breaks Loads Silently

CUR does not protect you from a mismatched catalog. If a player holds an old catalog and the server serves new bundles without a matching catalog update, Addressables can fail to resolve keys, surfacing as missing assets or load failures rather than an obvious version error. Enforce catalog versioning in your backend, require app updates for breaking changes, and run the Addressables Analyze window before publishing to catch duplicate assets and oversized bundles.

Check the Result

After publishing a patch, open the Unity Addressables Analyze window and run "Check Bundle Sizes" and "Check Duplicate Bundle Dependencies." Confirm the new catalog lists only the expected changed bundles. In the client build, watch the Network profiler during the update: only the delta bundles should transfer, and bundle reference counts should return to zero after you call Addressables.Release on each AsyncOperationHandle.

Use CUR for live-ops content that changes frequently, but treat core game data as immutable until you are ready to ship a full client update. Pair every async load with a matching release, version your catalogs rigorously, and test patch installs on a device with an older catalog before you promote the build to production.