Xcode vs System Data storage: why the macOS bar says 12 GB Xcode and 180 GB System Data on the same Mac

You open System Settings, Storage, and the bar shows two numbers that do not add up. Xcode is listed at 12 GB. System Data is 180 GB. You have one Xcode project, three simulators, and a DerivedData folder you have not cleared in eight months. The Xcode bar feels like it is lying. It is not lying, it is just answering a different question than the one you asked.

Why does the macOS Storage bar split Xcode and System Data?

macOS classifies disk usage by file location, not by owning application. The classifier walks the filesystem, tags each path with a category from a hardcoded list, and totals by category. The Xcode category in that list is narrow on purpose. It covers /Applications/Xcode.app and a handful of ~/Library/Developer/Xcode/UserData/ subfolders that hold project-specific user preferences. That sum lands somewhere between 9 GB and 14 GB for a current Xcode 16 install with a few projects opened, which is what the bar shows.

System Data is the catch-all category that absorbs everything macOS does not have a specific bucket for. The folders Xcode writes most of its bytes into all qualify:

• ~/Library/Developer/Xcode/DerivedData/
• ~/Library/Developer/Xcode/Archives/
• ~/Library/Developer/Xcode/iOS DeviceSupport/
• ~/Library/Developer/Xcode/watchOS DeviceSupport/
• ~/Library/Developer/CoreSimulator/
• ~/Library/Developer/XCTestDevices/
• ~/Library/Caches/org.swift.swiftpm/
• /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/

Those paths are owned by Xcode by every reasonable definition. They exist because Xcode created them. They go away if you uninstall Xcode and the runtimes. macOS still files them under System Data because the classifier indexes by path, not by author.

What does the macOS Storage bar actually measure for each category?

The same Mac, broken down properly, looks like this. Numbers come from a 1 TB MacBook Pro running Xcode 16.2 with three iOS simulators, two watchOS runtimes, and six months of build history.

Add the rows from DerivedData down. That sum is Xcode's true cost on disk. It almost always exceeds the Xcode bar by an order of magnitude, and it always counts as System Data in System Settings. The Apple Developer Forums thread on orphaned runtimes documents a single 9 GB orphan in /System/Library/AssetsV2 that newer Xcode versions never expose in the UI but still inflate System Data.

How do I see Xcode's real footprint in one command?

Open Terminal and run this. It is a read-only audit. Nothing gets deleted.

# Show what Xcode actually costs on disk versus the macOS Storage bar.
{
  printf "\n=== Xcode bar candidates (counted as 'Xcode') ===\n"
  du -sh /Applications/Xcode.app 2>/dev/null
  du -sh ~/Library/Developer/Xcode/UserData 2>/dev/null

  printf "\n=== Counted as 'System Data' but owned by Xcode ===\n"
  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/Xcode/"watchOS DeviceSupport" 2>/dev/null
  du -sh ~/Library/Developer/CoreSimulator/Devices 2>/dev/null
  du -sh ~/Library/Developer/CoreSimulator/Caches 2>/dev/null
  du -sh ~/Library/Developer/XCTestDevices 2>/dev/null
  du -sh ~/Library/Caches/org.swift.swiftpm 2>/dev/null

  printf "\n=== System-owned simulator runtime cache (needs sudo to read) ===\n"
  sudo du -sh /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime 2>/dev/null

  printf "\n=== Total free disk ===\n"
  df -h /
} | tee ~/Desktop/xcode-footprint.txt

The first block matches the Xcode entry in System Settings within a few hundred MB. The second block, added together, is the amount of System Data that is really Xcode wearing a different label. On a Mac that has not been swept in six months, the second block typically runs 80 to 150 GB.

Why does Apple group Xcode caches with System Data?

There is a defensible reason for the classifier choice. ~/Library/Developer is a shared developer-toolchain location. Apple's command line tools, Instruments, Swift toolchains downloaded outside Xcode, and third-party tools all write there. Apple did not want the Storage bar to credit one app for shared infrastructure. The same logic applies to /System/Library/AssetsV2, which is a system-level asset cache that Xcode triggers but does not own exclusively.

The reason is defensible. The result is misleading. A working iOS engineer reads "Xcode 12 GB, System Data 180 GB" and concludes Xcode is small and macOS is the problem. The honest reading is the inverse, most of the time. The brtkwr.com "Using Claude to free 200GB" writeup makes the broader point about misattributed System Data on dev Macs:

"After the initial Docker/cache cleanup freed 150GB, going back and asking 'what else?' found another 75GB."

The "what else?" pass on a iOS engineer's Mac almost always points at the Xcode-owned paths the Storage bar is hiding from them.

What is in the Storage bar that is NOT Xcode?

Subtract Xcode's true footprint from the System Data bar. The remainder is the genuinely non-Xcode System Data. On a working dev Mac in 2026 it usually breaks down like this.

The decoding System Data categories explainer walks each of these in detail. The point for the Xcode comparison is simple: once you remove Xcode-owned bytes from System Data, the remainder is almost always AI tooling and Docker, not macOS itself.

How do I shrink the Xcode share of System Data safely?

The order matters because the rebuild cost varies. Start with the path that rebuilds itself on the next build and end with the ones that cost a download or a re-symbolicate.

# Trash-first cleanup. Reversible for seven days.
# 1. DerivedData (rebuilds on next build, zero cost).
mv ~/Library/Developer/Xcode/DerivedData ~/.Trash/DerivedData-$(date +%s)
mkdir -p ~/Library/Developer/Xcode/DerivedData

# 2. CoreSimulator caches (dyld, runtime metadata; rebuilds on first launch).
mv ~/Library/Developer/CoreSimulator/Caches ~/.Trash/CoreSimulator-Caches-$(date +%s)
mkdir -p ~/Library/Developer/CoreSimulator/Caches

# 3. iOS DeviceSupport (re-downloads when you next plug in the device).
mv ~/Library/Developer/Xcode/"iOS DeviceSupport" ~/.Trash/iOS-DeviceSupport-$(date +%s)

# 4. Unavailable simulator runtimes (the official knob, not reversible).
xcrun simctl delete unavailable

# 5. Recheck the System Data bar.
df -h /

The full path-by-path walk for DerivedData lives in safely delete Xcode DerivedData. The simulator side, including the orphans xcrun simctl delete unavailable misses, is in reclaim disk from Xcode simulators. Both posts default to Trash-first commands so you can recover if a build pipeline turns out to need the cache.

A Mac with 180 GB of System Data usually drops to 60 to 90 GB after the five commands above. The Xcode bar does not change because the app bundle did not change. The System Data bar drops by exactly the bytes you trashed, because those bytes were Xcode wearing a System Data label.

Should I trust the macOS Storage bar at all?

Use the macOS Storage bar to spot trends, not to attribute blame. A System Data bar that grew 60 GB in a month is real, regardless of category labels. A drop after xcrun simctl delete unavailable confirms you got the right path. The bar is fine as a thermometer. It is bad as a diagnosis.

For diagnosis, run du -sh on the eight paths above, or run a tool that does it for you. The Apple Discussions thread on rogue simulators is full of devs posting du output to each other because nobody trusts the bar to tell them where 18 GB of "Xcode" actually went. A read-only audit answers the question in 20 seconds.

When is the Xcode bar actually accurate?

There are two cases. A Mac that has never built a project, where the Xcode bar honestly reflects the app bundle plus a few MB of user state. And a Mac that was wiped within the last week, where DerivedData and simulators have not had time to grow. Outside those two cases, the Xcode bar is a lower bound, often off by 10x or more.

CleanMyDev makes the diagnosis quick: the same eight paths, plus 20 other categories of dev-Mac System Data, with sizes and last-modified dates in one window, Move to Trash by default. The lifetime license is $9.99 at /#pricing. Audit mode is free, so compare the per-row breakdown to the macOS Storage bar before paying.

Related reading

• Safely delete Xcode DerivedData
• Reclaim disk from Xcode simulators
• Core Simulator caches on Mac