Xcode Taking Up Space on Mac? Safe Ways to Reclaim It

Xcode is one of the biggest apps you can install, but the app itself is rarely the real problem. Its caches — build products, simulators, device support files, archives — grow with every project and every iOS release, and they routinely take two or three times more space than Xcode. All of them can be trimmed without breaking your projects.

Where Xcode hides its gigabytes

Almost everything lives under ~/Library/Developer. The usual suspects, roughly in order of size:

• ~/Library/Developer/Xcode/DerivedData — build output and indexes for every project you've ever opened. 10–40 GB is common.
• ~/Library/Developer/CoreSimulator — simulator devices and their installed apps and data.
• ~/Library/Developer/Xcode/iOS DeviceSupport — debug symbols for every iOS version you've ever plugged in, several gigabytes each.
• ~/Library/Developer/Xcode/Archives — every build you've archived for distribution, kept forever.

# See what each Developer folder is holding (read-only)
du -sh ~/Library/Developer/*

Clear DerivedData first

DerivedData is a pure cache: intermediate build products, module caches, and the search index for each project. It's the single biggest and safest win.

# Check the size
du -sh ~/Library/Developer/Xcode/DerivedData
# Delete it — Xcode regenerates this on the next build
rm -rf ~/Library/Developer/Xcode/DerivedData

There's no undo command because none is needed: the next build of each project recreates its folder from source. The only cost is that the first build afterwards runs from scratch — a few extra minutes per project. If a project has been misbehaving — phantom errors, stale assets, a broken index — clearing DerivedData often fixes that too, which is why it's the first thing experienced iOS developers try. You can also find the folder from inside Xcode via Settings → Locations, where the DerivedData path has a small arrow that reveals it in Finder.

Delete simulators you no longer use

Every simulator device you've ever created keeps its own data. Two commands clean up the strays:

# List every simulator on this Mac
xcrun simctl list devices
# Remove simulators whose runtime is no longer installed
xcrun simctl delete unavailable

The list command is read-only; look for devices marked unavailable before running the delete. To reclaim entire OS runtimes, open Xcode → Settings → Platforms and delete iOS versions you no longer target — a single old runtime is often 7–8 GB. Both actions are reversible: you can re-download any runtime from the same Platforms pane, and recreate a deleted simulator in Window → Devices and Simulators with the + button.

Device support files and old archives

iOS DeviceSupport keeps one folder per iOS version that's ever been attached to your Mac for debugging — and there are sibling folders for watchOS and tvOS if you've debugged those devices too. Old versions are safe to delete: if you ever plug in a device running that version again, Xcode re-copies the symbols from it (the first connection just takes a few minutes longer). Keep the folders that match devices you actively debug, and clear the rest without guilt — a Mac that's been through four iPhone generations often carries 15–20 GB here alone.

Archives are in Xcode → Window → Organizer → Archives — right-click any of them to delete. One caution: keep the archives for app versions still live on the App Store, because they hold the dSYM files you need to symbolicate crash reports. Everything older than your oldest shipping version is fair game.

Where this shows up in Storage

Everything under ~/Library/Developer is counted as System Data in the storage bar, which is why developer Macs show such alarming numbers there. If the category still looks bloated after this cleanup, see what else lives inside System Data.