Unity 6.6 retires AssetBundles: Slime Rancher 2's incremental build drops from 32 minutes to three
Unity has shipped content directories in version 6.6 — a new way of packaging and loading content that the engine's developers openly call a replacement for AssetBundles. The key difference is that the runtime now addresses, loads and unloads individual artifacts — a specific mesh or texture, for example — rather than a whole bundle. Bundle layout, for which teams spent years devising grouping strategies, stops being a design decision.
Unity cites numbers from a real project: Slime Rancher 2, ported from Addressables to content directories. The incremental build dropped from 32 minutes 16 seconds to 3 minutes 4 seconds, the clean build from 58 minutes 6 seconds to 37 minutes 13 seconds. The game build slimmed down from 4 GB to 2.88 GB, and loading sped up from 45 to 30 seconds — by roughly a third. The measurements were taken in Unity 6.6 Beta (6000.6.0b10) on a MacBook Pro with an M5 Max.
Why the bundle as a unit of loading stopped being good enough
An AssetBundle is an indivisible unit of distribution, storage and loading. Dependencies are tracked at the bundle level, and the bundle has to be loaded and unloaded as a whole. Hence all the attendant work: manually laying assets out into groups, tracking dependency chains, fighting the duplication of shared resources across bundles.
Content directories are built differently. Unity uses a content-addressable storage scheme — the same idea that underpins git: every content file is named and addressed by a hash of its own contents. Deduplication turns from a developer's chore into a property of the format. Artifacts, however, reference one another not by hash but by stable identifiers — otherwise editing a single file would cascade hash changes through the entire chain; the mapping between identifiers and hashes is kept in the build manifest.
What goes into the build is now defined not by marking every asset, but by root assets — ordinary ScriptableObjects. Dependencies are pulled in automatically and tracked per individual asset rather than per bundle. The code gains a Loadable<T>
type — an engine-level loadable reference: you declare a field such as Loadable<Mesh> bodyMesh and then call bodyMesh.Load(); individual assets can be loaded and unloaded synchronously or asynchronously, via async/await. Objects referenced by a Loadable end up in the build but are not loaded into memory until they are requested. Loading itself is fully asynchronous in both reading and deserialization, using platform async APIs; underneath it lies the content file format that appeared in DOTS back in 2022.
What to do if you are already on Addressables
Unity has not broken existing projects. Content directories are compatible with the Addressables package, which remains the interface for organizing content, and existing projects can be converted to the new backend: Slime Rancher 2 was moved over without a single code change. The conversion procedure and a comparison of the options are described in the Addressables documentation.
What changes is the whole approach to what needs marking at all. Unity automatically includes assets referenced by a Loadable in the build and strips duplicates itself, so separate bundles for shared dependencies are no longer needed. The documentation recommends creating a single root asset for the entire project, and if the code loads many assets by string keys — using a ScriptableObject as an asset list instead of many root assets.
Limitations worth knowing about up front
In 6.6 content directories only work with local content — the content that ships with the player. Remote delivery and post-install downloads still require AssetBundles or a mechanism of your own. Unity promises full granular over-the-air delivery in the Unity 7 generation, with details due in 2027.
- the BuildUsage
A content directory is registered at runtime, after which its assets become available; scenes are also hooked up through loadable references. The details are described in the official Unity documentation on content directories.
Why Unity needed to change the foundation right now
Content directories look like a change of footing for the entire content stack rather than a standalone 6.6 feature. The AssetBundle's limitations show through in the design of Addressables as well: a noticeable share of the work with that package came down to compensating for the bundle's indivisibility. Once the base unit becomes atomic, some of the familiar tasks of tech artists and build engineers — laying assets out into groups, hunting for duplicates, manually managing dependency chains — lose their meaning on their own.
The direction matches the industry's general movement toward content-addressable storage and incremental builds: the same principle has long been at work in version control systems and build caches, and on large projects it pays off first and foremost in iteration time. The tenfold reduction of the incremental build in the Slime Rancher 2 example hits not so much the final build as the daily edit-and-check cycle — and that is where teams spend their working hours.
Addressables, meanwhile, is not going anywhere: judging by the way the migration is arranged, the package remains the user-facing interface, while content directories take their place underneath it. Given that Unity ties remote delivery to the new foundation in the Unity 7 generation, moving to this backend will probably become a prerequisite for granular content downloads over time, and projects that live on manual bundle layout today would do well to look into converting ahead of time.
Why were AssetBundles retired only now: pressure from Godot and Unreal, the accumulated pain of Addressables, a change of course after John Riccitiello's departure?