How to Clean Xcode DerivedData &
Free Up Gigabytes on Your Mac

What Is DerivedData — and Why Does It Keep Growing?

Every time you build a target in Xcode, the compiler produces a large amount of intermediate output: compiled object files (.o), Swift module interfaces (.swiftmodule), pre-compiled headers, dependency graphs, index-store data for code completion, and the final linked binary. Rather than mixing these outputs with your source tree, Xcode stores all of them in a separate cache directory called DerivedData.

The idea is smart: by caching intermediate build products, Xcode can perform incremental builds — only recompiling files that have actually changed since the last build. On a large project with hundreds of Swift files, this can cut a full rebuild from several minutes down to a few seconds.

The problem is accumulation. Xcode creates a new subdirectory for every project it has ever opened, named with the project name plus a hash of its location on disk. If you rename a project, move it to a different folder, or clone a fresh copy from Git, Xcode creates a brand-new DerivedData folder rather than reusing the old one. The orphaned folder is never cleaned up automatically. Over months and years of active development, it is completely normal to find DerivedData directories for dozens of projects you no longer work on — or even no longer have on your machine.

Where DerivedData Lives

By default, DerivedData is stored at:

~/Library/Developer/Xcode/DerivedData/

You can confirm — or change — this location in Xcode under Xcode → Settings → Locations → Derived Data. Unless you have explicitly moved it, it will be at the default path above. Inside, you will find one or more subdirectories named after your projects, for example:

~/Library/Developer/Xcode/DerivedData/
  MyApp-abcdefghijklmnop/
  MyApp-qrstuvwxyz012345/     ← same project, different path
  OldClient-hjklmnopqrst/
  SomeOpenSourceLib-uvwxyz/

Each of those subdirectories can be anywhere from a few hundred megabytes for a small app to several gigabytes for a large project with many targets, frameworks, and test plans.

The Full Map of Xcode's Hidden Disk Usage

DerivedData is the biggest offender, but it is far from the only one. Here is a complete picture of every location Xcode uses to store data on your Mac, how large each one typically grows, and whether it is safe to delete.

DerivedData: Safe to Delete? Absolutely Yes.

This is the most common question developers ask, and the answer is unambiguous: DerivedData is entirely safe to delete at any time. It contains no source code, no project configuration, no signing certificates, and nothing that cannot be regenerated automatically.

When you delete DerivedData and open your project in Xcode again, Xcode will simply rebuild from scratch the next time you press Cmd+B. Your first build after deletion will take longer than usual — equivalent to a clean build — but all subsequent incremental builds will be as fast as before as the cache is repopulated.

Xcode Archives: Keep the Ones That Matter

Archives are different. Located at ~/Library/Developer/Xcode/Archives, each archive is a self-contained snapshot of a release build, complete with the compiled binary, its dSYM symbol file, and entitlements. Archives are what you upload to App Store Connect and what App Store Connect uses to create your app's distribution binary.

The dSYM (debug symbols) inside an archive are critically important: if a crash report comes in from a user running a version you shipped six months ago, the only way to symbolicate that crash — to turn raw memory addresses into readable function names and line numbers — is to have the matching dSYM for that exact binary. Without it, crash reports are unreadable.

Archives from discontinued projects, internal prototypes that were never shipped, or Xcode's automatic archives from running on a physical device in debug mode are almost always safe to remove.

iOS Simulator Data: The Hidden Storage Hog

The iOS Simulator is essentially a full virtual iPhone or iPad running on your Mac. Every simulator device you have ever booted — and there are often dozens, spanning multiple iOS versions and device types — maintains its own virtual disk image stored under ~/Library/Developer/CoreSimulator.

This directory has two major components:

CoreSimulator/Devices

Each virtual device has its own UUID-named folder here. If you have ever run a simulator for iPhone 13, iPhone 14, iPhone 15, iPhone 15 Pro, iPad Pro, and various iOS versions from 15 through 18, that is easily 30 or more virtual devices. Each one stores installed apps, sandboxed app data, and system state. On a machine that has been in active use for two or three years, this folder alone can exceed 15 GB.

CoreSimulator/Caches

This folder stores disk images for simulator runtimes. If you have ever downloaded an older runtime to test an edge case on iOS 15 or iOS 16, those disk images remain on disk permanently unless manually removed. A single simulator runtime image (e.g., "iOS 15.5 Simulator") can be 3–7 GB on its own.

You can safely delete simulators for iOS versions you no longer test against. Xcode will prompt you to re-download the runtime if you ever need it again.

iOS DeviceSupport: Symbol Files for Every iOS Version

Stored at ~/Library/Developer/Xcode/iOS DeviceSupport, this folder contains a complete copy of the debug symbol libraries (.dylib files) for every iOS version you have ever connected a physical device running. Xcode downloads these the first time you plug in a device running a new iOS version, and they are used for on-device debugging.

A single iOS version's symbol set is typically 1–2 GB. If you have connected devices running iOS 14, 15, 16, 17, and 18 (plus minor versions), you can easily have 10–12 GB of symbol files. The ones you do not need are for iOS versions you no longer debug against — typically anything more than two major versions old. Deleting them forces Xcode to re-download them if you connect a device running that version again, but for most developers that never happens.

Manual Cleanup Steps: Exact Commands

You can clean all of these locations manually from the Terminal. Here are the exact steps, in the safest order:

1. Quit Xcode first Always quit Xcode before deleting any of these directories. If Xcode is writing to DerivedData during a build when you delete it, you may get a corrupted build state.
2. Delete DerivedData entirely This is the safest and highest-impact action. Run the following command in Terminal: rm -rf ~/Library/Developer/Xcode/DerivedData
3. Use Xcode's built-in cleaner for Simulators Open Xcode, go to Window → Devices and Simulators, select any simulator you no longer need, and click the minus (−) button. Alternatively, run: xcrun simctl delete unavailable
4. Delete old iOS DeviceSupport versions Open Finder, press Cmd+Shift+G, paste the path, then manually delete folders for iOS versions you no longer support: ~/Library/Developer/Xcode/iOS DeviceSupport
5. Review and selectively remove old Archives In Xcode, open Window → Organizer → Archives. Right-click any archive you no longer need and choose Show in Finder, then delete it there. Or navigate directly to: ~/Library/Developer/Xcode/Archives
6. Clear the Xcode application cache Less impactful but still worth doing: rm -rf ~/Library/Caches/com.apple.dt.Xcode

Automate This with TrimyMac's Xcode Artifacts Category

Doing this manually every few months works, but it requires you to remember to do it and to navigate through multiple directories. TrimyMac's Xcode Artifacts category handles all of this automatically, with an important distinction: it knows which files are safe to delete and which to leave alone.

When you run a scan in TrimyMac, the Xcode Artifacts category:

• ✓ Scans all DerivedData subdirectories and identifies how much space each project is consuming, so you can clean selectively or all at once
• ✓ Detects orphaned DerivedData entries for projects that no longer exist at their original path on disk
• ✓ Lists unused Simulator devices and runtimes grouped by iOS version, so you can remove entire runtime families with a single click
• ✓ Flags old iOS and watchOS DeviceSupport folders for versions more than two major releases behind the current SDK
• ⚠ Always marks Archives as review before delete — TrimyMac will never automatically remove distribution Archives without explicit confirmation

The result is that a full Xcode cleanup that would take 10–15 minutes of manual Terminal work takes about 30 seconds in TrimyMac: run scan, review the Xcode Artifacts breakdown, confirm, done.