How to Delete Xcode DerivedData (and Other Xcode Junk)

To delete DerivedData in Xcode, quit Xcode and remove the contents of ~/Library/Developer/Xcode/DerivedData. It only holds build products, indexes and logs, so Xcode rebuilds what it needs on the next build. The same Developer folder also stores device symbols, archives and preview simulators, which is usually why Xcode takes up so much space.

TL;DR

• Check the size first: du -sh ~/Library/Developer/Xcode/DerivedData
• Quit Xcode, then clear it: rm -rf ~/Library/Developer/Xcode/DerivedData/*
• Old iOS DeviceSupport folders are safe to delete for OS versions you no longer debug on.
• Archives are not junk: keep any build you shipped, because its dSYMs symbolicate crash reports.
• SwiftUI preview simulators live in their own device set: xcrun simctl --set previews delete all

Why is Xcode taking up so much space?

The Xcode app bundle itself is a few gigabytes. The growth happens in ~/Library/Developer, where Xcode writes per-project build data, a full simulator device for every simulator you have ever booted, symbol caches for every physical device and OS version you have debugged, and a copy of every archive you have made. Nothing in there is cleaned up automatically, so it only grows.

You can see the big pieces in one command:

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

On a typical setup the biggest lines are DerivedData, CoreSimulator/Devices, iOS DeviceSupport and Archives. Simulators are big enough to need their own guide: see how to delete Xcode simulators and old runtimes.

Where is DerivedData stored?

By default:

~/Library/Developer/Xcode/DerivedData

Inside, each project or workspace gets a folder named after it plus a hash (for example MyApp-abcdefghij), containing Build, Index.noindex, Logs and SourcePackages. There is also a shared ModuleCache.noindex for precompiled modules.

If you moved it, Xcode shows the real location under Xcode > Settings > Locations > Derived Data. The small arrow next to the path opens it in Finder. You can also check from Terminal; if the key is not set, you are using the default path:

defaults read com.apple.dt.Xcode IDECustomDerivedDataLocation

How to clear DerivedData in Xcode

Step 1: see what you are about to delete

du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/DerivedData/* | sort -h

The second command lists every project folder by size, so you can spot the projects you no longer work on.

Step 2: quit Xcode

Xcode keeps files in DerivedData open while a project is loaded. Deleting underneath it can leave the indexer and the build system confused until you restart. Quit Xcode (and any xcodebuild jobs) first.

Step 3: delete it from Terminal

Delete everything:

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

Or delete one project’s folder only:

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

If you would rather be able to undo it, recent macOS versions ship a trash command that moves items to the Trash instead (check with which trash):

trash ~/Library/Developer/Xcode/DerivedData/*

Remember to empty the Trash afterwards, or the space is not freed.

What about Product > Clean Build Folder?

Product > Clean Build Folder (Shift-Command-K) removes the build products for the project you have open. It is the right tool when a build is behaving strangely. It does not remove the index, the logs, the resolved Swift packages or any other project’s folder, so it frees far less space than deleting DerivedData.

What happens after you delete DerivedData?

The next build of each project is a full build, and Xcode re-indexes the project, so code completion and jump-to-definition are slow for a few minutes. Swift packages are resolved and checked out again into the project’s new SourcePackages folder. Nothing in your source tree, your schemes or your signing settings is touched.

What is the iOS DeviceSupport folder?

~/Library/Developer/Xcode/iOS DeviceSupport

When you connect an iPhone or iPad running an OS version Xcode has not seen before, Xcode copies that version’s system symbols from the device so it can debug and symbolicate on it. Each OS version gets its own subfolder (the folder name includes the OS build, and on newer Xcode versions often the device model too), and each one can be a few gigabytes. Similar folders exist for other platforms, such as watchOS DeviceSupport.

Inspect it first:

du -sh ~/Library/Developer/Xcode/"iOS DeviceSupport"/* | sort -h

Delete the folders for OS versions you no longer run on any test device:

rm -rf ~/Library/Developer/Xcode/"iOS DeviceSupport"/<folder-name>

If you plug in a device with that OS version again, Xcode copies the symbols back. It takes a few minutes, but nothing breaks.

Should you delete Xcode archives?

~/Library/Developer/Xcode/Archives

Every Product > Archive creates a dated .xcarchive here. An archive contains the built app and its dSYM files. Those dSYMs are what turn a crash report from a shipped build into readable stack traces, so do not delete archives for versions that are still in users’ hands unless the dSYMs are stored elsewhere (for example, uploaded to your crash reporter or kept in your CI artifacts).

Development and ad-hoc archives you never shipped are safe to remove. The easiest place to review them is Window > Organizer > Archives, which shows each archive’s version and build number. From Terminal:

du -sh ~/Library/Developer/Xcode/Archives/* | sort -h

How to clean up SwiftUI previews

SwiftUI previews run on simulators kept in a separate device set, so they do not show up in the normal simulator list:

~/Library/Developer/Xcode/UserData/Previews/Simulator Devices

List them with simctl by pointing it at the previews set:

xcrun simctl --set previews list devices
du -sh ~/Library/Developer/Xcode/UserData/Previews

With Xcode closed, delete them all:

xcrun simctl --set previews delete all

Xcode creates a fresh preview simulator the next time you open a preview canvas.

Other Xcode folders worth checking

A few smaller caches add up over time:

du -sh ~/Library/Caches/com.apple.dt.Xcode \
       ~/Library/Caches/org.swift.swiftpm \
       ~/Library/Developer/XCTestDevices 2>/dev/null

• ~/Library/Caches/com.apple.dt.Xcode is Xcode’s general cache. Safe to delete with Xcode closed.
• ~/Library/Caches/org.swift.swiftpm holds Swift Package Manager’s shared download cache. Safe to delete; packages download again on the next resolve.
• ~/Library/Developer/XCTestDevices holds simulator clones Xcode creates for parallel testing. Safe to delete with Xcode closed; they are recreated when you run tests in parallel again.

For a wider look at what is safe in ~/Library/Caches, see which Library caches are safe to delete.

Xcode folders at a glance

Path (under ~/Library)	What it is	Safe to delete?	How it comes back
Developer/Xcode/DerivedData	Build products, indexes, logs, package checkouts	Yes, with Xcode closed	Next build and re-index
Developer/Xcode/iOS DeviceSupport	Symbol caches per device OS version	Yes, for OS versions you no longer use	Copied again when you connect that device
Developer/Xcode/Archives	Archived builds and their dSYMs	Only builds you never shipped	Not recoverable; re-archive from source
Developer/Xcode/UserData/Previews	SwiftUI preview simulators	Yes, with Xcode closed	Recreated on next preview
Developer/CoreSimulator/Devices	Simulator devices and their data	Per device, see the simulator guide	Recreated when you add a simulator
Developer/XCTestDevices	Clones for parallel testing	Yes, with Xcode closed	Recreated by parallel test runs
Caches/com.apple.dt.Xcode	Xcode’s general cache	Yes, with Xcode closed	Rebuilt as needed
Caches/org.swift.swiftpm	SwiftPM download cache	Yes	Re-downloaded on next resolve

How to keep Xcode from filling up your disk again

• Delete DerivedData folders for projects you have archived or abandoned, not just the one you are working on.
• After a new major iOS release, remove iOS DeviceSupport folders for versions your test devices no longer run.
• After you ship, make sure the dSYMs are uploaded somewhere, then prune old archives.
• Clean simulators and old runtimes after each Xcode upgrade, because the old runtimes stay behind. The simulator guide covers this.

If space is still missing after all this, a lot of developer data ends up counted as System Data in macOS Storage settings. Why System Data is so large on a Mac explains how to find it. For the full list of developer folders, start with the guide to freeing up space on a Mac for developers.

Do it in one click with DevCleanup

DevCleanup is a native macOS app that finds DerivedData, iOS DeviceSupport folders, simulator caches, old archives and SwiftUI preview data in one scan and lets you pick what goes. Smart Clean puts the regenerable items (DerivedData, device support files and simulator caches) in one “Xcode Junk” list you confirm once, and it’s free. Archives and SwiftUI previews live on the Toolchains screen under Xcode, where archives are never pre-selected because you may need them to symbolicate crash reports. Every deletion is logged in History with how to restore it.

Download DevCleanup