Is it safe to delete Xcode DerivedData?

Yes. DerivedData only holds build products, indexes and logs, and Xcode recreates it on the next build. Expect a slower first build and a few minutes of indexing per project.

Where is DerivedData on a Mac?

By default it is in ~/Library/Developer/Xcode/DerivedData, with one folder per project. Xcode shows the exact path under Settings > Locations.

How do I delete old iOS simulators?

Run xcrun simctl delete unavailable in Terminal to remove simulators for runtimes you no longer have. Remove whole runtimes in Xcode under Settings > Components, or with xcrun simctl runtime delete. Avoid deleting folders inside CoreSimulator by hand.

Can I delete the iOS DeviceSupport folder?

You can delete the subfolders for iOS versions your devices no longer run. Xcode copies the symbols again the next time you debug a device on that version, which takes a few minutes.

Should I delete Xcode Archives?

Only for builds you no longer need to support. Each archive holds the dSYM files that turn crash reports into readable stack traces, so keep archives for versions people still use unless those dSYMs are stored elsewhere.

Why does Xcode use so much storage?

Besides the app itself, Xcode keeps build files for every project, a simulator runtime for each OS version you test on, and debug symbols for every device and iOS version you connect. None of it is removed automatically.

How to free up space from Xcode: DerivedData, simulators and device support

Most of the space Xcode uses sits in four places inside ~/Library/Developer: DerivedData, simulators and their runtimes, device support files, and Archives. DerivedData is always safe to delete because Xcode rebuilds it. Remove simulators with xcrun simctl or Xcode's own settings, and keep any Archives for builds you have shipped.

Where Xcode keeps its files

Xcode itself lives in /Applications and is usually 10 to 15 GB or more. You can't shrink that part. The space that grows over time is in your home folder, mostly under ~/Library/Developer. Open it in Finder with Go > Go to Folder (Shift-Command-G) and paste the path.

~/Library/Developer/Xcode/DerivedData: intermediate build products, indexes and logs, one folder per project. Every project you have ever opened leaves one behind.
~/Library/Developer/CoreSimulator/Devices: one folder per simulator device, with the apps and data you installed on it.
Simulator runtimes: the iOS, watchOS, tvOS and visionOS system images that simulators boot. Recent versions of Xcode store these as disk images managed by the system, not as plain folders you should touch.
~/Library/Developer/Xcode/iOS DeviceSupport (and the watchOS and tvOS versions): debug symbols copied from each physical device and OS version you have connected for debugging.
~/Library/Developer/Xcode/Archives: every build you made with Product > Archive, including the debug symbols (dSYMs) for it.
Caches: ~/Library/Caches/com.apple.dt.Xcode and Swift Package Manager's cache in ~/Library/Caches/org.swift.swiftpm.

To see how big each one is, run this in Terminal. It only reads sizes and changes nothing.

du -sh ~/Library/Developer/Xcode/* ~/Library/Developer/CoreSimulator 2>/dev/null

What is safe to delete, and what it costs

DerivedData: safe. Xcode recreates it on the next build. The cost is time: the first build of each project is a clean build, and indexing runs again, so autocomplete and search are slow for a few minutes.
Unavailable simulators: safe. These are simulators for runtimes you no longer have installed. They can't be booted anyway.
Old simulator runtimes: safe if you don't test on them. You can download a runtime again from Xcode later. The cost is a multi-gigabyte download.
Old device support folders: usually safe. Folders for iOS versions your devices no longer run are dead weight. Xcode copies the symbols again the next time you debug a device on that version, which takes a few minutes.
Xcode caches: safe. Package caches mean Swift packages are downloaded again on the next resolve.
Archives: not automatically safe. See the warning below.

Step by step with built-in tools

1. Quit Xcode and the Simulator

Deleting build folders while Xcode is building or indexing can leave it confused. Quit both apps first.

2. Clear DerivedData

The simplest way is in Finder. Go to ~/Library/Developer/Xcode/DerivedData, select the project folders you don't need (or all of them) and move them to the Trash. You can also find the path in Xcode under Settings > Locations, with an arrow that opens it in Finder. For one project, Product > Clean Build Folder (Shift-Command-K) clears its build products without leaving Xcode.

If you prefer Terminal, this deletes the whole folder at once. It skips the Trash, so the files are gone immediately. Only run it if you are sure.

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

3. Remove simulators the right way

Don't delete folders inside CoreSimulator by hand. Simulators are tracked in a database, and removing their folders leaves Xcode listing devices that no longer exist. Use simctl, which ships with Xcode.

First, list what you have:

xcrun simctl list devices

This removes every simulator whose runtime is no longer installed. It doesn't touch simulators you can still boot.

xcrun simctl delete unavailable

To remove one specific simulator, copy its ID from the list above and run xcrun simctl delete followed by that ID. You can also delete simulators in Xcode under Window > Devices and Simulators. If you want to keep your simulators but wipe the apps and data inside them, xcrun simctl erase all resets every simulator to a clean state. Run it only if you don't need anything installed on them.

4. Remove old simulator runtimes

Runtimes are usually the biggest single item. In Xcode, open Settings and go to Components (called Platforms in Xcode 15). Select a runtime you no longer need and click the minus button. In Terminal, list the runtimes and their identifiers with:

xcrun simctl runtime list

Then remove one by passing its identifier to xcrun simctl runtime delete. Some developers report runtimes that stay stuck in a "Deleting" state or don't appear in either list. Restarting the Mac and checking again often helps. Don't try to delete runtime files from system folders yourself.

5. Trim device support

Open ~/Library/Developer/Xcode/iOS DeviceSupport. Each folder name includes a device model and an iOS version. Move folders for versions your devices no longer run to the Trash. If you still debug on an older device, keep its folder.

6. Empty the Trash

Moving items to the Trash doesn't free any space until you empty it. Check the folders in the Trash one more time, then empty it. If free space still doesn't rise, Time Machine local snapshots may be holding the old files. See how to delete Time Machine local snapshots.

What not to delete

Archives you have shipped

Each archive in ~/Library/Developer/Xcode/Archives holds the dSYM files for that build. You need them to turn crash reports from that version into readable stack traces. If a version is still in users' hands and its dSYMs aren't uploaded somewhere else (App Store Connect, or a crash reporting service you use), keep the archive. Delete old archives from Xcode under Window > Organizer rather than Finder, so you can see the version and date of each one. Archives for test builds that never shipped are fine to remove.

The Xcode app bundle

Don't remove files from inside Xcode.app to save space. If you have more than one copy of Xcode, such as a beta, delete the version you don't use from Applications instead.

Simulator data you still need

If a simulator holds test accounts or app data you rely on, erase and delete remove it. Back up anything you need first.

How much space you can expect

It depends on how many projects, Xcode versions and runtimes you have. DerivedData grows with every project you build. Each simulator runtime is several gigabytes. Device support folders are often a few gigabytes each. Developers who have used Xcode for a few years often find tens of gigabytes across these folders, and a lot of it shows up in macOS Storage settings as System Data or Developer.

None of this stays gone forever. DerivedData fills again as you work, so it's worth checking every few months. If you also use other developer tools, the same idea applies to node_modules folders and Docker's disk image.

Seeing it all in one place

The steps above work with nothing extra installed. If you want to see everything at once, freedisk.space scans your disk and groups developer folders by tool and project in its Developer Storage view. It marks DerivedData as rebuilt on the next build, and marks simulators and device support as worth reviewing. If you add the simulator folder to Cleanup, it warns that the Trash would damage the simulator database and shows xcrun simctl delete unavailable instead. It also notes that the Archives folder holds your dSYMs and sends you to the Organizer instead. Nothing is deleted from the app directly: you add items to a Cleanup list, review them, and confirm before they move to the Trash, where Put Back still works.

Questions people ask

Is it safe to delete Xcode DerivedData?: Yes. DerivedData only holds build products, indexes and logs, and Xcode recreates it on the next build. Expect a slower first build and a few minutes of indexing per project.
Where is DerivedData on a Mac?: By default it is in ~/Library/Developer/Xcode/DerivedData, with one folder per project. Xcode shows the exact path under Settings > Locations.
How do I delete old iOS simulators?: Run xcrun simctl delete unavailable in Terminal to remove simulators for runtimes you no longer have. Remove whole runtimes in Xcode under Settings > Components, or with xcrun simctl runtime delete. Avoid deleting folders inside CoreSimulator by hand.
Can I delete the iOS DeviceSupport folder?: You can delete the subfolders for iOS versions your devices no longer run. Xcode copies the symbols again the next time you debug a device on that version, which takes a few minutes.
Should I delete Xcode Archives?: Only for builds you no longer need to support. Each archive holds the dSYM files that turn crash reports into readable stack traces, so keep archives for versions people still use unless those dSYMs are stored elsewhere.
Why does Xcode use so much storage?: Besides the app itself, Xcode keeps build files for every project, a simulator runtime for each OS version you test on, and debug symbols for every device and iOS version you connect. None of it is removed automatically.