System Data Unpacked › macOS System Data

macOS System Data: what it is and how to clear it safely

By Yigit Can Polat, who builds a Mac app that measures it · Updated 2 November 2026

What System Data is

Open System Settings › General › Storage (on macOS Monterey and earlier, About This Mac › Storage) and the bar is split into Applications, Documents, Photos, macOS and a few more. System Data is what is left over. It is not a folder and not a type of file. It is a category, and it is defined by exclusion: whatever Storage settings cannot attribute to one of the named categories ends up there.

Until macOS Monterey the same category was called Other. The rename did not change what goes into it, and it did not make it any easier to see inside: Storage settings still shows one total and no list.

That is why the number is confusing. It is not one thing that grew, it is a few dozen unrelated things that each grew a little, and macOS adds them up without saying what they are.

What is actually inside it

Here is a real one: a developer's Mac, 245 GB disk, System Data at 107.9 GB, measured item by item. The badges say how much thought deleting each part needs.

Measured with System Data Unpacked on one Mac. Yours will differ, which is the point: the parts change from machine to machine, so no fixed list of folders to delete is right for everyone.

On a Mac that is not used for development the mix is different but the idea is the same. The usual large parts are:

• Local Time Machine snapshots. Hourly APFS snapshots kept on the startup disk while the backup drive is away. macOS deletes them on its own when it needs room, but until then they count.
• iPhone and iPad backups made to the Mac, in ~/Library/Application Support/MobileSync/Backup. Often tens of gigabytes each, and often the only local copy of a device.
• Application data. Chat apps keep every photo and video they receive; creative apps keep media caches and render files; Logic Pro and GarageBand sound libraries can reach tens of gigabytes.
• Caches and logs in ~/Library/Caches, ~/Library/Logs and /Library/Caches.
• Virtual machine disks from Parallels, UTM, VMware Fusion or Docker, which are single files of tens of gigabytes.
• Software update files while an update is downloading or waiting to install.

Why System Data gets so large

Almost nothing in it is a leak. Each part is a cache or a store that some tool fills on purpose and nobody empties: Xcode keeps every build product in case you build again, a package manager keeps every version it downloaded, a simulator keeps every app you installed on it, and every Xcode update leaves the previous simulator runtime behind. Each of them is reasonable on its own. Together, over a year, they pass 100 GB without anything being wrong.

It also grows in bursts. A new Xcode, a new project, a model download or a phone backup can add 10 to 30 GB in an afternoon, which is why the number seems to jump rather than creep.

How to see what is inside

Storage settings will not list the parts, but Terminal will. These commands only read; none of them deletes anything.

The largest folders in your Library

du -sh ~/Library/* ~/Library/Application\ Support/* 2>/dev/null | sort -h | tail -20

Local Time Machine snapshots

tmutil listlocalsnapshots /

Simulator runtimes and devices (if you have Xcode)

xcrun simctl runtime list
du -sh ~/Library/Developer/CoreSimulator/Devices ~/Library/Developer/Xcode/* 2>/dev/null

Docker

docker system df

Two things make doing this by hand slow. Some of the largest folders sit inside other apps' containers, which macOS will not let Terminal read until Terminal has Full Disk Access. And a list of sizes does not say what each folder is or whether deleting it is safe. That second question is the one that matters.

How to clear System Data safely

Go from the parts that cost nothing to delete towards the ones that need a decision, and stop when you have the space you need.

1. Caches and build output that rebuild on their own

Xcode's DerivedData, package manager caches and app caches are recreated the next time they are needed. Deleting them costs a slower next build and nothing else.

rm -rf ~/Library/Developer/Xcode/DerivedData
brew cleanup --prune=all
npm cache clean --force

2. Simulators and runtimes you no longer use

Every Xcode update leaves the previous runtime behind. Remove the devices Xcode itself marks unavailable, then any runtime you no longer build for.

xcrun simctl delete unavailable
xcrun simctl runtime list
xcrun simctl runtime delete <identifier>

3. Build folders of projects you stopped working on

A node_modules or .build folder in a project you have not opened for months is pure cost. It comes back with npm install or the next build if you ever return.

4. Local snapshots, if you need room right now

macOS removes local snapshots when it runs short of space, so this is rarely needed. When it is, delete them by date from the list above:

sudo tmutil deletelocalsnapshots <date>

5. Decisions, not cleanup

Device backups, virtual machines, downloaded models and app data are things you may want back. Check that a phone is backed up to iCloud before removing its local backup (Finder › your device › Manage Backups), and remove chat media from inside the chat app rather than from its folder, which also holds your login and message history.

What not to delete

• Anything under /System. Since macOS Catalina the system lives on its own read-only volume, sealed since Big Sur; it is not where your System Data is, and trying to change it achieves nothing good.
• Whole folders under ~/Library/Containers or ~/Library/Group Containers belonging to Apple apps. They hold the local copy of Notes, Messages, Mail and others, part of which may not have reached iCloud yet.
• Anything you cannot name. A folder you do not recognise is a reason to find out what made it, not a reason to delete it.

Purgeable space is not free space

Finder and Storage settings show a purgeable figure: the space macOS estimates it could free from caches and snapshots if something needed room. It is tempting to count it as free. Measured, it is not.

On a MacBook with 55.38 GB free, 3.55 GB purgeable and no local snapshots, 6.44 GB was written in 1 GB steps and then deleted. Free space fell by 6.45 GB, every byte of it from real free space and none from the purgeable pool. The purgeable figure dropped to 1.11 GB along the way, which was macOS lowering its estimate rather than handing anything over, and it returned to 3.55 GB on its own once the files were gone. The full measurement is published.

macOS may evict more when a disk is genuinely close to full. At ordinary free-space levels, though, purgeable is an estimate that moves on its own, not space to plan around.

Reducing it without deleting anything

Some of System Data you would rather keep: an SDK, an archive, a project you will come back to. macOS can store files compressed and decompress them transparently when they are read. It does this to much of the system itself. Applied to folders that are mostly read, it frees a lot of space and changes nothing about how they behave. Measured on copies of real folders, with every file compared afterwards:

The last row is the useful warning: data Apple already ships compressed, and dense data such as media or model weights, gains nothing. And folders whose files are shared with others, as a pnpm node_modules made of hard links is, can grow rather than shrink if they are compressed one copy at a time.

Questions