Unity build size rarely explodes overnight. It grows slowly:
- A few new 4K textures
- An uncompressed audio file
- A plugin update
- An Addressables change
- A scene pulling unintended dependencies
Then one day your APK, AAB, or build folder is 120 MB larger and no one knows why.
The real problem is not build size.
It is lack of regression control.
The Question You Should Be Asking
Most developers ask:
“What is my build size right now?”
The correct question is:
“What changed compared to my last good build?”
You cannot answer that without structured snapshots and deterministic diffs.
A Practical System for Controlling Unity Build Size
To prevent regressions, you need three things:
1️⃣ Automatic Build Snapshots
Every successful build should record:
- Build target (Android, iOS, Windows)
- Total build size
- Contributor breakdown
- Category grouping (textures, audio, meshes, shaders, plugins)
Store this as JSON so it works with version control and CI artifacts.
No snapshot = no baseline.
No baseline = no regression detection.
2️⃣ Deterministic Snapshot Comparison
When a build grows, you need:
- Total delta in bytes and percent
- Top increases
- Top decreases
- New assets
- Removed assets
- Category distribution shifts
This gives you immediate root cause visibility instead of guesswork.
Example output:
- +42 MB textures
- +18 MB new Addressables bundle
- +9 MB plugin update
- +6 MB scene dependency pull
Now you are debugging facts.
3️⃣ Enforced Size Budgets
Visibility is not enough.
You should define:
- Maximum total build size per platform
- Maximum allowed regression vs baseline
- Optional category budgets
If violated:
- Local builds warn or fail
- CI exits non-zero
- A clear report explains what exceeded and by how much
This turns build size into a hard constraint instead of a suggestion.
Why CI Enforcement Matters
Manual review fails at scale.
In real projects:
- Multiple branches ship in parallel
- Different team members commit large assets
- Nightly builds accumulate silent growth
A proper batchmode workflow should:
- Load a baseline snapshot
- Compare against current
- Evaluate budgets
- Print a human-readable summary
- Output JSON for automation
- Return a non-zero exit code on failure
That is how you prevent accidental regressions from reaching production.
Introducing Build Size Guard
I built Build Size Guard specifically for regression control, not just reporting.
It:
- Automatically records build size snapshots
- Compares any two builds
- Highlights top increases and new contributors
- Groups by folder and category
- Enforces size budgets locally and in CI
- Generates JSON and Markdown reports
- Has zero runtime footprint
It is designed for serious Unity developers shipping on Android, iOS, and Windows.
If You Care About
- APK size
- AAB size
- IPA size
- Patch size
- Store limits
- Preventing last-minute build surprises
This workflow solves that problem.
Available Now
🎮 Itch.io
https://kevindevelopment.itch.io/buildsizeguard
🧰 Unity Asset Store
https://assetstore.unity.com/packages/slug/361332
If you treat build size as a tracked metric instead of an afterthought, regressions become predictable and preventable.
Top comments (0)