Every build writes thousands of intermediate files into ~/Library/Developer/Xcode/DerivedData: object files, module caches, indexes that power jump to definition, test logs and debug symbols. Xcode creates one folder per project and never deletes any of them. On a machine that has been doing iOS or macOS work for a couple of years, this is regularly the largest single folder in your home directory.
The tell is usually an unexplained drop in free space that shows up as System Data in Apple's Storage panel, because that category is a catch all for anything macOS cannot label.
Measure it before you touch it
du -sh ~/Library/Developer/Xcode/DerivedDataOn a developer Mac two years old, expect somewhere between 15GB and 80GB. To see which projects are responsible, sort the subfolders by size:
du -sh ~/Library/Developer/Xcode/DerivedData/* | sort -hr | head -15Each folder is named after the project plus a hash, so a 25GB entry belonging to a prototype you abandoned last spring is easy to spot. Nothing in that folder is a source of truth. It is all rebuildable output.
What is safe to delete
All of it. Xcode rebuilds DerivedData automatically the next time you open a project. The only cost is that the first build afterwards is a full build rather than an incremental one, which on a large workspace can mean a few extra minutes once.
rm -rf ~/Library/Developer/Xcode/DerivedData/*Quit Xcode first so nothing is holding an open file handle. If you would rather keep the cache for your current project, delete the individual hashed folders you identified in the sorted list instead of the whole directory.
The folder people forget: iOS DeviceSupport
Each time you plug in a physical device running an iOS version Xcode has not seen before, Xcode copies the debug symbols for that version into ~/Library/Developer/Xcode/iOS DeviceSupport. Every version you have ever tested against stays there.
du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupportA machine that tested iOS 14 through iOS 19 can hold 20GB to 40GB of symbol folders here, and you only ever need the ones matching the devices you still use. Deleting them is safe: connect the device again and Xcode recreates what it needs.
Simulators and runtimes are a separate bill
Simulator data lives under ~/Library/Developer/CoreSimulator and is often larger than DerivedData, especially if you download every runtime Xcode offers.
du -sh ~/Library/Developer/CoreSimulator
xcrun simctl delete unavailableThe first command tells you the damage, the second removes simulator devices whose runtime no longer exists. To remove old runtimes themselves, use Xcode Settings, then Components or Platforms, depending on your Xcode version.
DerivedData, iOS DeviceSupport and simulator caches all appear in the Clean tab under a single Developer group. On the machine in our screenshots that group alone held 102.21 GB of 120.72 GB, with 11 of 12 items selected by default. You see each path and size, then confirm before anything is removed.
Stopping it from coming back
Apple ships no setting to cap DerivedData or expire old entries. Three habits keep it under control:
- Point scratch builds at a temporary path with
xcodebuild -derivedDataPath /tmp/ddso only your real projects use the default location. - Delete the hashed folder for a project the day you stop working on it, not six months later.
- Re-check the size monthly. It is a metric worth watching, the same way you watch free space on a server.
If you would rather not remember any of this, macoptimize rescans those folders on demand and keeps a dated log of what came back each time, so you can see the growth curve instead of guessing at it.
Where else Xcode quietly stores gigabytes
DerivedData is the headline, but it is not the only folder Xcode owns. Run one command and you get the whole picture:
du -sh ~/Library/Developer/Xcode/* ~/Library/Developer/CoreSimulator ~/Library/Caches/com.apple.dt.Xcode 2>/dev/null | sort -hr| Location | Typical size | Safe to delete |
|---|---|---|
| Xcode/DerivedData | 15GB to 80GB | Yes |
| Xcode/iOS DeviceSupport | 10GB to 40GB | Yes |
| CoreSimulator/Devices | 5GB to 60GB | Recreate as needed |
| Xcode/Archives | 5GB to 50GB | No, keep these |
| CoreSimulator/Caches | 1GB to 15GB | Usually |
| ModuleCache.noindex | 1GB to 10GB | Yes |
Archives are different. ~/Library/Developer/Xcode/Archives holds the packaged build of every app you have ever shipped, plus the dSYM files that symbolicate crash reports from TestFlight and the App Store. Delete them and those crashes become unreadable forever. They are also the only folder in that list you cannot regenerate from source without checking out the exact commit and rebuilding. Trim old archives only after you have uploaded the dSYMs somewhere durable.
A two minute routine that keeps it flat
Once a month, in this order:
xcrun simctl delete unavailableto drop devices whose runtime is gone.rm -rf ~/Library/Developer/Xcode/DerivedData/*with Xcode closed.- Delete the
iOS DeviceSupportfolders for iOS versions none of your test devices run any more. - In Xcode Settings, open Components or Platforms and remove the simulator runtimes you never boot.
Then measure again with the du line at the top of this section, so you can see the number move instead of assuming it did.
What the next build actually costs you
Clearing DerivedData does not slow Xcode down permanently, but the first build afterwards is a full build. Expect roughly 2 to 8 minutes for a mid sized app, 15 minutes or more for a large workspace with SwiftUI previews and a few modules. The index rebuilds in the background while you work, so jump to definition feels slow for the first few minutes and then returns to normal.
Two things do not change: your source is untouched, and the next build after that one is incremental again.
When clearing DerivedData is the actual fix
It is the standard first step for a specific class of Xcode problems, not just a space saving move. Clear it when the editor shows errors that do not match the source, when SwiftUI previews render stale layouts, when a new file is not visible to the compiler, or when auto complete is confidently wrong. In each of those cases the cached index has drifted from the project, and rebuilding it is faster than debugging it.
FAQ
Does deleting DerivedData break my project?
No. DerivedData contains build output and indexes only. Source files, storyboards, assets and package definitions live in your project folder. The next build simply takes longer because everything is compiled again.
Can I delete DerivedData while Xcode is running?
Quit Xcode first. Deleting files that an open build holds can leave that build in a confused state and force a clean.
How often does DerivedData need clearing?
For a developer switching between several projects, monthly is reasonable. If you work in one repo and rarely branch, every few months is enough. Watch the total size rather than the calendar.
Should I delete the Xcode Archives folder?
No. Archives hold your shipped builds and the dSYM files that turn crash reports into readable stack traces. Trim old archives only once the dSYMs are stored somewhere you control, and never delete the archive for a version still live on the App Store.
How long will the first build be after clearing DerivedData?
A small project takes a couple of minutes. A large workspace with several modules can take 15 minutes or more, plus a few minutes while the index rebuilds in the background. Every build after that is incremental again.
Does clearing DerivedData fix Xcode errors?
Sometimes, and it is worth trying early rather than late. Stale indexes cause wrong error markers, dead auto complete and previews that show old code. Clearing the cache rebuilds the index from the current source, which resolves that whole category of confusion.