Home › Mac Guides › Xcode DerivedData

Xcode DerivedData: what it is, where it lives, and when to delete it

If you build iOS or macOS apps, Xcode is almost certainly the single largest consumer of disk space on your Mac. Between DerivedData, simulator runtimes, device support files and archives, it is routine to find 60-150 GB of build artefacts that no longer correspond to any project you still work on. Here is exactly what each folder does, what is safe to remove, and what deleting it costs you.

Updated 2026-08-02 · Written by the CleanerMac team · macOS 13–15 tested

What DerivedData actually contains

DerivedData is Xcode's per-project working directory. Every time you build, Xcode writes intermediate object files, module caches, precompiled headers, index data, logs and the finished product into a folder named after your project plus a hash, inside ~/Library/Developer/Xcode/DerivedData. Nothing in there is source code. Every byte of it is regenerated from your project and your dependencies.

That regeneration is the entire trade-off. Deleting DerivedData is completely safe for your source, but your next build will be a full clean build, and Xcode will have to rebuild its code index before autocomplete and jump-to-definition work again. On a large project that can mean ten to thirty minutes of waiting. So the right rule is not delete it constantly, it is delete the folders belonging to projects you have not opened in months.

Where Xcode hides its storage

Two of these deserve extra attention. iOS DeviceSupport grows silently: each device plus OS build combination you attach adds several gigabytes of symbols, and Xcode never removes the old ones. If you have been developing for a few years you may be carrying support files for iOS versions nobody runs any more. CoreSimulator/Devices is the other quiet giant, because every Xcode update creates a fresh set of simulators without deleting the previous generation.

Deleting DerivedData from inside Xcode

1. The gentlest option first: Product menu, hold Option, choose Clean Build Folder (Shift-Command-K cleans, Option turns it into a deeper clean). This removes the workspace's build products while leaving its index intact.
2. For the full folder, open Xcode, Settings, Locations, and click the small arrow next to the Derived Data path. Finder opens the containing folder. Quit Xcode, then delete the project subfolders you no longer need.
3. Safer than Terminal: quit Xcode, press ⇧⌘G in Finder, go to ~/Library/Developer/Xcode/DerivedData and drag the project subfolders to the Trash. Deleting while Xcode is open means you will be deleting files out from under a running indexer and Xcode may behave strangely until you restart it.

Reclaiming simulator space properly

Do not delete ~/Library/Developer/CoreSimulator/Devices by hand. The folder is backed by a plist index, and removing directories without updating it leaves ghost devices in Xcode's device list. Use the supported command instead:

• xcrun simctl delete unavailable removes every simulator whose runtime is no longer installed. This is the single highest-value, lowest-risk command in the whole list, and on a Mac that has survived several Xcode upgrades it commonly frees 10-40 GB.
• xcrun simctl list devices shows what is left, so you can delete specific ones by UDID with xcrun simctl delete <UDID>.
• xcrun simctl erase all resets every simulator to factory state without deleting the devices themselves, which reclaims installed apps and their data.
• Old runtimes themselves live under ~/Library/Developer/CoreSimulator/Profiles/Runtimes and in newer Xcode versions are managed from Xcode, Settings, Components.

When deleting DerivedData actually fixes a bug

Clearing DerivedData has a reputation as the Xcode equivalent of turning it off and on again, and there is a real reason for that. Stale module caches and precompiled headers genuinely do cause a specific family of failures:

• A header or Swift module that you know exists reports as not found.
• Build succeeds but the running app is clearly the previous version.
• Errors referencing a file path that no longer exists after a rename or a branch switch.
• Autocomplete and syntax highlighting stop working while the project still compiles.
• Odd failures immediately after switching Xcode versions or updating a Swift package.

If your problem is not on that list, deleting DerivedData is unlikely to help and will cost you a long rebuild. Try a plain Clean Build Folder first, and reset package caches from File, Packages, Reset Package Caches when a dependency is the suspect.

Other developer folders worth checking

Xcode is not the only offender. Package managers accumulate their own archives, and they are all rebuildable from a lockfile:

• ~/Library/Caches/CocoaPods and per-project Pods directories.
• ~/.swiftpm and per-project .build folders from Swift Package Manager.
• ~/Library/Caches/org.carthage.CarthageKit.
• ~/.gradle/caches and ~/.m2/repository if you also do JVM or Android work.
• node_modules folders scattered across old projects, plus ~/.npm.
• Docker's disk image under ~/Library/Containers/com.docker.docker, which does not shrink on its own and needs pruning from within Docker.

Together these frequently outweigh DerivedData itself. If your startup disk keeps filling despite regular cleanups, this is usually where the space went, and our guide to a full startup disk covers the non-developer half of the problem.

Doing it in one pass with CleanerMac

CleanerMac's Developer Deep Clean covers the biggest of these — DerivedData — showing the size of each project's build folder with the date it was last built, and lets you clear only the stale ones. Projects you have touched recently are protected so you do not accidentally throw away the index for the code you are working on today. Stale build folders are deleted outright, and every folder is listed with its size and last build date before anything is removed.

Once the developer folders are handled, the rest of a typical Mac cleanup is straightforward: see clearing caches safely, finding large files, and the routine in our Mac maintenance checklist.

A sensible cadence

Monthly is plenty for most developers. Run xcrun simctl delete unavailable after every Xcode update, prune iOS DeviceSupport for OS versions you no longer test against, and clear DerivedData for archived projects a couple of times a year. Leave your active project's DerivedData alone unless you are actually debugging a build problem, because a warm index is worth more than the gigabytes it occupies.

Reclaim your developer disk space

See every stale DerivedData folder, simulator and cache in one place.

Download CleanerMac — free for 3 days

macOS 13+ · Apple Silicon & Intel · $24.99 once, no subscription