Clear Xcode DerivedData, simulators and old runtimes

How much space is Xcode using?

Xcode's own app in /Applications is only part of it. Most of the space it uses over time sits in your Library folder, in folders that grow with every build, every simulator and every device you connect. One command shows the main ones:

# the big Xcode folders in your home folder, largest first
$ du -sh ~/Library/Developer/Xcode/* ~/Library/Developer/CoreSimulator/* 2>/dev/null | sort -hr | head -12

Simulator runtimes won't appear in that list, because they're stored outside your home folder; xcrun simctl runtime list shows them with their sizes. The rest of this guide goes through each folder in order of how safe it is to clear.

What is DerivedData, and is it safe to delete?

Every project you build leaves its intermediate files, compiled modules, the code index that powers autocomplete, and build logs in DerivedData. Each project gets its own subfolder, named after the project plus a hash, and Xcode never removes old ones by itself. On an active developer Mac it commonly reaches somewhere between 1 and 30 GB, and more if you build many projects or large dependency graphs.

The default location is ~/Library/Developer/Xcode/DerivedData. If you've moved it, check Xcode > Settings > Locations (called Preferences in Xcode 13 and earlier); the small arrow next to the Derived Data path opens it in Finder.

# see how big it is
$ du -sh ~/Library/Developer/Xcode/DerivedData

# biggest projects inside it
$ du -sh ~/Library/Developer/Xcode/DerivedData/* 2>/dev/null | sort -hr | head

# move it to the Trash (quit Xcode first)
$ mv ~/Library/Developer/Xcode/DerivedData ~/.Trash/

To clear only the current project's build folder, use Product > Clean Build Folder in Xcode (Shift-Command-K). It's lighter than removing DerivedData and enough when a single build is misbehaving.

Shedi finds all of this in about 10 secondsDerivedData, unusable simulators, old device support and runtimes, every item explained. Everything goes to the Trash first.

Get Shedi

How do I delete old simulators?

Simulator devices (each iPhone, iPad or Watch you've ever created or that Xcode created for you) live in ~/Library/Developer/CoreSimulator/Devices. Each holds the apps you installed into it and their data. When you update Xcode or delete a runtime, devices for runtimes that are gone become unavailable: they still take space, but you can't boot them.

List them first, then delete them:

# see which simulator devices Xcode can no longer run
$ xcrun simctl list devices unavailable

# delete them
$ xcrun simctl delete unavailable

Don't delete folders from CoreSimulator/Devices by hand: the simulator service keeps its own list and will complain about missing devices. Use simctl.

How do I delete old simulator runtimes?

Runtimes are the big part. Each one is a full copy of iOS, watchOS, tvOS or visionOS for the simulator, typically several gigabytes. Since Xcode 14 they're installed as disk images outside your home folder, managed by the system, which is why you won't find them by searching ~/Library and why you shouldn't delete them from Finder.

In Xcode: choose Xcode > Settings, then click Components in the sidebar (older Xcode versions call this pane Platforms). Apple's docs say Xcode shows each installed component "along with the amount of storage you can recover if you remove them". Click the info button next to a runtime under Other Installed Platforms, then Delete.

In Terminal:

# list installed runtimes with their sizes
$ xcrun simctl runtime list

# preview what would be deleted: runtimes not used in 90 days
$ xcrun simctl runtime delete --notUsedSinceDays 90 --dry-run

# delete one runtime by the identifier shown in the list
$ xcrun simctl runtime delete <identifier>

The --notUsedSinceDays and --dry-run options are in Xcode 26's simctl; older versions may not have them, so check with xcrun simctl help runtime.

If a deleted runtime keeps reappearing after a restart, that's a known issue discussed on Apple's developer forums. Don't try to remove it from system folders by hand; many of those locations are protected by System Integrity Protection.

What is iOS DeviceSupport, and can I delete it?

When you connect a physical iPhone, iPad, Apple Watch or Apple TV to Xcode for the first time on a new OS version, Xcode copies that version's debug symbols to your Mac so it can debug apps on it. They land in folders such as:

• ~/Library/Developer/Xcode/iOS DeviceSupport
• ~/Library/Developer/Xcode/watchOS DeviceSupport
• ~/Library/Developer/Xcode/tvOS DeviceSupport

There is one subfolder per OS version and build, and even small updates add a new one. The open-source DevCleaner project estimates 2–5 GB per version.

# one line per OS version, largest first
$ du -sh ~/Library/Developer/Xcode/*DeviceSupport/* 2>/dev/null | sort -hr

# move one old version to the Trash
$ mv ~/Library/Developer/Xcode/iOS\ DeviceSupport/<old-version-folder> ~/.Trash/

Should I delete old Xcode Archives?

Archives (~/Library/Developer/Xcode/Archives, organized in dated folders) are what you create with Product > Archive for TestFlight, the App Store or an export. Each one holds the built app and its dSYM debug symbols. You need those symbols to turn crash reports from that release into readable stack traces.

See them in Window > Organizer > Archives, where you can right-click one and choose Show in Finder or delete it.

# size of each month's archives
$ du -sh ~/Library/Developer/Xcode/Archives/* 2>/dev/null

Smaller Xcode folders worth knowing

• SwiftUI Previews (~/Library/Developer/Xcode/UserData/Previews): simulator data used for previews; it's recreated when you open a preview again. Only this subfolder: the rest of UserData holds your key bindings, themes and provisioning profiles.
• Swift Package Manager cache (~/Library/Caches/org.swift.swiftpm): downloaded package sources shared across projects. swift package purge-cache clears it, or use File > Packages > Reset Package Caches in Xcode for the current project.
• Old Xcode versions in /Applications, such as a leftover Xcode-beta.app. Each is a large app on its own; delete the ones you don't use like any other app.

For the full list across every developer tool, including CocoaPods, Carthage and Homebrew, see Every developer cache you can safely delete on macOS.

What should I not delete?

• ~/Library/Developer as a whole. It contains your provisioning profiles, key bindings, simulator devices you may still use, and Archives.
• Runtime disk images from system folders. Use Xcode's Components pane or simctl.
• Archives you might still need for symbolication or re-uploading.

Putting it together

A typical cleanup, in order of safety:

# 1. DerivedData (quit Xcode first)
$ mv ~/Library/Developer/Xcode/DerivedData ~/.Trash/

# 2. simulators Xcode can no longer run (deletes immediately)
$ xcrun simctl delete unavailable

# 3. review runtimes, then delete the ones you don't test on
$ xcrun simctl runtime list

Then review DeviceSupport and Archives by hand. When you've built and run your project once and everything works, empty the Trash. Xcode is usually only part of a developer Mac's storage problem (the general Mac guide covers the rest); Docker and node_modules are often next. If you'd rather see it all in one list, with each item explained before anything moves, that's what Shedi does.

Sources

• Apple Developer: Downloading and installing additional Xcode components
• xcrun simctl help delete and xcrun simctl help runtime (Xcode 26.6)
• Apple Developer Forums: How to delete iOS simulator runtimes?
• DevCleaner for Xcode README (DeviceSupport sizes)