Where Xcode's disk space goes, and how to get it back

On this page

1. Take stock first
2. Simulator runtimes
3. Simulator devices
4. Device support files
5. DerivedData
6. Archives: keep the ones you shipped
7. What not to delete
8. Where Spaceback fits

If you build apps for Apple platforms, Xcode is almost certainly the biggest thing on your disk, and most of it isn't Xcode itself. It's simulator runtimes you downloaded once, simulator devices that quietly filled up, debug symbols for every iOS version you've ever plugged in, and build products for projects you haven't opened in months.

Here's what that looked like on my MacBook Air on September 28, 2026, with Xcode 26.6 on macOS 27.0:

What	Where	Size
Simulator runtimes (5 disk images)	Managed by xcrun simctl runtime	35.0 GB
Simulator devices (29 of them)	~/Library/Developer/CoreSimulator/Devices	32 GB
iOS device support	~/Library/Developer/Xcode/iOS DeviceSupport	6.5 GB
DerivedData	~/Library/Developer/Xcode/DerivedData	2.9 GB
Swift Package Manager cache	~/Library/Caches/org.swift.swiftpm	0.7 GB

About 77 GB, on a Mac where I don't keep old archives because release builds come from Xcode Cloud. Yours will differ, but the order is usually the same: runtimes and devices first, everything else a long way behind.

Take stock first

This prints the size of each folder that exists and then lists your runtimes. It only reads:

for p in ~/Library/Developer/Xcode/DerivedData \
         ~/Library/Developer/Xcode/Archives \
         "$HOME/Library/Developer/Xcode/iOS DeviceSupport" \
         ~/Library/Developer/CoreSimulator/Devices \
         ~/Library/Caches/org.swift.swiftpm; do
  [ -e "$p" ] && du -sh "$p"
done
xcrun simctl runtime list

Simulator runtimes

In recent versions of Xcode, simulator runtimes are signed disk images that macOS stores and mounts for you, outside your home folder. That's why they're easy to miss: nothing in your home folder gets bigger when you download one. xcrun simctl runtime list -v shows each one's size, where it's stored and, usefully, when it was last used. Two of my five, iOS 18.1 and iOS 18.5, had no "Last Used At" line at all: 16 GB between them.

The easiest way to remove one is Xcode's Settings window, on the Components tab (called Platforms before Xcode 16). From Terminal, simctl can now delete by age, and it has a dry run:

xcrun simctl runtime delete --notUsedSinceDays 30 --dry-run
xcrun simctl runtime delete --notUsedSinceDays 30

There are also --unusable for runtimes marked unusable and --outdated for ones that have a newer version with the same identifier, or you can pass a single runtime's identifier from the list. You don't need sudo: simctl asks a system service to do the deleting. If you need a runtime again later, Xcode downloads it again, which costs a few gigabytes of bandwidth and a coffee.

Simulator devices

Every simulator you've booted keeps its own data: installed apps, photos, caches, everything a real device would accumulate. The iPhone 17 Pro simulator I run UI tests on had grown to 7 GB on its own. To find your biggest ones, list the device folders by size and match the long IDs against xcrun simctl list devices:

du -sh ~/Library/Developer/CoreSimulator/Devices/* 2>/dev/null | sort -h | tail -5
xcrun simctl list devices

Then pick the gentlest tool that fixes it:

xcrun simctl delete unavailable   # devices whose runtime you've removed
xcrun simctl shutdown all         # erase needs the devices shut down
xcrun simctl erase all            # wipe every device's contents, keep the devices
xcrun simctl delete <device-id>   # remove one device entirely

Erasing is usually what you want: the devices stay in Xcode's destination menu, just empty. SwiftUI previews keep a separate set of simulators, and xcrun simctl --set previews delete all clears those.

Device support files

When you connect a device to debug on it, Xcode copies that iOS version's debug symbols to ~/Library/Developer/Xcode/iOS DeviceSupport, one folder per device model and version. They pile up as you and your test devices update. Delete the folders for versions you no longer run. If you connect a device on that version again, Xcode copies the symbols again, which takes a few minutes the first time.

DerivedData

DerivedData holds build products, intermediate files and the index for every project you've opened. It's the classic fix for a build that won't behave, and it's safe to delete with Xcode closed:

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

The cost is a full rebuild and a re-index the next time you open each project. On a big project that's a few minutes of a warm laptop. Mine is only 2.9 GB because most of my command-line builds pass -derivedDataPath to xcodebuild, which puts DerivedData inside the project instead. If you do that too, those project-level folders are where the space went, and they need the same treatment. On a Mac with a dozen active projects and default settings, 20 GB or more is normal.

Archives: keep the ones you shipped

Archives in ~/Library/Developer/Xcode/Archives are the builds you exported or uploaded, and they contain the debug symbols (dSYMs) you need to symbolicate crash reports for those exact builds. Delete archives for versions nobody runs any more. Keep the ones for versions still in users' hands, unless your crash reporting already has the symbols. If you distribute through App Store Connect with symbols included, Xcode's Organizer can symbolicate crashes from Apple, but third-party crash reporters still want the dSYMs.

What not to delete

• Xcode.app itself, or files inside it. If you need to remove platform support, do it from the Components tab so Xcode knows it's gone.
• Anything under /Library/Developer/CoreSimulator by hand. That's where the runtime images are stored and mounted. Deleting files there by hand, instead of through simctl or Xcode, can leave the simulator service confused about what's installed.
• ~/Library/Developer/Xcode/UserData. Key bindings, code snippets, themes and breakpoints live there. The previews simulators are inside it, but clear those with the command above, not by deleting the folder.

Where Spaceback fits

Spaceback's Junk scan lists DerivedData, Archives, iOS device support and the simulator caches folder, along with npm, Yarn, Homebrew, CocoaPods and Gradle caches, each with its size. Scanning is free; cleaning developer caches is part of Pro, and everything you pick goes to the Trash. The App Store version doesn't delete simulator runtimes or simulator devices. It can't reach where runtimes live, and even if it could, simctl is the right tool, because Xcode needs to know what's been removed.

Vlada Misici builds Spaceback, a storage cleaner for Mac and iPhone. Every number in these posts was measured on a real Mac, and every command was run before it went on the page. Found a mistake? Email vlada@queazy.app and it gets fixed.