Guide
How to delete Xcode DerivedData, and what else Xcode leaves behind
By Maulik Dave · Updated
Xcode is often the biggest user of disk space on a developer’s Mac. Most of it can be regenerated. One part can’t. Here is what each folder is, what deleting it costs, and how to do it.
At a glance
| What | Safe to delete? | What it costs |
|---|---|---|
| DerivedData | Yes | The next build and indexing of each project take longer. |
| iOS DeviceSupport | Yes, for versions you no longer use | Rebuilt the next time you connect a device on that version. |
| Unavailable simulators | Yes | Data inside those simulators (test app data) is lost. |
| Simulator runtimes | Yes, ones you don’t test on | Downloading again takes time and several gigabytes. |
| Archives | Only for builds nobody uses | You can no longer symbolicate crash reports from those builds. Can’t be regenerated. |
Quit Xcode and the Simulator app before you start.
DerivedData
Where: ~/Library/Developer/Xcode/DerivedData. You can confirm the location in Xcode › Settings › Locations; the small arrow next to the path opens it in Finder.
What it is: build products, intermediate files, the source index and logs for every project you’ve opened, one folder per project (named like MyApp-abcdefghij). Folders for projects you deleted or haven’t opened in months stay until you remove them. A few gigabytes per project is common, and the whole folder can reach tens of gigabytes.
Cost of deleting: nothing is lost. The next build of each project is a full build, and Xcode re-indexes the source, so code completion and search are slow for a few minutes. On a big project with many packages that can mean a long first build.
How: open the folder in Finder, select the project folders you don’t need (or all of them) and move them to the Trash. On macOS 15 or later you can use the built-in trash command instead of rm, so items stay recoverable until you empty the Trash:
trash ~/Library/Developer/Xcode/DerivedData/*Remember to empty the Trash afterwards; space is only freed then. For a single project, Product › Clean Build Folder (⇧⌘K) clears its build products without touching others.
Archives
Where: ~/Library/Developer/Xcode/Archives, in folders by date.
What it is: each .xcarchive is a build you made with Product › Archive, including its debug symbols (dSYM files). Those symbols turn crash reports from that exact build into readable stack traces.
Data loss warning: dSYMs can’t be regenerated, even from the same source code. Apple’s documentation says you must retain the Xcode archive for each build you distribute. Keep the archive of every version that users still run, unless the symbols are stored elsewhere, for example uploaded to your crash reporting service or App Store Connect.
How: open Window › Organizer, choose Archives, select old ones (for example internal test builds) and delete them there.
iOS DeviceSupport
Where: ~/Library/Developer/Xcode/iOS DeviceSupport (and watchOS DeviceSupport, tvOS DeviceSupport if you develop for those).
What it is: system symbols Xcode copies from a device the first time you connect it for debugging, one folder per OS version and build. Each is often a few gigabytes, and folders for versions your devices left long ago pile up.
Cost of deleting: if you connect a device on that version again, Xcode copies the symbols again, which takes a few minutes. Delete folders for versions none of your devices run; keep the current ones.
Simulators
Simulator devices live in ~/Library/Developer/CoreSimulator/Devices. Each holds the apps and data you installed in it. After Xcode updates, devices for runtimes that are no longer installed become “unavailable” but keep their data. To remove only those:
xcrun simctl delete unavailableThis deletes devices that the current Xcode doesn’t support. It doesn’t touch the ones you can still run. Any test data inside the deleted devices is gone; that is rarely a problem.
To see every device and its state first:
xcrun simctl list devicesSimulator runtimes (the iOS, watchOS, tvOS and visionOS system images) take several gigabytes each and are stored separately. Manage them in Xcode › Settings › Components (called Platforms in Xcode 15), which shows each installed component and the space you get back by removing it (Apple’s guide to Xcode components). Or list and remove them in Terminal:
xcrun simctl runtime list
xcrun simctl runtime delete <identifier>Use the identifier from the list. You can download a runtime again from the same settings pane.
Other Xcode-related space
- Old Xcode versions. A second copy, such as an Xcode beta, can take tens of gigabytes. Delete it from Applications if you no longer need it.
- Caches.
~/Library/Caches/com.apple.dt.Xcodeand Swift Package Manager’s~/Library/Caches/org.swift.swiftpmare regenerated; deleting them means packages are downloaded and resolved again. - Device logs.
~/Library/Developer/Xcode/iOS Device Logsholds old device logs you probably don’t need.
Freeing space for more than just Xcode? See how to free up disk space on a Mac. Running local AI models too? See how to remove Ollama, LM Studio and Hugging Face models.
Where Tidlark helps
Tidlark’s developer files section lists Xcode DerivedData, simulator caches and logs, device support files, compiler module caches and package caches (SwiftPM, CocoaPods, Gradle, npm and others), each with its size and what removing it costs. Regenerable items like DerivedData can be selected for you; Archives are never pre-selected, and Tidlark warns that their debug symbols can’t be regenerated. It skips Xcode’s caches while Xcode is running, and removed items go to the Trash.
See pricing or download Tidlark. Related: uninstall apps completely.