Where is DerivedData, and is it safe to delete?

What is actually in there

One folder per project, each holding compiled objects, module caches, indexes, logs and the built app itself. Xcode never cleans them up: a project you last opened two years ago still has its folder, at full size, and a project you have since deleted still has its folder too.

On the Mac this app was built on, DerivedData was 9.06 GB — the single largest reclaimable thing on the disk, and most of it belonged to scratch projects that no longer existed.

Finding it by hand

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

The second line is the useful one: it names the projects, largest last. A folder whose project you cannot place is the easiest space on the whole machine to get back.

What deleting it costs

• A full rebuild of any project you open next — minutes, not seconds, on a large one.
• The index goes, so Xcode re-indexes before jump-to-definition and autocomplete work properly again.
• Nothing else. No source, no settings, no signing identity. It is output, not input.

Do not delete it while Xcode is building. Removing a build tree mid-build does not just fail the build; it can leave Xcode confused about a target until it is restarted.

The neighbours, which are often bigger

DerivedData is rarely alone. In the same ~/Library/Developer tree sit archives from every distribution build you ever made, device support folders for every iOS version you ever plugged in, and CoreSimulator caches. Simulator runtimes live elsewhere again and are usually the biggest of the lot — see removing old simulator runtimes.

Where the app comes in

RefreshYourMac measures all of them separately, rates DerivedData as a yellow warning — it regenerates, but it costs you that rebuild — and refuses to touch it while Xcode is open. It shows you the folders and their sizes before anything is deleted, and nothing goes without you saying so.