Smart Addresser: rule-driven addresses and labels for Unity Addressables

The problem is that Unity addresses are assigned by dragging

Every Unity team that adopts the Addressable Asset System eventually hits the same wall. Addresses are registered by dragging assets into the Addressables Group Window, one by one, and the README of this project states plainly that in reality it is difficult to manually register all assets. Smart Addresser exists to automate that task. The intended users are game developers at a studio where asset counts make manual addressing a chore, and the mechanism is a rule set rather than a script: you can assign addresses to all Prefabs in a specified folder, to all assets in a folder named Addressables, or to all assets whose path matches a regular expression you write. Rules are authored in a GUI tool, so the address scheme becomes something a team can review in one window instead of something encoded in thousands of inspector fields.

Version rules are what separate this from a build script

Addressing is the feature most tools stop at. Smart Addresser adds a version management feature whose purpose is to exclude pre-release assets from a build by setting the version number of an asset. The documentation has a dedicated versioning specification, a page on applying a specified version range, a page on how versioning interacts with asset dependencies, and a page on using your own version range expression, which tells you the version model is configurable rather than fixed. That last point is the one to read before designing around it. Version rules and address rules are separate concepts in this tool, and a version range expression decides what counts as a pre-release asset. In a live service game where content is patched monthly, this is the part that determines whether a half-finished asset ends up in a client build.

Installing through the Package Manager with a git URL

Smart Addresser is a Unity package, and the README requires Unity 2020.3 or higher with Addressables installed. Installation goes through the Package Manager: open it from Window > Package Manager, use the plus button, and choose to add a package from a git URL. The URL to enter is `https://github.com/CyberAgentGameEntertainment/SmartAddresser.git?path=/Assets/SmartAddresser`.

The path query points the Package Manager at the package folder inside the repository, which is the part that is easy to get wrong when copying it. The README also gives the equivalent manifest edit for projects where you would rather not click through the editor:

{
    "dependencies": {
      "jp.co.cyberagent.smartaddresser": "https://github.com/CyberAgentGameEntertainment/SmartAddresser.git?path=/Assets/SmartAddresser"
    }
}

The package name is `jp.co.cyberagent.smartaddresser`. To pin a target version you append a fragment to the same URL, for example the same git path with `#1.0.0` at the end. If you leave the version unspecified, the README says the version can be updated by editing the hash of the library in the package-lock.json file, which is the pattern the resolved entry shows.

The layout rules live in a LayoutRuleData asset

The rules themselves are stored in the project as an asset, and the documentation names that asset type. You create it before writing any rules, and the sections for creating address rules and label rules follow it. The tool then provides a Layout Viewer for checking and validating the actual addresses, labels, and versions that the rules assign, which is a separate concern from applying them. The rule model is described as a set of filters and providers: an Asset Filter of an Asset Group decides which assets a rule considers, and Address, Label, and Version providers decide what each matching asset receives. The README also documents creating your own Asset Filters and Providers, so the extension point is the rule model itself rather than a scripting hook bolted on the side. Two things follow from this design. A rule set is reviewable data, which is what makes it usable in CI. And a project can hold more than one LayoutRuleData asset, with the documentation describing how to manage several of them and how validation behaves across them.

Applying rules from the GUI, from CI, or from your own editor script

There are three ways to push rules into the Addressables Asset System. From the Layout Rule Editor you can apply directly, and you can configure rules to be applied automatically, so the addresses stay correct as assets move. From CI you use the CLI, which the README presents as a way to incorporate addressing and validation into a CI/CD process, and the CLI section covers setting a version expression, detecting corrupted layout rules, and applying layout rules to the Addressables Asset System. From your own editor code, the scripting section covers editing layout rule data programmatically and running validation and apply. The corruption detection deserves attention: layout rule data is a serialized asset that can be damaged, and the tool has explicit tooling for spotting that, which tells you the maintainers expect the rule file to be a fragile point in the pipeline rather than an inert configuration.

Asset dependencies decide whether a version range actually excludes an asset

One documentation page is titled about versioning and asset dependencies, and it is the section most likely to change how you plan a release. An asset can be pulled into a build even when the version rules say it should be excluded, because something else that is included depends on it. In other words, the version range expression is not the last word on what ships. For a team that treats excluded pre-release content as a defect risk, that distinction between an asset being excluded and an asset being reachable is the difference between a rule that works and a rule that appears to work. The same caution applies to addresses and labels: rules assign values to matching assets, and the dependency graph decides what those assets drag into the final build.

A young package with a recent release history

The repository is MIT licensed, with the license file named LICENSE.md, and it ships a Japanese README alongside the English one. Releases are recent but the version numbers are still low: 1.0.10 on 2025-06-09, 1.1.0 on 2025-07-03, and 1.2.0 on 2026-06-19, with the last push also on 2026-06-19. The version numbers are still in the 1.x line, so a studio should expect to read the changelog before a major Unity upgrade. The repository layout is a full Unity project rather than a library alone, with `Assets`, `Packages`, `ProjectSettings`, and a `Documentation` folder, so it can be opened to see the tool in context. If your team wants to look before installing, opening the repository in Unity is more informative than reading the README, because the rule model is easier to understand from an example project than from a description.

Editorial conclusion

Smart Addresser suits Unity teams with more assets than anyone wants to drag into the Addressables Groups window by hand, especially when the folder layout already implies the address and when releases need pre-release assets excluded from a build. It is the wrong tool for a small project where a handful of addresses costs nothing to manage manually, since the rule authoring, the version specification, and the dependency rules are all real work to set up. Before adopting it, decide whether your address scheme can be expressed as folder and path rules, read the section on versioning and asset dependencies, and confirm the team is willing to let a tool own the address and label layout, because applying rules overwrites what those rules produce.

Frequently asked questions

Official sources

1. CyberAgentGameEntertainment/SmartAddresser on GitHub
2. Issues
3. License: MIT
4. README
5. Releases