Open About This Mac → More Info → Storage Settings on any working developer's machine and you will find a fat grey bar labelled System Data. On a fresh install it is 10 GB. Six months later it is 90 GB. Nothing in that panel tells you what changed, and no submenu breaks it down. This is the single most common Mac storage question in 2026, and the honest answer is that System Data is a leftover bucket for everything macOS could not confidently sort into another category.

That answer is not very useful on its own. What follows is a map of what Apple actually puts in there, why the number moves, and how to enumerate the contents when you need to.

Why the category exists

macOS classifies storage by asking each file system item which app or framework claims it. Photos claims your Photos library. Mail claims your Mail folder. Music claims your Music library. Everything else — anything without a well-known claimant — falls into System Data. That includes files owned by the operating system, files that apps left in generic locations, and files that no one bothered to tag.

The category is not a bug; it is the residual class. But because the classifier is conservative, plenty of things you might expect to be shown separately end up here. That is why the label is so unsatisfying.

The usual contents

On a typical Mac, System Data is a mix of the following, in rough order of size:

  • Developer caches. ~/Library/Developer/Xcode/DerivedData, ~/Library/Developer/CoreSimulator/Devices, and ~/Library/Developer/Xcode/iOS DeviceSupport are the three biggest offenders on any machine that has ever launched Xcode. Each folder can be tens of gigabytes.
  • Virtual disks. Docker Desktop keeps its image at ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw. Parallels, VMware Fusion, and UTM keep their disks under ~/Library/Application Support. Any of them can be 30–100 GB while showing as System Data.
  • APFS snapshots. Time Machine takes local snapshots roughly every hour. They occupy purgeable space and are counted against your used total.
  • Mail cache and downloaded attachments. ~/Library/Mail on an IMAP-heavy account can hold years of downloaded messages and their attachments.
  • iOS and iPadOS backups. ~/Library/Application Support/MobileSync/Backup/ contains one folder per device backed up through Finder.
  • Language-specific package caches. ~/Library/Caches/Homebrew, ~/Library/Caches/pip, ~/.npm, ~/Library/pnpm/store, ~/.gradle/caches, ~/.cargo/registry, and their peers.
  • Application support data. Slack, Zoom, JetBrains, Adobe Creative Cloud, and every Electron app you have opened store per-user data under ~/Library/Application Support/<vendor>. Slack alone often crosses a gigabyte.
  • System caches and logs. /private/var/folders, /private/var/log, and various platform caches Apple keeps out of the user's Library.

None of these are broken out in the Storage panel. Every byte belongs to System Data.

How to actually enumerate it

The Storage panel will not help. The tools that will:

The du command, focused on the usual suspects, gets you a rough measurement in a couple of minutes:

du -sh ~/Library/Developer/Xcode/DerivedData \
      ~/Library/Developer/CoreSimulator/Devices \
      ~/Library/Developer/Xcode/Archives \
      ~/Library/Containers/com.docker.docker \
      ~/Library/Application\ Support/MobileSync \
      ~/Library/Mail

That output is honest — it counts the actual on-disk usage of each path — but it also stops there. It cannot tell you which subfolder inside DerivedData is the largest, or which application inside Application Support is the biggest, without more work.

The tmutil listlocalsnapshots / command lists Time Machine snapshots, which never appear in Finder or the Storage panel at all.

For everything else, a visual storage map is the only realistic option. Walk ~/Library and /Library and read the treemap. Every large slab you see is a component of System Data, drawn to scale, labelled with its path.

Why the number moves without you doing anything

Two things drive most of the churn:

Time Machine snapshots come and go on their own schedule. macOS creates one about every hour and removes it after 24 hours (longer if the destination is missing). Purgeable snapshot space shows as used until macOS decides to reclaim it.

Apps write into caches during normal use. Slack downloads emoji and preview images. Xcode indexes new projects. Chrome refills its cache after you clear it. Docker rebuilds an image that pulls fresh layers. None of these actions produce a visible file to the user, but each one adds to System Data.

If the number swings by 5 GB between two glances at Storage Settings, you are almost certainly watching a snapshot rotate or a cache repopulate.

Categories that get miscounted into System Data

Some things that logically belong elsewhere still end up here:

  • Downloaded but unindexed iCloud files.
  • Photos library subfolders that Photos did not claim (for instance, an old iPhoto library that macOS no longer knows about).
  • Application support folders for apps you have deleted; the folders remain when the .app is trashed.
  • macOS installer partitions that were not cleaned up after an upgrade.

Any of these can add tens of gigabytes without appearing under their natural category.

What to touch and what to leave

Safe to remove after review:

  • Xcode DerivedData; iOS DeviceSupport for devices you no longer own; unused simulators.
  • Homebrew downloads (brew cleanup --prune=all).
  • Package manager caches for languages you no longer write in.
  • Old iPhone backups for devices you no longer use.
  • Cached mail attachments (re-downloaded on demand).
  • Docker.raw, only if you can rebuild your images and are willing to lose local volumes.

Leave alone:

  • Anything inside /System.
  • Anything inside /private/var unless you know exactly what a specific file is for.
  • ~/Library/Keychains, ~/Library/Metadata, ~/Library/Mobile Documents.
  • Application Support folders for apps you actively use, unless the vendor documents a specific safe-to-delete file.

The line between "this is a cache" and "this is my only copy" is not always obvious. When in doubt, quit the owning app first and rename the folder before deleting; if nothing breaks in a day, remove it.

The point of the number

System Data grows because macOS gives everything a place to store its working files and then, correctly, does not audit those places. The category tells you nothing about what is in there because Apple's classifier does not know. If you want to know, you have to walk the filesystem — with du, with tmutil, or with a visual map.

We wrote VolumeLens because this is the exact question a storage tool ought to answer honestly. It walks your disk, counts hard links once, flags folders macOS refused to read instead of pretending they are empty, and — with Insights — labels the developer caches, virtual disks, and iOS backups that make up most of the System Data mystery. Free for scan, browse, search, and cleanup; Pro adds Insights and CSV export. See pricing or download when you are ready.