You open System Settings → General → Storage on your MacBook, hover over the storage bar, and try to remember what the labels used to be. There was definitely a category called Other a couple of years ago. Now you only see System Data, and it is enormous. A Reddit thread you scroll into swears Other is still a thing. A blog post from 2021 tells you to clear Other with a sequence of steps that no longer matches the UI.
On a developer Mac the confusion is worse, because that bucket is usually 80 to 200 GB and Apple refuses to tell you what is inside.
What was the Other category on Mac?
Before macOS Ventura, the storage panel under About This Mac → Storage showed a category called Other. It was Apple's grab bag for everything that did not fit into Apps, Documents, Photos, Mail, Music, Messages, Podcasts, iCloud Drive, or TV.
In practice, Other contained:
- System and application caches under
~/Library/Caches/ - Application support data under
~/Library/Application Support/ - Logs in
~/Library/Logs/and/Library/Logs/ - Plugins and extensions
- Disk images, virtual machine images, and archives
- Fonts, dictionaries, and other resources macOS could not classify
- Many of the dot-folders in your home directory like
~/.npm/,~/.cache/,~/.docker/
System Data was a separate, smaller category, mostly used for macOS itself.
What changed in macOS Ventura?
Apple consolidated the two buckets. Starting with macOS Ventura (13), the storage panel moved into System Settings → General → Storage and the Other category disappeared. Almost all of what used to be Other is now reported as System Data.
If you upgraded from Monterey to Ventura, you likely saw the System Data bar suddenly grow by 50 to 150 GB overnight. Nothing actually changed on disk. Apple just stopped splitting two labels that confused users equally.
System Data vs Other storage on Mac: a side-by-side comparison
Here is the same set of files, labelled the way each macOS version reports them.
| File type | Example path | Pre-Ventura label | Ventura and later label |
|---|---|---|---|
| User caches | ~/Library/Caches/ |
Other | System Data |
| Application support | ~/Library/Application Support/ |
Other | System Data |
| Logs | ~/Library/Logs/, /Library/Logs/ |
Other | System Data |
| Xcode build artifacts | ~/Library/Developer/Xcode/DerivedData/ |
Other | System Data |
| iOS Simulator runtimes | ~/Library/Developer/CoreSimulator/ |
Other | System Data |
| Claude Code sessions | ~/.claude/ |
Other | System Data |
| Codex CLI rollouts | ~/.codex/ |
Other | System Data |
| Cursor cached data | ~/Library/Application Support/Cursor/ |
Other | System Data |
| Ollama models | ~/.ollama/models/ |
Other | System Data |
| Hugging Face cache | ~/.cache/huggingface/ |
Other | System Data |
| Docker VM image | ~/Library/Containers/com.docker.docker/.../Docker.raw |
Other | System Data |
| Time Machine local snapshots | /Volumes/.timemachine/... |
System | System Data |
| macOS swap files | /private/var/vm/ |
System | System Data |
| Recovery and firmware | /System/Library/... |
System | macOS (separate row) |
The pattern: most things that used to be Other are now System Data. Pure operating system files have their own macOS row, which is usually a calm 12 to 20 GB and does not balloon.
Why does this matter for developers?
Because the rename hides the real story. On a developer Mac, System Data is rarely macOS bloat. It is your tools.
A single dev cleanup that freed 200 GB, documented at brtkwr.com, broke down the recovered space like this:
"Docker was the biggest culprit... The volumes were almost entirely unused, probably from old postgres/redis containers I'd stopped months ago."
That 108 GB Docker recovery was reported as System Data in Sonoma, and would have been split between Other and a small bit of System on Monterey. Same files, different label.
The same author noted a second pattern that catches everyone:
"When you stop using an editor, uninstall it properly or manually delete its Application Support directory."
Every Cursor, Windsurf, VS Code Insiders, Zed, Atom, and Brackets install you ever ran is still sitting in ~/Library/Application Support/. The app is gone from the Applications folder, the support directory is not.
How to audit System Data on a developer Mac
Apple does not give you a breakdown, so you do it from Terminal. Here is a one-shot audit that hits the usual heavy locations.
# top-level developer caches
du -sh ~/.claude ~/.codex ~/.cursor ~/.cline ~/.factory 2>/dev/null
du -sh ~/.ollama ~/.cache/huggingface 2>/dev/null
# Xcode and simulator
du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null
du -sh ~/Library/Developer/Xcode/Archives 2>/dev/null
du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport 2>/dev/null
du -sh ~/Library/Developer/CoreSimulator/Devices 2>/dev/null
# JS / container
du -sh ~/.npm/_cacache ~/Library/pnpm ~/.bun 2>/dev/null
du -sh ~/Library/Caches/ms-playwright 2>/dev/null
du -sh ~/Library/Containers/com.docker.docker 2>/dev/null
# old editor leftovers (uninstalled apps still take space here)
du -sh ~/Library/Application\ Support/Cursor 2>/dev/null
du -sh ~/Library/Application\ Support/Windsurf 2>/dev/null
du -sh ~/Library/Application\ Support/Code\ -\ Insiders 2>/dev/null
Sort by size, then decide. Each number you see is a piece of the System Data bar in System Settings.
Why the labels are confusing on purpose
The split between Other and System was never useful. Both contained files most users could not identify. Apple's consumer-facing answer is "let macOS manage it" via Optimize Storage, which on a dev Mac is meaningless. macOS does not know that ~/.claude/projects/ doubles every month or that Docker.raw will grow to 60 GB if you let it.
The Ventura rename also masked a real growth trend. AI coding tools, local LLMs, and per-project container layers all started landing in the same bucket at the same time the label changed. People upgrading to Ventura assumed Apple was adding to System Data. In reality, it was their own tools.
For a longer breakdown of the bucket itself, see what is System Data on Mac. For a step-by-step reduction guide that respects what you actually need, see how to reduce System Data on macOS safely. The Xcode-specific slice is in safely delete Xcode DerivedData.
What about the storage panel telling me to clean up?
macOS will recommend Optimize Storage, Empty Bin Automatically, and Reduce Clutter. These do almost nothing for a developer Mac.
| Apple recommendation | What it actually clears | Useful for dev Mac? |
|---|---|---|
| Optimize Storage | Removes iTunes movies and TV shows you have watched | No |
| Empty Bin Automatically | Empties Trash after 30 days | Marginal |
| Reduce Clutter | Opens a Documents browser, you delete by hand | No |
| Store in iCloud | Offloads Documents and Desktop files | No, dev caches live elsewhere |
None of these touch DerivedData, Simulator runtimes, AI tool sessions, Docker volumes, or Ollama models. The only way to address those is to know the paths and audit them directly.
The skeptical-dev answer
You do not need to clear System Data. You need to know what is in it.
A 50 GB DerivedData folder is fine if you are mid-project. A 50 GB DerivedData folder for a repo you have not touched in eight months is reclaimable. A 12 GB Ollama model you use weekly is a working asset. A 12 GB Ollama model you forgot you pulled in October is dead weight. The label does not tell you which is which. The path, last-modified date, and your memory do.
How CleanMyDev handles this
CleanMyDev opens the System Data bucket the way a developer would if they had a week to write the script themselves. It scans 110 plus developer-specific paths across Xcode, Simulators, AI coding tools, LLM caches, containers, JS package managers, and uninstalled editor leftovers. Every result shows path, size, last-used date, and a risk label. Default action is Move to Trash, restorable from Finder until you empty.
No telemetry. No sudo. No surprises. One time payment, $9.99, lifetime updates.