Is it safe to delete Xcode’s DerivedData folder?

By Mohit Nippanikar, who makes SiftMac

1. What’s inside

By default Xcode keeps derived data for every project in one place:

~/Library/Developer/Xcode/DerivedData

Each project gets its own subfolder, named after the project plus a string of letters, for example MyApp-abcdefghijklmnop. Inside are its build products and intermediate build files, the index that powers code completion and search, build logs, and Xcode’s copies of the Swift packages it uses. None of it is your code. Xcode › Settings › Locations shows where your Mac keeps it, and the small arrow next to the path opens it in Finder.

2. How big it is on your Mac

It grows with every project you’ve ever built, including ones you finished years ago, and often reaches tens of gigabytes. To see the total, and each project biggest last:

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

3. How to delete it

1. Quit Xcode, so it isn’t writing to the folder while you delete it.
2. In Finder, choose Go › Go to Folder (⇧⌘G), paste ~/Library/Developer/Xcode/DerivedData, and press Return.
3. Move the project folders inside it to the Trash: all of them, or only the ones for projects you no longer work on. Then empty the Trash.

Or in Terminal, with Xcode quit, to clear all of it at once:

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

For one project you have open, Product › Clean Build Folder (⇧⌘K) clears its build products without leaving Xcode. It leaves the index and the downloaded packages in place.

4. What happens afterwards

• The next build of each project starts from scratch, so it takes as long as a first build.
• Xcode indexes the project again. Code completion, jump to definition and search catch up when it finishes.
• Swift packages are fetched again, so the first open needs an internet connection.
• Your source code, project settings and schemes are untouched: they live in your project folder.

Deleting DerivedData is also the classic fix when Xcode acts up: builds that fail for no reason, previews that won’t load, or an index stuck on old code.

5. What to keep instead: Archives

Next to DerivedData, ~/Library/Developer/Xcode/Archives holds what Product › Archive made: the builds you shipped, with their debug symbols (dSYMs), which turn a crash report into readable code. That folder is You decide, not a cache. It doesn’t come back, so keep the archives of any version people still run. The other big folders in ~/Library/Developer, simulators and device support files, are covered in DerivedData, node_modules and Docker: what’s safe to delete.

Questions

Does deleting DerivedData delete my code?

No. Your code lives in your project folder. DerivedData holds only what Xcode made from it.

Should I delete it regularly?

Only when you need the space or Xcode misbehaves. Folders of projects you no longer build can go any time; the current project’s folder is worth keeping, since rebuilding it costs you time.

Will it break my app on the App Store or TestFlight?

No. Those builds were uploaded from your archive. Just keep the Archives folder as above.