Why "System Data" Is Eating Your Mac Storage (And It's Xcode's Fault)

That mysterious "System Data" category in your Mac's storage settings can swell to 100GB+ on a developer machine. Here's what's actually inside it and how to take back control.

You open System Settings > General > Storage on your Mac, and there it is: a massive gray bar labeled "System Data" consuming 60, 80, maybe 150 gigabytes of your precious SSD. You click on it expecting a breakdown, and macOS gives you... nothing. No list of files. No explanation. Just a shrug in the form of a vague label.

If you're an iOS or macOS developer, this isn't a mystery at all. That "System Data" category is almost certainly dominated by one thing: Xcode and its associated caches, simulators, and build artifacts. The problem is that Apple categorizes most of ~/Library/Developer/ as "System Data" rather than showing it under "Applications" or "Developer Tools," so it looks like your operating system is hogging space when it's really your development workflow.

In this guide, we'll crack open the black box. You'll learn exactly which directories are hiding inside System Data, how big each one gets, and what you can safely delete to reclaim tens of gigabytes right now.

What Is "System Data" in macOS Storage?

macOS groups your disk usage into categories: Apps, Documents, Photos, System, and System Data. The "System Data" category is essentially a catch-all for files that don't fit neatly into other buckets. It includes:

  • Application caches (not just browser caches — every app that caches data)
  • System logs and diagnostics
  • Fonts, voices, and dictionaries
  • Virtual memory swap files
  • Time Machine local snapshots
  • Spotlight indexes
  • And crucially: developer tool data stored in ~/Library/

For non-developers, System Data typically sits between 10-30GB. For developers working with Xcode, it routinely balloons to 40-160GB. The difference is almost entirely attributable to the contents of ~/Library/Developer/.

The Hidden Culprit: ~/Library/Developer/

The ~/Library/Developer/ directory is where Xcode stores virtually everything it needs beyond its own application bundle. This single directory can easily contain more data than Xcode itself. Let's measure it:

du -sh ~/Library/Developer/*

On a typical developer Mac that's been used for a year or more, this command produces something like:

 28G    /Users/you/Library/Developer/CoreSimulator
 35G    /Users/you/Library/Developer/Xcode
  4.2G  /Users/you/Library/Developer/CommandLineTools
512M    /Users/you/Library/Developer/Toolchains

That's 67.7 GB just in this one example, and it's on the lower end. Developers who work with multiple simulator runtimes, maintain several projects, or have been using the same machine across multiple Xcode versions can easily see this number climb past 120GB.

Let's break down each component.

Component Breakdown: Where the Gigabytes Go

1. CoreSimulator (10-50GB)

The iOS, iPadOS, watchOS, tvOS, and visionOS simulators are managed under ~/Library/Developer/CoreSimulator/. This directory contains:

  • Simulator runtimes (CoreSimulator/Caches/dyld and downloaded runtime images): Each iOS version runtime is 4-7GB. If you have three iOS versions installed (say iOS 17, 18, and 19), that alone is 12-21GB.
  • Simulator device data (CoreSimulator/Devices/): Each simulator device you've created stores its own filesystem — apps you've installed, documents, photos, caches. A single device can range from 500MB (fresh) to several GB (if you've been testing with it extensively).
  • Runtime caches: dyld shared caches for each platform and OS version.

To see how many simulator devices you have and their total size:

xcrun simctl list devices
du -sh ~/Library/Developer/CoreSimulator/Devices/

It's common to have 20-40 simulator devices that you never use. Every time Xcode updates or you install a new runtime, it may create new default devices.

2. Xcode (DerivedData + Archives + More) (15-60GB)

The ~/Library/Developer/Xcode/ directory is the big one. It contains several subdirectories:

  • DerivedData (~5-30GB): Build artifacts, indexes, and logs for every project you've opened. Each project gets its own folder. Old projects you haven't touched in months still take up space here.
  • Archives (~2-20GB): Every time you archive a build for App Store submission or ad-hoc distribution, Xcode saves the full archive here. Each archive includes the compiled binary, dSYM files, and metadata. A single archive can be 200MB-2GB.
  • iOS DeviceSupport (~3-15GB): When you connect a physical iOS device to your Mac, Xcode downloads debug symbols for that device's iOS version. Each version is 2-5GB. If you've connected devices running iOS 15, 16, 17, 18, and 19 over the years, that's 10-25GB of debug symbols — most of which you'll never need again.
  • UserData/Previews (~5-80GB): SwiftUI Preview build artifacts. This one deserves its own article (and we wrote one). It can silently grow to enormous sizes.
  • Products: Exported builds and installers.

To get a complete picture:

du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/Archives
du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport
du -sh ~/Library/Developer/Xcode/UserData/Previews

3. Command Line Tools (2-5GB)

If you've installed the Xcode Command Line Tools separately (via xcode-select --install), they live at /Library/Developer/CommandLineTools/. This is a system-level directory and typically costs 2-5GB. It includes compilers, linkers, headers, and SDKs. Most developers need these, but if you have a full Xcode installation, the standalone CLT may be redundant.

4. Toolchains (0-3GB)

Custom Swift toolchains (development snapshots from swift.org) are stored in ~/Library/Developer/Toolchains/. Each toolchain is about 700MB-1.5GB. If you've experimented with Swift nightly builds or custom toolchains, check whether you still need them.

Why Apple Doesn't Show You This Breakdown

Apple's storage management UI in System Settings is designed for consumers. It shows you categories that make sense for photo libraries, music, documents, and app bundles. But developer tooling doesn't fit this consumer model:

  • Xcode's caches are in ~/Library/, which macOS treats as system-level data, not user documents.
  • Simulator runtimes are registered with CoreSimulator, not installed as traditional apps, so they don't appear in the Applications category.
  • DerivedData is a cache, but macOS doesn't show per-app cache breakdowns in the storage UI.
  • Archives and device support files don't belong to any category that the consumer storage UI recognizes.

The result is that all of this gets lumped into "System Data," making it look like macOS itself is the problem. Apple has improved this slightly in recent macOS versions (Sequoia shows a bit more detail), but for developers, the breakdown is still inadequate.

Step by Step: Reclaim Your System Data

Here is a prioritized cleanup plan. Start with the safest, highest-impact items and work your way down.

Step 1: Delete DerivedData (Safe, 5-30GB)

DerivedData is a build cache. Deleting it forces Xcode to rebuild when you next open a project, but nothing is lost. It's the single safest cleanup you can do.

rm -rf ~/Library/Developer/Xcode/DerivedData/*

Or, if you want to be selective and only remove old project caches:

# List DerivedData folders sorted by last modified date
ls -lt ~/Library/Developer/Xcode/DerivedData/

# Remove a specific project's cache
rm -rf ~/Library/Developer/Xcode/DerivedData/MyOldProject-abcdefg/

Step 2: Remove Old Simulator Devices (Moderate, 2-15GB)

Delete simulators for iOS versions you no longer target:

# List all available simulators
xcrun simctl list devices

# Delete all simulators that are in "unavailable" state
# (their runtime was uninstalled)
xcrun simctl delete unavailable

# Delete a specific device by UUID
xcrun simctl delete <DEVICE-UUID>

Step 3: Remove Old Device Support (Safe, 3-15GB)

If you no longer have devices running iOS 15 or 16, there's no reason to keep those debug symbols:

ls ~/Library/Developer/Xcode/iOS\ DeviceSupport/

# Remove support files for old versions
rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/15.*
rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/16.*

Step 4: Clean Old Archives (Manual Review, 2-20GB)

Open Xcode's Organizer (Window > Organizer) to review your archives. Delete builds you no longer need for crash report symbolication. As a rule of thumb, keep the last two releases of each app and delete everything older.

# Or from Terminal:
ls -lh ~/Library/Developer/Xcode/Archives/

# Delete all archives from 2024 and earlier
rm -rf ~/Library/Developer/Xcode/Archives/2024*
rm -rf ~/Library/Developer/Xcode/Archives/2023*

Step 5: Clear SwiftUI Previews Cache (Safe, 5-80GB)

xcrun simctl --set previews delete all

This removes all cached Preview builds. They'll be regenerated on demand when you use SwiftUI Previews.

Step 6: Remove Unused Simulator Runtimes (5-20GB per Runtime)

# List installed runtimes
xcrun simctl runtime list

# Delete a specific runtime
xcrun simctl runtime delete <RUNTIME-IDENTIFIER>

Each runtime is 4-7GB. If you only need the latest iOS version for development, removing old runtimes frees significant space.

Beyond Xcode: Other Developer Tools That Inflate System Data

Xcode is the biggest contributor, but it's not alone. Other common developer tools that hide data inside System Data:

Docker Desktop (10-60GB)

Docker stores its virtual machine disk image at:

~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

This file grows over time as you pull images and build containers. Even if you delete images, the raw file doesn't automatically shrink. You can reclaim space by pruning:

docker system prune -a --volumes

And then, in Docker Desktop settings, reduce the virtual disk size limit.

Homebrew (2-10GB)

Homebrew keeps old versions of packages in its Cellar and caches downloads:

# See how much Homebrew is using
du -sh /opt/homebrew/  # Apple Silicon
du -sh /usr/local/     # Intel Macs

# Clean up old versions and download cache
brew cleanup --prune=all

node_modules and npm/yarn/pnpm Cache (5-30GB)

Every Node.js project creates a node_modules directory. If you have 10 projects, you might have 10 copies of React, TypeScript, and hundreds of other packages. The package manager caches add more:

# Check npm cache size
du -sh ~/.npm/_cacache

# Check yarn cache
du -sh ~/Library/Caches/Yarn

# Check pnpm store
du -sh ~/Library/pnpm/store

# Clean npm cache
npm cache clean --force

CocoaPods Cache (1-5GB)

du -sh ~/Library/Caches/CocoaPods
pod cache clean --all

Swift Package Manager Cache (1-5GB)

du -sh ~/Library/Caches/org.swift.swiftpm
rm -rf ~/Library/Caches/org.swift.swiftpm

How to Monitor System Data Over Time

The real problem isn't the one-time cleanup — it's the fact that these directories grow back silently. Within a month of a full cleanup, DerivedData will be 10GB again, simulators will accumulate, and archives will pile up.

Here are strategies for ongoing monitoring:

  • Schedule a monthly du -sh check: Add a recurring reminder to run du -sh ~/Library/Developer/* and check the totals.
  • Use a menu bar monitor: Tools like DiskPort sit in your menu bar and show your developer storage usage at a glance, alerting you when directories exceed thresholds you set.
  • Set up automatic DerivedData cleanup: Delete DerivedData folders that haven't been modified in 30+ days. This can be scripted or handled by a tool like DiskPort.

The Real Fix: Know What's in System Data

The "System Data" mystery isn't really a mystery once you know where to look. For developers, the answer is almost always the same: Xcode simulators, build caches, device support files, and archives. Combined with Docker, Homebrew, and Node.js caches, it's not unusual for developer tooling to consume 80-120GB of what macOS labels as "System Data."

The key takeaway: don't blame macOS. Your operating system isn't broken. Your development workflow is generating enormous amounts of cached data, and Apple's storage UI simply doesn't surface it in a useful way. Once you understand the anatomy of ~/Library/Developer/, you can take control.

Regular cleanup — or better yet, automated cleanup with the right tool — can keep System Data under control and free up 30-80GB on your Mac without losing anything important.