YooAsset: a Unity resource management system for patching, packaging and hot updates

What problem YooAsset solves, and for whom

The README frames YooAsset around shipping scenarios rather than around an API. The list of stated use cases includes an installer with no game resources at all where players download while playing, an installer that guarantees an early experience while players choose which level content to fetch, an installer kept under 300MB with the remainder downloaded before entering the game, a mostly offline game that updates when the network is available and still runs an older version when it is not, and a MOD game where player-created content is uploaded to a server and downloaded by others. There is also a question about projects with hundreds of GB of assets where every build takes a long time, answered by building in separate projects.

That list tells you the intended audience: teams building commercial Unity titles with a live-ops component. A single-player prototype with a few hundred megabytes of assets does not need any of this. A team that has to decide, per release, how much content sits in the installer and how much is fetched later does. The README also states that the system has been used by multiple products with millions of DAU, which is a claim about the author's experience rather than something a reader can check from the repository.

The design consequences show up in the feature list. Distributed builds mean the asset pipeline is expected to run across more than one Unity project. Addressable asset location means code refers to assets by a configured address rather than a full path, although the README says full-path location is the default and addressable location is opt-in. Label-based packaging means a human does not hand-maintain the mapping from assets to bundles.

Build pipelines, dependency analysis and the packaging model

YooAsset supports both the legacy built-in build pipeline and the Scriptable Build Pipeline (SBP), and the README describes switching between them as seamless. In practice this matters because SBP is where Unity exposes build hooks that let a package control how dependencies are collected. YooAsset's packaging system is described as customizable, with automatic dependency analysis aimed at zero redundancy and bundle-to-bundle dependency management based on resource objects. The claim that this naturally avoids circular dependencies between bundles is a design statement, not something the README proves; the mechanism it names is that dependencies are tracked per resource object rather than per bundle.

Packaging is driven by resource labels. The README says label-based packaging automatically classifies dependent bundles, which removes manual bookkeeping and makes it practical to produce either a zero-resource installer or a full-resource installer from the same project. Distributed builds go further: the same project can be split by content, and separate projects can be built independently. That is the answer the README gives to the hundred-gigabyte build-time question, and it is also the mechanism behind MOD support, since a MOD is effectively another content set built and delivered separately.

At runtime, the loading system is reference counted. The README presents reference counting as the basis for a safe unload strategy and for memory management, and mentions analyzers that help find potential resource leaks. Reference counting is a real constraint as much as a feature: every load must be matched by a release, and the analyzer exists precisely because mismatches are easy to introduce. Anyone adopting YooAsset should expect to treat load and release as a paired discipline in code review.

The runtime offers four modes: editor simulation, standalone, online, and WebGL. Editor simulation lets you work without building bundles at all, and the README states you can switch between modes without changing code. That is the single most useful property for day-to-day development, because it keeps the iteration loop short while still exercising the same loading code paths.

Getting the package and a first real load

The repository does not contain step-by-step install instructions in its README. What it does contain is an OpenUPM badge pointing at the package name com.tuyoogame.yooasset, and a link to the official documentation site at https://www.yooasset.com/. The package identifier below is the one the README shows; no other install command appears in the repository files.

OpenUPM packages are added by scoped registry. The registry URL and scope below are the ones the badge links to:

{
  "scopedRegistries": [
    {
      "name": "package.openupm.com",
      "url": "https://package.openupm.com",
      "scopes": ["com.tuyoogame"]
    }
  ]
}

After the registry is configured, the package is added by its name, com.tuyoogame.yooasset, either through the Package Manager window or by editing the project manifest directly. The README gives no command-line invocation, so the editor route is the one to follow.

Once installed, the next step according to the README is to pick a runtime mode. Editor simulation mode is the one to start with, because it lets you run without building any bundles. The README states that switching from editor simulation to standalone or online mode requires no code changes, so the first real exercise is to load one asset in simulation mode, confirm it resolves, then build bundles and repeat the same call in standalone mode.

Beyond this, the README does not document the initialization sequence, the manifest types, or the downloader API signatures. Those live on the tutorial site. Treat the repository as the source of the package and the site as the source of the manual.

Downloading at runtime, and where the model can bite

The loading system has a behaviour worth understanding before you design around it: when an asset is loaded and one of its dependent bundles is not present locally, YooAsset downloads that bundle from the server and then completes the load. The README calls this playing while downloading. It means a load call can block on network I/O without the caller having asked for a download, which is convenient and also a place where latency and failure handling become part of your loading path.

The downloader side is more explicit. You can create a downloader by resource label or by resource object, set a limit on concurrent files, set a retry count for failures, and set a timeout threshold. The README states that multiple downloaders running at once will not download the same file twice, and that downloaders expose progress and failure callbacks. Multi-threaded download with resume, automatic file verification, and automatic repair of corrupted files are all listed. Those are the properties you would want for a large patch on a mobile connection.

The limitations are structural rather than hidden. First, this is a system for Unity projects only; there is no non-Unity path. Second, the whole model assumes you operate a server that hosts bundles and version manifests, so a team with no backend has taken on an operational dependency. Third, the README's version management claims (fast rollback of an online version, separate channels for review, test and production builds, staged or grayscale updates) describe capabilities, not a rollback procedure; the README does not document how a rollback is actually performed, so that is something to confirm against the tutorial site before you rely on it during an incident. Fourth, reference counting means a leaked handle keeps memory alive, and the analyzer is there because that happens.

One more boundary: the README states that the 2.x line adapted the WeChat mini game and Douyin mini game platforms. The default branch is yoo3 and the current releases are 3.0.x, so mini game support is a 2.x statement. If mini game delivery is your requirement, verify the current branch's status rather than assuming the 2.x note carries forward.

YooAsset compared with Unity Addressables

The obvious comparison is Unity Addressables, which is Unity's own package for addressable asset loading, catalogs and content updates. The two overlap on the central idea: assets get an address, bundles get built, a catalog or manifest maps addresses to bundles, and content can be updated after release. If your needs stop there, Addressables is already in the Unity ecosystem and needs no third-party dependency.

The difference in approach shows up in the areas YooAsset emphasizes. YooAsset's packaging is label-driven with automatic dependency classification, and it supports building across separate Unity projects and splitting content within a project, which is the mechanism behind its MOD story. Its downloader is a first-class object you configure with concurrency limits, retry counts and timeouts, and it can be scoped by label or by resource object. Its runtime modes include an editor simulation mode that runs without building bundles. Addressables has its own equivalents for some of this, but the shape of the API and the packaging workflow differ, and YooAsset's README is written around shipping scenarios rather than around a feature matrix.

A second comparison that appears in how people search for this project is GameFramework, a Unity game framework rather than a resource system, and Xasset, another Unity asset management package. GameFramework is a broader application framework; if you already use it, the question is integration rather than replacement. Xasset occupies the same problem space as YooAsset, so the decision comes down to packaging model, downloader API and which documentation you can actually work from. YooAsset's documentation is external to the repository, which cuts both ways: the site is maintained separately from the code, so the README and the tutorial can drift apart between releases.

Maintenance, licensing and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-20. The most recent release is 3.0.6 from 2026-09-18, preceded by 3.0.5 on 2026-07-20 and 3.0.4 on 2026-07-14. That is a release cadence of roughly one to two months across the 3.0.x line, with the newest release landing two days before the most recent push. Teams on 3.0.x are therefore tracking a line that is still receiving changes.

The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. It also carries notice and attribution obligations: if you redistribute the code, the licence and notices need to travel with it. That is a statement about the licence text, not legal advice; if your legal team has questions about redistribution in a shipped game, that is a question for them.

The upgrade cost is dominated by the fact that this is a runtime dependency embedded in your loading code. Moving between 3.0.x patch releases is likely to be routine, but the README's own framing points to a larger cost across major lines: the 2.x mini game adaptation is described as a 2.x property, and the default branch is yoo3. If you are on 2.x and want the 3.x line, expect to re-verify the parts of the README you depended on, particularly platform support and version management. There is no migration guide in the repository, so the practical first step is to read the release notes for each 3.0.x version between your current one and your target.

Editorial conclusion

Adopt YooAsset if you are shipping a Unity game that needs installers without bundled assets, staged downloads, or MOD-style content, and you are willing to read the tutorial site at yooasset.com because the repository README is a feature list rather than a manual. Do not adopt it if you need a single self-contained document set, or if your project is small enough that Unity Addressables already covers your case. Verify first that the package version you install matches the branch you are reading: the default branch is yoo3 and the current release line is 3.0.6, so 2.x material about WeChat and Douyin mini games may not describe the code you are running.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. tuyoogame/YooAsset on GitHub