How to Reduce Unity Build Size (Without Deleting the Wrong Thing)

A client once handed me a hybrid-casual game whose APK had crossed 400 MB. Their question was the one every team eventually asks: “what is even in there?” Nobody had done anything wrong, exactly. Four artists and two years had just happened to the project, one 4096 texture at a time.

We got it under 150 MB in a week, and almost none of that came from deleting assets. It came from fixing how the assets that actually ship were imported. That distinction matters, because the instinct when a build is huge is to start deleting, and deleting is both the riskiest move and usually the least effective one.

Step one: read the build report, not your gut

Unity writes a complete manifest of every build and buries it. After building, open the Editor log (~/Library/Logs/Unity/Editor.log on macOS, %LOCALAPPDATA%\Unity\Editor\Editor.log on Windows) and search for “sorted by uncompressed size”. You’ll find every asset that shipped, largest first, plus a category summary showing how the total splits between textures, audio, meshes, and code.

I’ve done this audit maybe thirty times, and the top twenty lines have explained the problem every single time. If you want the same data with a UI, the Build Report Inspector package renders it in-editor. Either way: get the list before touching anything. Teams consistently guess wrong about what’s big.

Textures pay most of the rent

In the projects I’ve audited, textures are 60 to 80 percent of build size, and the fix is almost never “fewer textures.” It’s import settings:

Max Size. A texture imported at 4096 that renders on a quarter of a phone screen is paying for pixels no one sees. Per-platform overrides exist precisely for this; most mobile UI art is perfectly happy at 1024.

Compression format. ASTC on modern mobile hardware gives you quality-per-byte that makes uncompressed formats indefensible. If you see RGBA32 in the report, someone clicked past a warning.

Crunch compression. For textures that tolerate it, crunched formats shrink the on-disk (and download) size dramatically at some decode cost.

Mipmaps on UI sprites. Sprites drawn 1:1 in screen space don’t need mip chains; turning them off recovers a third of each sprite’s size.

None of this requires touching source art, which is what makes it safe. The pixels your players see don’t change; the padding around them does.

Audio is the quiet whale

Audio hides well because a folder of .wav music doesn’t look like 80 MB. Three settings do the work: drop Vorbis quality to around 70 percent (in a blind test, on phone speakers, nobody has ever caught me doing this), set long music tracks to Streaming so they stop being decompressed into memory, and force one-shot mobile SFX to mono, which halves them outright.

The Resources misconception

Here’s the mental model that saves you from deleting the wrong thing: assets that nothing references don’t ship in your build. Unity packs the scenes in Build Settings plus everything they transitively depend on. Your folder of unused concept art costs repository space and import time, not APK megabytes.

There are two exceptions, and they’re both folders: everything in Resources ships, referenced or not, and everything in StreamingAssets ships as-is. A stale Resources folder is the classic source of mystery bloat, and it hurts twice, because Unity also builds a lookup index of the whole thing at startup. Audit it ruthlessly; most mature projects are carrying Resources content nobody has loaded in a year.

Duplicates, exact and sneaky

Big teams import the same asset more than once. Same texture, three folders, three names, three copies in the build. Exact duplicates are findable by hashing (this is tedious by hand; tooling helps, more below).

The sneakier version is Addressables: if two bundles both depend on an asset that lives in neither, each bundle gets its own copy. The Addressables Analyze window has a “Check Duplicate Bundle Dependencies” rule that finds these, and it’s worth running before every release if you ship with bundles.

Code size, briefly

For IL2CPP builds, enable Strip Engine Code and consider a higher Managed Stripping Level; on a typical mobile project that’s tens of megabytes. The tradeoff is that aggressive stripping eats reflection-dependent code, which is its own famous source of build-only bugs; I’ve written a full guide to diagnosing those if you go down this road.

Keep it from creeping back

The 400 MB project didn’t get there in a day, and one heroic audit won’t keep the next one away. The durable fix is making size visible continuously: check the category summary after each release candidate, and set an alarm threshold someone actually owns.

I ended up automating my version of this into RefSafe Pro, whose Cleaner tab runs the import-settings audit (oversized textures, decompress-on-load audio) with one-click fixes, finds exact duplicates by hash, and includes a build-weight analyzer that walks the dependency graph from your Build Settings scenes and lists the fifty heaviest assets actually shipping. It’s the Editor.log ritual, minus the ritual.

But start with the log. It’s free, it’s already on your machine, and it ends the guessing.