Freeing 100GB on a Mac sounds like a big number until you see where it actually comes from. On most developer Macs that have gone a year or more without a real cleanup, 100GB is not an aggressive target — it's often sitting in five or six specific places, each contributing double digits. This is a breakdown of where those gigabytes realistically are, in the order they tend to be largest, with honest ranges rather than promises, because the exact numbers depend entirely on what you've been doing with the machine.
Docker.raw: often the single biggest item on the disk
Docker Desktop's virtual machine disk lives at ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw. It grows to fit whatever images, containers, and volumes you've pulled, and critically, it does not shrink back down when you delete those things — the file stays large even after you remove everything inside it.
Realistic recovery: 20–80GB, depending on how long Docker has been in use and whether anyone has ever pruned it. Run:
docker system prune -a --volumes
This removes anything not attached to a running container, but read the summary before confirming — it lists exactly what will go. If the file is still large afterward, Docker Desktop's Troubleshoot → Clean / Purge data does a harder reset of the VM disk itself.
Xcode's DerivedData and Archives: the silent accumulator
~/Library/Developer/Xcode/DerivedData holds build products for every project you've opened, and Xcode never cleans old entries on its own — projects you deleted months ago can still have DerivedData sitting there. ~/Library/Developer/Xcode/Archives holds every archived build you've ever made for App Store submission or ad-hoc distribution, also kept indefinitely.
Realistic recovery: 10–40GB for DerivedData, plus 5–20GB for Archives if you've shipped several app versions. Both are safe to clear — Xcode rebuilds DerivedData automatically, and Archives are only needed if you plan to re-export a specific past build (check before deleting one you might need for symbolication of an old crash report).
node_modules across every project you've ever cloned
Individually, a node_modules folder is 200MB to 2GB. The problem is that they multiply — every clone, every branch checkout into a fresh worktree, every tutorial project you tried once, each carries its own full copy if you're using npm or Yarn Classic.
Realistic recovery: 5–30GB, concentrated in whichever projects you haven't opened in months. These are always safe to delete outright; running npm install or pnpm install again rebuilds them from package-lock.json or pnpm-lock.yaml.
| Source | Typical size range | Safe to delete? |
|---|---|---|
| Docker.raw | 20–80GB | Yes, via prune or reset |
| Xcode DerivedData | 10–40GB | Yes, always rebuilds |
| Xcode Archives | 5–20GB | Check first — needed for old crash symbolication |
| node_modules (all projects) | 5–30GB | Yes, reinstalls from lockfile |
| iOS DeviceSupport | 5–20GB | Yes, re-downloads per device |
| Video / screen recordings | 5–40GB | Check first — not regenerable |
| iOS device backups | 5–30GB | Only if you don't need to restore from them |
Video and screen recordings
~/Movies and the Desktop are where screen recordings and video exports land, and video is dense enough that a handful of files can be tens of gigabytes. Unlike caches, these are not regenerable — sort by size, check what each file actually is, and move genuinely unneeded ones to Trash.
Realistic recovery: 5–40GB, highly dependent on whether you record video or screen sessions regularly.
iOS device backups you don't need anymore
Each backup Finder makes of a connected iPhone or iPad lands in ~/Library/Application Support/MobileSync/Backup/ and runs 5–15GB. It's common to find two or three from devices you've since upgraded or sold. Manage them from Finder → [device] → Manage Backups, not by deleting the folder directly, so you don't leave a stale reference behind.
Realistic recovery: 5–30GB if you've backed up more than one device over the years.
iOS DeviceSupport and simulator devices
~/Library/Developer/Xcode/iOS DeviceSupport keeps a folder per (device, iOS version) pair you've ever connected for debugging, forever, and ~/Library/Developer/CoreSimulator/Devices keeps every simulator you've created, including ones for iOS versions no longer installed.
Realistic recovery: 5–20GB combined. Both are safe — DeviceSupport re-downloads the next time you connect that device, and xcrun simctl delete unavailable clears orphaned simulators without touching ones you still use.
Adding it up honestly
None of these categories are guaranteed to be large on your specific Mac — a machine that's never run Docker won't have a Docker.raw problem, and a designer's Mac will have different video volumes than a backend developer's. But across the categories above, most developer Macs that haven't been cleaned in a year will find 100GB somewhere in this list, usually concentrated in two or three of these seven items rather than spread evenly.
Finding what's specific to your machine
The categories above are the predictable ones. The last stretch of any deep cleanup is whatever doesn't fit a checklist — a forgotten export, an old virtual machine disk, a duplicated Photos library. A visual storage map, which draws every folder as a rectangle sized by actual usage, finds these because it doesn't need to know your specific setup in advance; the largest thing on the map is the largest thing on your disk, whatever it turns out to be.
A sensible order for a 100GB target
If the goal is a specific number rather than general tidiness, work through the categories above roughly in the order listed — largest typical contributor first — and check your Available figure in Storage Settings after each one. This tells you two useful things as you go: whether you're on track to hit 100GB without touching every category, and whether a category you expected to be large (Docker, say) turns out to be small on your particular Mac, in which case you'll need to lean more heavily on the others.
Stop checking categories once you've hit your target rather than working through the full list out of habit. A 100GB goal met through Docker.raw and DerivedData alone, with node_modules and iOS backups left untouched, is a perfectly reasonable outcome — there's no requirement to exhaust every possible source just because it's on the list.
Why these numbers are ranges, not promises
The ranges given for each category are drawn from what's typical, not guaranteed — a Mac that's never run Docker Desktop has no Docker.raw file at all, and a designer who has never opened Xcode will find nothing in DerivedData. Treat this article as a map of where to look, not a receipt for exactly how much you'll recover. The only way to know your actual numbers is to check each path on your own disk, which is precisely what a proper storage scan is for.
Where VolumeLens comes in
VolumeLens recognises every category in the table above by name — Docker.raw, DerivedData, node_modules, iOS DeviceSupport, and the others — and lays them out on a map alongside whatever else is on your disk, so the predictable and the specific-to-you show up in the same view. It scans locally, never uploads anything, and its only action is Move to Trash after you've reviewed exactly what's included, so a 100GB cleanup stays a series of deliberate decisions rather than a leap of faith.