Unity Addressables: The Release Call Nobody Remembers Until Memory Climbs

Skipping the pitch for why Addressables beats Resources.Load — if you're here, you already know. Two failure modes worth flagging because neither throws a compile error or a runtime exception:

Missing Release(). LoadAssetAsync increments a reference count. Nothing decrements it except an explicit Addressables.Release(handle) call. No Release, no decrement, asset stays resident until the app quits — regardless of whether anything in the scene still references it. Store the handle, release it in OnDestroy or wherever that asset's logical lifetime ends. This is the single most common Addressables leak, and it's invisible until you're profiling memory on a real device and can't explain why it keeps climbing.

Destroy() vs ReleaseInstance(). For anything loaded through InstantiateAsync, calling the regular Destroy() removes the GameObject from the Hierarchy but does not touch the Addressables reference count. You need Addressables.ReleaseInstance(gameObject) specifically. Regular Destroy on an Addressables instance is a leak that looks like nothing happened, because visually, nothing did.

One Groups gotcha that isn't a leak but defeats the whole point of switching: Pack Together bundles the entire group into one file. Load a single enemy prefab from a group with 300 assets set to Pack Together, and you load all 300 assets' bundle into memory to get that one prefab. This silently recreates the exact Resources-folder problem Addressables is supposed to solve. Organize groups by when assets are used together, not by asset type.

Full setup — package install, addressing strategy, async loading pattern, and Groups/Bundle Mode config: https://digitaltoolify.blogspot.com/2026/09/how-to-use-unity-addressables-fix-build.html

Anyone running memory profiling in CI to catch Addressables leaks before they reach a build, or is this still a manual Profiler check for most people?