The Hidden Reason Your Unity Build Is Bigger Than It Should Be (Addressables Duplicate Dependencies)

Tim — Thu, 02 Jul 2026 09:22:21 +0000

After 17 years of shipping Unity projects, I can tell you where the mystery megabytes in your build usually hide: the same assets are being packed into more than one bundle, silently. Addressables does this by design, and it's one of the most common — and most invisible — sources of wasted space in a shipped game.

This post covers why duplication happens, how to find and fix it with Unity's built-in Analyze tool, and the false-positive trap that makes the automatic fix do the wrong thing if you're not careful. (That last part bit me hard, which is half the reason this post exists.)

Why Addressables duplicates assets

Duplication comes from implicit dependencies. When you mark an asset as Addressable, you make it explicit. But anything that asset references — materials, textures, meshes, shaders — comes along implicitly, even if you never added it to a group yourself.

The problem starts when two explicit Addressables in different groups share the same implicit dependency. The classic example: two prefabs in two different groups both reference the same material. That material — and everything it depends on — gets pulled into both bundles.

The cost shows up twice:

On disk: the dependency is stored once per bundle, inflating your total download/build size.
In memory at runtime: if both bundles are loaded, you get two separate copies of the asset, each with its own instance identity. This is worse than just wasted bytes — if you mutate one copy's state at runtime, the other copy never sees the change, because they're no longer the same object. That's a genuinely nasty class of bug to track down.

The same mechanism applies to plain AssetBundles too: if two bundles share an implicit dependency that isn't explicitly assigned to a bundle, Unity duplicates it into both.

How to find duplicates: the Analyze tool

Unity ships a built-in detector. Open:

Window → Asset Management → Addressables → Analyze

Run the rule Check Duplicate Bundle Dependencies. It scans every group with a BundledAssetGroupSchema, projects the bundle layout, and reports any asset that would end up in more than one bundle. (The related Bundle Layout Preview rule is useful context — it shows you the full projected layout.)

Check Duplicate Bundle Dependencies is a fixable rule, meaning Unity can attempt an automatic resolution — but read the trap section below before you trust it.

How to fix it

Three legitimate fixes, in rough order of control:

1. Make the shared asset Addressable yourself

The cleanest fix. Mark the shared dependency (the material, in our example) as Addressable and assign it to a group. Now it lives in exactly one bundle, and every bundle that references it simply loads that bundle as a dependency. One copy, on disk and in memory.

2. Run the automatic fix

If the rule finds issues, you can run its Fix operation. Unity creates a new Addressable group and moves all the shared dependencies into it. Fast, but blunt.

3. Group prefabs that share dependencies together

If two prefabs always load together anyway, just put them in the same group. They'll share the dependency inside one bundle, no extraction needed.

⚠️ The false-positive trap (read this before you click Fix)

The automatic fix is not always right, and two cases trip it up constantly:

Multi-object assets (e.g. an FBX with many meshes)

If a single asset contains multiple objects, different groups can legitimately pull in different parts of it without actually duplicating anything. The textbook case is an FBX with several meshes: mesh A in GroupA, mesh B in GroupB. The Analyze rule sees the shared FBX and reports it as duplicated — but nothing is actually duplicated. If you run the automatic Fix, Unity yanks the whole FBX out into its own group, which can make your layout worse, not better.

SpriteAtlases

Addressables handles SpriteAtlases differently. If an atlas is marked Addressable in its own bundle, the atlas texture lives only there and other bundles reference it — no duplication. But if the atlas is not Addressable (or doesn't have Include in Build enabled), each sprite that ships can carry its own copy of the pixel data, and the same sprite in multiple bundles duplicates that data. The fix is the same principle as #1: mark the sprites/atlas Addressable and put them in a dedicated group.

The runtime cost of over-extracting

Even when extraction is correct, it isn't free. Once a dependency lives in its own bundle, that bundle becomes a load-time dependency: it must be loaded whenever you load anything that references it — even if none of its assets are used yet. Loading a bundle has its own runtime cost. For small, always-co-loaded dependencies, packing them together is often better than splitting every one into its own bundle. Deduplication is a tradeoff, not a free win.

A separate case: Resources-folder duplication

There's a related rule, Check Resources to Addressable Duplicate Dependencies, that flags assets duplicated between your Addressables build and the Resources/ folder — meaning the data ships in both the player build and the Addressables data. Unlike bundle duplication, this rule is informational only: there's no safe automatic action. The usual manual fix is to move the asset out of Resources/ and make it Addressable instead.

Verifying the fix

After fixing, re-run Check Duplicate Bundle Dependencies — it should come back clean for the cases you intended to resolve. Then rebuild and check the Editor Log (Console → top-right dropdown → Open Editor Log) for the per-asset size breakdown, or use the Build Layout Report, to confirm the duplicated bytes are actually gone.

The tool I ended up building

Hunting duplicates by eye — and knowing which reports are real versus the multi-object false positives above — is exactly the kind of tedious, high-stakes work that's easy to get wrong. I got tired of doing it manually, so I built PerfLint for Unity: it scans your project locally (nothing is ever uploaded — zero telemetry) and flags assets duplicated across Addressable groups, showing each duplicate's memory cost and where it's referenced. It's deliberately conservative: it won't push you to auto-extract something that only looks duplicated.

The scan and the shareable health report are free. If you run it on your project, I'd genuinely love to hear what it found — or missed. That feedback is worth more to me than anything else at this stage.

Questions about your specific Addressables layout? Drop a comment — happy to look at Analyze output or Build Layout Reports.

DEV Community: Tim