Xcode DerivedData.
Safe to delete?

By default, Xcode keeps it in your Library folder, at ~/Library/Developer/Xcode/DerivedData. The Library folder is hidden in Finder, so the quickest way there is Go → Go to Folder (⇧⌘G) and paste the path.

You can move it. In Xcode, choose Xcode → Settings → Locations. The Derived Data setting is Default, Relative (to the workspace) or Custom (an absolute path), and the current path is shown under it. A single workspace can also override it in File → Workspace Settings (Project Settings for a lone project). If you set a custom path, Xcode stores it in its preferences, and you can read it from Terminal:

defaults read com.apple.dt.Xcode IDECustomDerivedDataLocation

“Does not exist” in the answer means you never changed it, and the default path applies.

There is a third place people forget. xcodebuild -derivedDataPath <path> builds into whatever folder you name, and Xcode's settings know nothing about it. CI scripts, release scripts and coding agents often use it to keep builds apart, which leaves a full DerivedData folder inside the project, under any name: build, .build, ci-output. Each of those folders has a Build/Intermediates.noindex folder inside, so you can find them by that:

find ~/Developer -type d -path '*/Build/Intermediates.noindex' -prune \
  | sed 's|/Build/Intermediates.noindex$||'

Replace ~/Developer with the folder that holds your projects. Each line printed is a folder an Xcode build wrote into.

One folder per project, named after the project with a hash appended, such as MyApp-dkzfqqfgbyhdrjgqtoxkvbmsmlgp, plus a few caches shared by all projects. Spaces in the project name become underscores. Each project folder has an info.plist whose WorkspacePath says which project on disk it belongs to:

plutil -p ~/Library/Developer/Xcode/DerivedData/MyApp-*/info.plist

The folder is tied to the project's path, so a second clone of the same repository, a git worktree or a project you moved gets a folder of its own. The old one stays behind.

Xcode 26 also keeps a few more shared folders at the top level, such as SymbolCache.noindex and CompilationCache.noindex. They are caches too.

The total, then each project, smallest to largest:

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

The second list is the useful one. It usually shows a few projects you work on every day and a long tail of projects you opened once, tutorials, old clones and folders whose project no longer exists. If you moved DerivedData, use your custom path instead.

Yes. Everything in it is generated from your project, and Xcode creates what it needs again on the next build. Your source code, schemes, breakpoints and project settings live in the project itself, not here. Two conditions: quit Xcode first, so nothing is building or indexing into the folder while it disappears, and know what you are trading.

What deleting a project's folder costs:

• A full rebuild. The next build compiles everything from scratch, which for a large app can take many minutes instead of seconds.
• Reindexing. Completion, Jump to Definition and Open Quickly are slow or incomplete until Xcode has indexed the project again.
• Package resolution. Xcode resolves your Swift packages again and fetches what it no longer has.
• Old logs and test results. Build logs and .xcresult bundles in Logs are gone for good. If you need a test report, export it first.

Deleting the shared ModuleCache.noindex adds one more cost: the next build of every project rebuilds the modules for the system frameworks.

So the cheap win is the folders of projects you are not working on this week. Deleting the folder of the app you are building today only buys you a slow afternoon.

Product → Clean Build Folder (⇧⌘K) is narrower. Xcode describes it as removing build products and intermediate files for the project you have open. It is the right first step when a build behaves strangely, and it leaves the index, logs and package checkouts alone. Clean Build Folder Immediately (⌥⇧⌘K) does the same without asking first.

Quit Xcode. To remove one project's folder, name it; the wildcard covers the hash:

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

To empty all of it:

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

rm -rf deletes at once, without the Trash. Check the path twice, and if you use a custom location, use that path instead. If you prefer a way back, open the folder in Finder and drag the project folders to the Trash; the space comes back when you empty it.

A folder that xcodebuild -derivedDataPath created inside a project is cleared the same way: delete that folder, and the next build with the same path recreates it.

Two neighbors of DerivedData grow the same way and come back the same way.

SwiftPM's global cache

Swift Package Manager keeps a shared cache of the package repositories and manifests it fetched in ~/Library/Caches/org.swift.swiftpm. Its own command clears it:

du -sh ~/Library/Caches/org.swift.swiftpm
swift package purge-cache

The next package resolution downloads again what it needs.

SwiftUI previews

Xcode runs SwiftUI previews in simulator devices of their own, kept in ~/Library/Developer/Xcode/UserData/Previews. simctl can list and delete them as a separate device set:

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

Quit Xcode before deleting them. Xcode creates new preview devices the next time you open a preview, which then takes a little longer to appear. For the regular simulators, see simulators and DeviceSupport.

• Every project path gets its own folder, so clones and worktrees multiply DerivedData. Delete the folders of clones you removed.
• Builds with -derivedDataPath that use a new folder per run pile up fast. Reuse one path per project, or delete the folder when the run is done.
• Clear the folders of projects you have not built in a couple of weeks, rather than everything at once. You get most of the space back and keep today's build fast.

DerivedData is rarely the only thing filling an Apple developer's disk. If space is already tight, start with “Your disk is almost full”, and see package manager caches for Homebrew, npm and friends.

Specula lists ~/Library/Developer/Xcode/DerivedData as regenerable, with a note to delete it while Xcode is closed. Its one-click Clean Up plan does not empty it: it offers the project folders nobody built for 14 days, checked by default, and leaves recent projects alone, so current work does not rebuild.

It also finds Xcode build folders inside your projects: any folder named DerivedData, or any folder Xcode or xcodebuild -derivedDataPath built into, whatever its name. Those not built for 3 days, judged by the newest entry in their Logs and their info.plist, are checked by default; recent ones are offered unchecked. The Old versions page groups App-<hash> folders of the same project in DerivedData, the leftovers of clones and moved projects. The SwiftPM cache and the previews folder are regenerable caches Specula offers as well.

Nothing is deleted without a confirmation, and you choose between the Trash and deleting permanently.