A Unity project's Library folder is bigger than the project

Unity is one of the clearest examples of a general rule: the folder you should not back up is usually the folder that is largest. Every asset you import is re-encoded into a form the target platform can use, and that output is cached per project.

What is in a project folder

find ~ -type d -name Library -maxdepth 5 2>/dev/null \
  -exec test -d '{}/../Assets' ';' -print0 \
  | xargs -0 du -sh 2>/dev/null | sort -h | tail -15

The test for an Assets folder alongside is what stops this matching every other folder called Library on the Mac. Anything printed there is a Unity import cache.

What deleting Library costs

Opening the project again reimports every asset, which on a large project is minutes to hours of work you are choosing to redo. Nothing is lost: the folder is derived entirely from Assets and ProjectSettings. For a project you are not currently working on, that is a good trade. For the one you are shipping this week, it is not.

Editor versions

Each Unity editor version is several gigabytes, plus a module per build target you added. Projects are pinned to a version, so old editors accumulate the same way old SDKs do.

du -sh /Applications/Unity/Hub/Editor/* 2>/dev/null | sort -h

Remove editor versions through the Hub rather than deleting folders, so its own list stays accurate. Check which versions your projects are pinned to first, which is recorded in each project's ProjectSettings/ProjectVersion.txt.

Platform switching doubles the cache

Switching build target reimports assets for the new platform, and the cache keeps both. A project that has been built for two or three platforms carries the import cache for all of them, which is often the explanation for a Library folder several times the size of the assets.

The same shape of problem, with the same answer, shows up across every toolchain: build output grouped by project is where developer disk space usually goes.