The number worth not hiding: 200 GB. That is how much one developer freed by going through their Mac category by category in a January 2026 writeup of using Claude to free 200 GB from a full disk. Their disk went from 98.5 percent full to 55 percent in one afternoon. Nothing exotic. They worked line by line through what macOS lumps together as System Data and reduced it the only way that actually works, by deleting specific folders they understood, not by trusting a magic button.
If you searched for how to reduce System Data on macOS safely, you have probably already tried the easy answers. You restarted. You opened the storage panel. You emptied Downloads. The gray bar did not move. This guide is the next step: shrinking System Data without breaking Xcode, without nuking caches you actually use, and without paying a subscription cleaner to do it behind your back.
Why is System Data so hard to reduce in the first place?
The Apple storage panel exists to keep customers calm, not to give developers tools. When you click Manage in About This Mac, you get a category list, a few suggestions like review iCloud documents or empty Trash automatically, and a giant gray slice labeled System Data that is not clickable. There is no drill-down, no path list, no show me what is in here button.
On a clean consumer Mac that gray slice sits around 20 GB. On a developer Mac it routinely sits at 80 to 200 GB. The difference is not macOS itself, it is everything macOS classifies under that label: caches, logs, virtual machine disk images, mail attachments, simulator runtimes, indexed search files, AI session histories, container layer data, and stale build artifacts. The storage panel cannot help with any of it, because Apple chose not to show paths.
Reducing System Data therefore comes down to finding the folders that contribute to it and deleting the right files inside them. That sounds obvious. The hard part is knowing which paths feed the gray bar, which ones rebuild themselves, and which ones contain the only copy of something you actually care about.
What contributes to System Data on a developer Mac?
Most of the size on a developer Mac comes from a short list of folders. The breakdown below is averaged from disk audits across iOS and full-stack developer machines.
| Folder | Typical size | What it stores | Safe to reduce? |
|---|---|---|---|
~/Library/Developer/Xcode/DerivedData/ |
15 to 60 GB | Xcode build cache | Yes, rebuilds on next compile |
~/Library/Developer/CoreSimulator/ |
20 to 100 GB | iOS simulator runtimes and devices | Yes, with xcrun simctl |
~/Library/Developer/Xcode/iOS DeviceSupport/ |
5 to 40 GB | Symbol files for old iPhones | Yes, redownloaded on plug-in |
~/.claude/, ~/.codex/, ~/.cursor/ |
5 to 400 GB | AI tool sessions, snapshots, logs | Yes, with audit |
~/Library/Containers/com.docker.docker/ |
20 to 100 GB | Docker.raw VM image | Yes, with docker system prune |
~/.npm/, ~/Library/pnpm/store/ |
1 to 20 GB | Package manager caches | Yes, rebuilds on next install |
/private/var/db/Spotlight-V100/ |
1 to 20 GB | Spotlight index | Yes, rebuilds on next index |
~/Library/Mail/V*/MailData/ |
1 to 30 GB | Cached attachments | Yes, server keeps originals |
| Time Machine local snapshots | 5 to 50 GB | Hourly on-disk backup snapshots | Yes, with tmutil deletelocalsnapshots |
Add the high end of each row and you reach the 180 GB of System Data reality every senior iOS dev recognizes. None of it is macOS itself. All of it can be reduced.
What's the safest order to reduce System Data on macOS?
Start with the highest size to safety ratio and work down. Each step here is reversible if you follow the move-to-Trash habit.
Step 1: Clear Time Machine local snapshots
Snapshots are the cheapest win because they are not really backups, they are local copies that macOS evicts on demand. macOS shows the disk as full while quietly holding back snapshot space for itself. Force the cleanup with one command.
# List current local snapshots
tmutil listlocalsnapshots /
# Delete every listed local snapshot
for s in $(tmutil listlocalsnapshots / | awk -F. '{print $4}'); do
sudo tmutil deletelocalsnapshots "$s"
done
This often reclaims 10 to 50 GB instantly and is safe, because your real Time Machine backup on the external drive is untouched. The snapshots are local-only copies.
Step 2: Audit Xcode DerivedData
DerivedData is the single largest reducible folder on most iOS dev Macs. The safely delete Xcode DerivedData guide covers the full reasoning. The short version:
du -sh ~/Library/Developer/Xcode/DerivedData
mv ~/Library/Developer/Xcode/DerivedData ~/.Trash/DerivedData-$(date +%s)
Quit Xcode first. The next build will be slow. Nothing else breaks.
Step 3: Run xcrun simctl on stale simulators
iOS simulator runtimes pile up across Xcode versions. A two-year-old Mac with frequent Xcode updates can carry 80 GB of simulators it does not use. The xcrun simctl delete unavailable guide walks through the safer commands and the rogue simulators that simctl cannot reach.
xcrun simctl delete unavailable
That command alone usually removes 10 to 30 GB on a developer Mac that has been through three Xcode major versions.
Step 4: Audit your AI coding tool folders
This is the new category, and the one no consumer cleaner targets. The Claude Code 472 GB postmortem documents how ~/.claude/debug and ~/Library/Caches/claude-cli-nodejs/ reached 472 GB on a single user's machine.
du -sh ~/.claude ~/.codex ~/.cursor 2>/dev/null
du -sh ~/Library/Caches/claude-cli-nodejs/ 2>/dev/null
du -sh ~/Library/Application\ Support/Cursor/ 2>/dev/null
If any of those is over 5 GB, look inside before deleting. Session history is harder to recreate than a build cache, so audit first and only remove what you understand.
Step 5: Prune Docker
Docker.raw grows even when no container is running. The fix is a small command set, with the side effect of deleting unused images and volumes. Read it carefully before running.
docker system df # see what is using space
docker system prune -a # delete unused images, networks, build cache
docker volume prune # delete unused volumes
If you have a database volume you forgot you needed, the volume prune step will remove it. Run docker volume ls first and exclude anything that still matters. The brtkwr writeup that freed 200 GB explicitly noted this:
"After the initial Docker/cache cleanup freed 150GB, going back and asking 'what else?' found another 75GB."
Two passes is normal. The first pass usually catches Docker and DerivedData. The second pass catches the AI tool folders and forgotten package manager caches.
Step 6: Clear stale package manager caches
npm cache clean --force
pnpm store prune
brew cleanup --prune=all
These are pure caches. They redownload on the next install.
Step 7: Empty Trash
This is the step everyone forgets. Move-to-Trash is reversible, but the Trash still occupies disk space until you empty it. After steps 1 through 6, the Trash on a developer Mac can be 50 GB or more. Empty it once you have verified nothing matters.
What about reset NVRAM and Safe Mode advice?
The internet is full of guides telling you to reset NVRAM, run First Aid, or boot in Safe Mode to reduce System Data. None of these reduce disk usage in any meaningful way. NVRAM holds tiny boot settings. Safe Mode flushes some caches that come back on the next boot. First Aid checks file system integrity, which is unrelated to size.
The only universal macOS cleanup that can move the gray bar is a restart, because restarting forces macOS to release purgeable cache space. On a developer Mac that recovers a few GB at most. If your System Data is 80 GB, restarting changes nothing perceptible. The disk-sized wins come from the folders in the table above, not from system rituals.
How do you reduce System Data without breaking anything?
The pattern across all seven steps is the same: audit first, delete reversibly, verify nothing broke, then empty Trash. The mistakes that make a reduce System Data session go wrong all share a shape. They are usually one of:
- A
sudo rm -rfthat removed a folder the user did not understand. - A consumer cleaner that emptied caches without showing what it touched.
- A blog post that recommended deleting
~/Library/Caches/wholesale and broke a paid app's license cache.
Reversibility is the cheapest insurance you can buy. The writeup that freed 200 GB used mv to a separate folder before final deletion, verified each app still worked, then emptied. That extra ten minutes is the difference between a calm cleanup and a panicked redownload of a database volume.
What does CleanMyDev do differently for System Data?
The trouble with System Data is that the storage panel hides the paths, and the terminal commands above require you to know which folders matter and which do not. CleanMyDev is a single SwiftUI app that sizes every category on the table above, shows last-modified dates so you can tell stale from active, and moves folders to Trash by default instead of rm -rf. No subscription, no scareware popups, no telemetry. A working Mac developer who wants to reduce System Data on macOS safely can run it instead of stitching together seven terminal commands and a backup ritual.
Reducing System Data is not magic. It is a list of folders and a habit of reversibility. If you would rather click through the list than build it from scratch, CleanMyDev for $9.99 lifetime is the version of this guide with a UI and receipts.