← Blog

What “System Data” actually is on a Mac — and how much of it you can delete

· 5 min read

Open → About This Mac → Storage, and macOS shows you a bar. Apps, Documents, Photos, Messages — all sensible. Then a grey slab called System Data that on a developer's machine is routinely 80, 150, sometimes 300 GB, with no explanation and no button.

Apple's own support page says it "includes files that don't fall into the other categories." That is technically true and completely useless.

Here is what is actually in there.

System Data is a leftovers bin, not a category

macOS sorts your disk into named buckets. Anything it can't confidently label falls into System Data. That means the bar contains three very different kinds of file mixed together:

  1. Things macOS needs and rebuilds if you delete them — swap, sleep image, Spotlight indexes.
  2. Caches that regenerate on their own — and cost you a slow first launch if you remove them.
  3. Junk that nothing will ever read again — old iOS device backups, Xcode simulator runtimes for versions you dropped two years ago, build caches from a project you deleted.

The third group is usually the majority of the bar, and it is the only group worth going after.

What's in there, in rough order of size

iOS device backups

~/Library/Application Support/MobileSync/Backup/

Every device you have ever plugged in and backed up locally, kept forever. Each one is the full contents of a phone. Two old iPhones can be 60 GB on their own.

Safe to delete? Yes, per backup — but read the folder names first. If a device is gone and its data was never restored anywhere, deleting the backup deletes the last copy. This is one of the few places in System Data where the file is genuinely irreplaceable.

Xcode

Three separate piles, and they add up faster than anything else on this list:

Simulator runtimes

~/Library/Developer/CoreSimulator/

Each installed iOS runtime is 6–10 GB, and Xcode does not remove old ones when you update. Devices you created and forgot sit under Devices/ with their own disk images.

Note that these overlap with what Finder counts as "Developer" on newer macOS versions, so the same gigabytes can appear in two places in different tools. They are only on disk once.

Package manager caches

Homebrew (~/Library/Caches/Homebrew), npm, pip, Gradle, CocoaPods, Docker. Every one of them keeps downloaded artefacts indefinitely by default. All of them re-download on demand.

Docker deserves its own mention: Docker.raw is a single sparse file that grows and does not shrink when you delete images. Pruning inside Docker frees space inside the image; reclaiming it on disk takes a separate step.

Mail downloads

~/Library/Mail/ holds full local copies of messages and every attachment you have ever opened.

Do not delete this folder. For any account that isn't pure IMAP-with-server- copies, this is the mail. Use Mail's own Preferences → Accounts → "Download attachments: None" and let it clean up, or remove the account.

Swap and the sleep image

/private/var/vm/

Virtual memory paging plus a file the size of your RAM for hibernation. macOS manages both. Deleting them frees space until the next boot, then they come back the same size. Not worth touching.

Time Machine local snapshots

Even without an external drive, Time Machine keeps hourly snapshots on the internal disk. macOS thins them automatically under disk pressure, which is why "free space" sometimes climbs on its own overnight.

tmutil listlocalsnapshots / shows them. macOS will handle it.

The part nobody tells you: Finder lies about deleted files

Delete 40 GB, watch the number not move. Two reasons, both normal:

So the honest answer to "why didn't my free space change" is usually that it will, in a few hours, without you doing anything.

What not to delete, ever

Some of this is folklore that circulates in forum threads and costs people real data:

Path Why people delete it What actually happens
~/Library/Mail "It's a cache" It's your mail
~/Library/Keychains "Junk plist files" Every saved password, gone
~/Library/Mobile Documents "iCloud has a copy" It is the local iCloud Drive
~/Library/Containers/com.apple.mail Same as above Same as above
/private/var/folders "Temp files" Live per-user temp state; apps break mid-run
~/Library/Preferences "Reset settings" Every app's settings at once

The general rule: if you cannot name the thing that will recreate the file, the file is not a cache.

Doing it by hand

Nothing here needs an app. It needs an evening and care:

# See where the weight actually is, biggest first.
du -sh ~/Library/Developer/* ~/Library/Caches/* 2>/dev/null | sort -rh | head -20

# Xcode build output — always safe.
rm -rf ~/Library/Developer/Xcode/DerivedData/*

# Local snapshots currently holding blocks.
tmutil listlocalsnapshots /

Read every path before you remove it, and prefer moving things to the Trash over rm -rf so a mistake stays recoverable for a day.

Where Decruft fits

Decruft scans those locations, tells you what each one is and what recreates it, and moves what you pick to the Trash rather than deleting it outright. It refuses, in code, to touch anything in the table above — the guard is a default deny, so a path that isn't explicitly recognised as junk is never offered.

Scanning is free and needs no license. You can run it, read what it found, and go delete the files yourself in Finder if you'd rather.