Three decisions to make before Addressables

Addressables is a promise to load by need

Addressables lets a project locate assets by an address instead of a physical path. You organise addresses and groups in the editor, build content, then request a meaningful key from code.

Do not mark every asset addressable by default. Start with content that is not needed at launch or is likely to be swapped or updated.

Make three decisions before a build

An address should be stable and readable; a group should reflect what is loaded, shipped, or updated together.

1. Define address rules such as ui/popup-settings or characters/player/default.
2. Group assets only when they share a genuine deployment reason.
3. Separate launch-critical assets from deferred content.
4. Agree whether content build output is source-controlled or treated as generated output.

A common lifecycle mistake

Loading by address without tracking release makes memory behaviour difficult to reason about. Releasing too early can break objects still on screen. Keep loading and release responsibilities visible within the same feature.

Validate one local group—build, load, release—before adding remote delivery to the mix.