Your Unity project builds successfully, but each new build is larger than the last even though you did not add big assets or features. The first build might be 80 MB; a few builds later it is 120 MB, then 150 MB. This can be frustrating and lead to unnecessary app size, longer uploads, and store warnings.

This guide explains why build size increases after each build and gives you step-by-step fixes so your output size stays stable.

1. Why Build Size Grows With Each Build

Common causes:

• Incremental build cache – Unity (and platform SDKs) keep intermediate files and caches to speed up the next build. Sometimes old or duplicate data is not pruned and gets bundled.
• Library and Temp bloat – Corrupted or stale data under Library/ or in the build pipeline can cause the same assets or symbols to be included multiple times or in a larger form.
• Strip and compression settings – If stripping level is low or compression is inconsistent between builds, small changes can make the final package grow.
• Build report / debug data – Some build options embed extra diagnostics or symbols that add size and can accumulate if not cleared.
• Addressables or asset bundles – If remote or local catalogs are cached and not cleaned, old asset versions can be included alongside new ones.

Fixing this usually involves cleaning caches, resetting the build pipeline, and locking in consistent build settings.

2. Fix 1: Clean Build (Full Rebuild)

A clean build forces Unity to regenerate everything from scratch and often resets the growing size.

Steps

1. Close Unity completely.
2. Delete the Library folder in your project root (not the whole project).
   • On Windows: YourProject/Library
   • On macOS: YourProject/Library
   • This folder is recreated when you reopen the project; allow Unity to reimport (can take several minutes).
3. Reopen the project in Unity and wait for the import to finish.
4. Build again (same platform and configuration as before).

Verification: Compare the new build size to the previous one. If the new build is smaller or back to a baseline you expect, the growth was likely due to incremental/cache bloat. If size is still large but stable on the next few builds, you have reset the pipeline.

Note: Do not delete Assets, Packages (except for local packages you intend to re-add), or ProjectSettings. Only remove Library (and optionally Temp and obj if present).

3. Fix 2: Clear Platform-Specific Caches

Each platform has its own caches that can cause size to grow over multiple builds.

Android (Gradle)

1. In Unity, go to Edit → Preferences (or Unity → Settings on macOS).
2. Open External Tools.
3. Note the Android SDK and NDK paths.
4. Close Unity.
5. Delete the Gradle cache used by Unity:
   • Windows: C:\Users\<You>\.gradle\caches (or the path shown in External Tools).
   • macOS: ~/.gradle/caches.
   • You can delete the whole caches folder; Gradle will recreate it.
6. Optionally delete the build output folder Unity uses for Android (e.g. YourProject/Build/Android or the path in Build Settings after a build).
7. Reopen Unity and build again.

iOS (Xcode)

1. After a Unity build, open the generated Xcode project (e.g. from Build/iOS).
2. In Xcode: Product → Clean Build Folder (Shift+Cmd+K).
3. Delete DerivedData for this project if you know its path, or use Xcode → Settings → Locations → Derived Data and delete the folder for your app.
4. Build from Xcode (or trigger from Unity if you use that flow).

General (Temp and obj)

1. Close Unity.
2. In your project root, delete:
   • Temp (if it exists)
   • obj (if it exists)
3. Reopen the project and build again.

4. Fix 3: Consistent Build and Player Settings

So that every build uses the same rules (and does not accidentally re-enable something that adds size), lock in these settings.

Strip and compression

1. Edit → Project Settings → Player.
2. Under Other Settings:
   • Managed Stripping Level: Set to Medium or High (High can reduce size further; test that your game still works).
   • Script Compilation: Use a single target API level when possible to avoid extra stubs.
3. Under Publishing Settings (or platform-specific tab):
   • Strip Engine Code: Enabled if available.
   • Compression: Prefer LZ4 or LZMA depending on your platform (LZMA is usually smaller; LZ4 is faster to load).

Build options

1. File → Build Settings.
2. Development Build: Uncheck for release builds (development builds are larger and can grow more between builds).
3. Autoconnect Profiler, Script Debugging: Uncheck for release.
4. Use the same Scene list and platform every time when comparing build sizes.

Verification: Do two builds in a row without changing any assets. Sizes should be nearly identical (tiny differences are normal). If the second build is still noticeably larger, repeat Fix 1 and Fix 2.

5. Fix 4: Addressables and Asset Bundles

If you use Addressables or Asset Bundles, stale or duplicated content can make the overall deliverable size grow.

1. Addressables: In Window → Asset Management → Addressables → Groups:
   • Build → Clean Build → All (or clean the relevant group).
   • Then Build → New Build → Default Build Script (or your pipeline).
   • Ensure Build & Load Paths are correct so you are not bundling old catalogs or duplicates.
2. Asset Bundles: Rebuild all bundles from a clean state (e.g. after clearing Library once) and ensure the build process only references the current bundle set.

6. Prevention Tips

• Use version control and avoid committing Library, Temp, and obj. This keeps the repo small and forces a clean reimport when someone else opens the project (they get a fresh Library).
• Automate clean builds occasionally in CI: delete Library (or platform caches), then build so you always have a baseline size.
• Compare build reports: Use Unity Build Report (or a script that parses the build output) to see which assets or systems grew. That will tell you if the growth is from cache or from real new content.
• One-time baseline: After a clean build, note the build size. Use it as the reference; if size grows again later, run the clean steps again.

7. When Size Is Still Large (But Stable)

If after a clean build the size stops increasing but is still larger than you want, the issue is no longer incremental bloat but total content and settings. In that case:

• Follow our Unity Build Size Too Large - Optimization Solutions guide for texture compression, stripping, and asset usage.
• Use Addressables for large, optional content so it is not all in the initial build.

8. Summary

Verification: After applying the fixes, run two or three builds in a row without adding assets. Build size should stay stable. If it does, you have fixed the “build size increases after each build” problem.

Bookmark this page for quick reference the next time your build size creeps up. If you are also fighting long build times, see our Unity Build Fails and Performance section for more guides.