5 Terminal Commands to Reclaim Xcode Disk Space in 2026 (simctl, xcrun & More)

If your Mac has started groaning under the weight of a bloated developer environment, learning the right Xcode disk space terminal commands is the fastest way to claw back tens of gigabytes without reinstalling anything. Xcode is one of the heaviest applications Apple ships — and it keeps growing. On a typical Apple Silicon Mac running macOS Sequoia or Tahoe, a few years of active development can leave behind 80 GB or more of derived data, simulator runtimes, build caches, and stale device support files. This guide walks through five targeted commands, explains where each gigabyte actually lives, and helps you delete only what is safe to remove.

Why Xcode Takes Up So Much Space

Xcode stores far more than the app bundle itself. When you build a project, it writes compiled intermediates and indexes to ~/Library/Developer/Xcode/DerivedData. When you run a simulator, it unpacks a full iOS or watchOS runtime image under ~/Library/Developer/CoreSimulator/Volumes. Archives accumulate in ~/Library/Developer/Xcode/Archives. Device support files (used for on-device debugging) pile up under ~/Library/Developer/Xcode/iOS DeviceSupport. None of these folders are visible in the Finder sidebar by default, so most developers never notice them until disk space becomes critical.

For a deeper look at how these categories appear in macOS Storage, see why Xcode takes up so much space — it covers what the system reports versus what you can actually delete.

The Xcode Disk Space Map: Sizes at a Glance

Before running any commands, it helps to know which folders are the real culprits. The table below shows typical sizes measured on an active Apple Silicon MacBook Pro with two to three years of development history.

Command 1: Wipe DerivedData

DerivedData is almost always the single largest consumer. It holds compiled modules, build logs, source indexes, and code-coverage data for every project you have ever built. Deleting it is completely safe — Xcode rebuilds it the next time you open a project.

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

If you want to preview the size first, run:

du -sh ~/Library/Developer/Xcode/DerivedData

On a busy machine this single folder regularly holds 30 GB or more. After deletion, your next build will be slower as indexes and intermediates regenerate, but subsequent builds return to normal speed.

Command 2: Remove Unused Simulator Runtimes with simctl

simctl is Apple's official command-line interface for managing simulators, and its delete unavailable subcommand is the safest way to prune simulator runtimes that Xcode itself no longer lists as active. In 2026, on macOS Sequoia and Tahoe, simulator runtimes are stored as disk images under ~/Library/Developer/CoreSimulator/Volumes rather than inside the Xcode app bundle, so old runtimes from iOS 15 or 16 linger even after you update Xcode.

How to delete unavailable simulators

1. Open Terminal.
2. List what you have: xcrun simctl list runtimes
3. Delete only the simulators tied to unavailable runtimes: xcrun simctl delete unavailable
4. To also remove downloadable (but not currently installed) runtime caches, open Xcode > Settings > Platforms and manually remove old platform versions from there.

The xcrun wrapper ensures the command runs against the active Xcode installation selected by xcode-select, which matters if you have multiple Xcode versions side by side.

Command 3: Clean Xcode Caches via xcrun

Xcode's internal build system and the Swift Package Manager both maintain caches that accumulate over time. You can flush them with:

xcrun --kill-cache

This terminates any cached xcrun lookup processes and forces Xcode's toolchain to re-locate binaries on next invocation. It is a lightweight operation but occasionally resolves mysterious build failures as a side effect. For a deeper cache sweep, also remove the Xcode-specific cache folder inside ~/Library/Caches:

rm -rf ~/Library/Caches/com.apple.dt.Xcode

Swift Package Manager keeps its own resolution cache at ~/Library/Caches/org.swift.swiftpm. Removing it forces SPM to re-fetch package metadata on the next build, which is safe but does require an internet connection:

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

Command 4: Prune Old Device Support Files

Every time you plug in a physical iPhone or iPad running a new iOS version, Xcode downloads a "device support" bundle so it can attach a debugger. These bundles live in ~/Library/Developer/Xcode/iOS DeviceSupport (and equivalent folders for tvOS, watchOS, and visionOS) and are never automatically removed. A folder from iOS 14 does you no good in 2026.

Inspect sizes interactively:

du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

Then delete specific old versions, for example:

rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/14.*
rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/15.*

Keep at least the current iOS major version that your active test devices are running. Xcode re-downloads any support files it needs when you reconnect the device.

Command 5: List and Delete Stale Archives

Every time you archive an app for distribution, Xcode writes a bundle to ~/Library/Developer/Xcode/Archives. Unlike the other folders, archives contain your compiled binary and dSYM debug symbols — deleting them means you cannot re-export or re-symbolicate crash reports for that specific build. Before removing anything here, make sure your dSYMs are uploaded to App Store Connect or stored off-machine.

List archives sorted by size:

du -sh ~/Library/Developer/Xcode/Archives/*/*/ | sort -rh | head -20

Remove a specific dated folder (replace the path with your actual archive):

rm -rf ~/Library/Developer/Xcode/Archives/2023-11-04/

A safer alternative is to move old archives to an external drive or cloud storage before deleting, since these are the only copies of your release binaries unless you kept them elsewhere.

How to Check Remaining Space After Cleanup

After running the commands above, confirm what you have reclaimed:

df -h /

For a folder-level breakdown, the following pipeline shows the ten largest directories under your home folder:

du -sh ~/* ~/.* 2>/dev/null | sort -rh | head -10

If you want a visual audit across your whole developer footprint — including Node modules, Cargo caches at ~/.cargo, Maven artifacts at ~/.m2/repository, and Gradle caches — a tool like Crumb can audit all of these at once and show what is safe before you delete, without you having to remember paths across every toolchain. You can also read more about what counts as System Data in macOS storage to understand how these caches appear in System Settings.

Keeping Xcode Lean Going Forward

A few habits prevent the bloat from returning:

• In Xcode, go to Settings > Locations and confirm DerivedData is set to a known location so you can find it easily.
• After every major Xcode update, run xcrun simctl delete unavailable to remove runtimes the new version no longer needs.
• Prefer on-demand simulator runtime downloads (Xcode > Settings > Platforms) rather than installing every available platform.
• Set a quarterly calendar reminder to sweep ~/Library/Developer/Xcode/iOS DeviceSupport for iOS versions that no devices in your test pool are running.
• For CI machines, add a post-build step that removes DerivedData after each run — the build system is faster starting fresh than inheriting stale incremental artifacts anyway.

None of these steps require root access or third-party software. All paths work identically on Apple Silicon and Intel Macs, and all commands are compatible with Xcode 16 and the upcoming Xcode 17 betas targeting macOS Tahoe.