Xcode taking up space? Delete DerivedData, DeviceSupport and old simulators
Updated 13 October 2026
Xcode DerivedData lives in ~/Library/Developer/Xcode/DerivedData and is safe to delete: it only holds build products, indexes and logs that Xcode rebuilds on the next build. Quit Xcode, delete the folder, and the next build and indexing pass will simply take longer. iOS DeviceSupport and simulator caches are also safe; Archives are the folder to keep.
WTMemory, a free macOS menu-bar app, can show these folders and their sizes before you decide. Details near the end; everything here also works with Terminal and Finder alone.
Where is Xcode using space on my Mac?
Almost everything lives under ~/Library/Developer. Measure it before you delete anything:
du -sh ~/Library/Developer/Xcode/* ~/Library/Developer/CoreSimulator/* 2>/dev/null | sort -hSimulator runtimes installed by recent Xcode versions are managed by the system, outside your home folder, so the command above does not count them. Check them with xcrun simctl runtime list.
| Location | What it is | Safe to delete? |
|---|---|---|
Xcode/DerivedData | Build products, index, module cache, logs | Yes. Slower next build and re-index. |
Xcode/iOS DeviceSupport (also watchOS, tvOS, visionOS) | Symbols copied from connected devices, one folder per OS version | Yes. Re-copied when you connect a device on that version. |
CoreSimulator/Caches | Simulator caches | Yes. Recreated when needed. |
CoreSimulator/Devices | Each simulator, its installed apps and data | Use simctl, not rm. You lose app data inside the simulators. |
| Simulator runtimes | iOS, watchOS, tvOS, visionOS simulator OS images | Yes, if you no longer test on that OS. Re-downloadable. |
Xcode/Archives | Builds you archived, with dSYMs | Usually no. Needed to symbolicate crashes. |
~/Library/Caches/com.apple.dt.Xcode | Xcode app cache | Yes, with Xcode quit. |
How do I delete Xcode DerivedData?
Quit Xcode first. Deleting the folder under a running Xcode can leave the indexer and build system in a confused state.
rm -rf ~/Library/Developer/Xcode/DerivedDatarm -rf deletes permanently. If you prefer something you can undo, open the folder in Finder with open ~/Library/Developer/Xcode/DerivedData and drag its contents to the Trash. You can also reach it from Xcode: Settings > Locations shows the DerivedData path with an arrow that opens it.
To clear a single project, delete only its folder. Each one is named after the project plus a hash, for example MyApp-abcdefghij. This is the classic fix for stale indexes, phantom build errors and "No such module" errors that survive a clean build.
What you give up: the next build of each project is a full build, Swift packages resolved into DerivedData are fetched again, and code completion and jump-to-definition are slow until indexing finishes. Nothing in your source tree changes.
Product > Clean Build Folder (Shift-Command-K) is not the same thing. It removes the current project's build products but leaves its index, other projects' folders and the shared module cache in place.
Is iOS DeviceSupport safe to delete?
Yes. When you connect an iPhone or iPad for debugging, Xcode copies that iOS version's symbols to your Mac so it can debug and symbolicate on the device. Every iOS version you have ever debugged gets its own folder, and each can be several gigabytes. List them by size:
du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport/* | sort -hDelete folders for iOS versions your test devices no longer run. If you connect a device on a deleted version again, Xcode copies the symbols again, which takes a few minutes before debugging starts. The same applies to watchOS DeviceSupport, tvOS DeviceSupport and other sibling folders.
How do I delete old simulators?
Shut down running simulators, then remove devices whose runtime is no longer installed:
xcrun simctl shutdown all
xcrun simctl delete unavailabledelete unavailable removes only simulators that the current Xcode SDK cannot run, so it is the safe first step. To see the rest, run xcrun simctl list devices and delete individual ones by UDID with xcrun simctl delete <UDID>. xcrun simctl erase all resets every simulator to factory state without deleting it, which clears installed apps and their data.
Runtimes are usually the largest item. List them:
xcrun simctl runtime listThen delete one by its identifier, or preview what an age-based cleanup would remove:
xcrun simctl runtime delete <identifier>
xcrun simctl runtime delete --notUsedSinceDays 90 --dry-runDrop --dry-run when the list looks right. In Xcode you can do the same from Settings > Components (named Platforms in Xcode 15). SwiftUI previews keep their own simulator set; xcrun simctl --set previews delete all clears it, and Xcode recreates what it needs.
Should I delete Xcode Archives?
Usually not. Each archive in ~/Library/Developer/Xcode/Archives contains the app build and its dSYM files. You need those dSYMs to turn crash reports from that exact build into readable stack traces, and to re-export or re-upload the build. Delete an archive only when that version is no longer installed anywhere you care about, or when you have stored its dSYMs elsewhere, for example in your crash reporting service. Manage them from Window > Organizer > Archives so you can see the version and date of each one first.
What about Swift Package Manager and old Xcode versions?
- SwiftPM caches in
~/Library/Caches/org.swift.swiftpmare re-downloaded when needed. Deleting them costs network time on the next package resolve. - Old copies of Xcode in
/Applications(for exampleXcode-15.4.app) are often the biggest single item. Make sure no CI script orxcode-selectpath points to one before removing it. - Documentation and logs inside
~/Library/Developerare small next to the items above; leave them unless they show up large indu.
Why does Xcode storage show up as System Data?
macOS storage settings group developer caches, simulator runtimes and other library data in broad categories, often under Developer or System Data, so the number rarely matches a single folder. Measuring with du as above tells you exactly where the space is. See the System Data guide for the rest of that category.
Review Xcode caches from the menu bar
WTMemory scans supported locations, including Xcode DerivedData, iOS DeviceSupport and Simulator caches, and shows each with a description and estimated size. You can reveal any item in Finder before deciding. Inspection is free.
With Pro, you select individual items, read the consequences in a confirmation, and WTMemory moves them to the Trash. Nothing is selected automatically and nothing is permanently deleted: you empty the Trash yourself. Archives are excluded from cleanup, so your dSYMs stay put. Quit Xcode and the Simulator first, because running tools can keep cache files open. WTMemory runs on macOS 12 and later, on Apple Silicon and Intel; Pro is $9 USD once for up to three Macs, with a seven-day trial.
FAQ
Is it safe to delete Xcode DerivedData?
Yes. DerivedData only holds build products, indexes, module caches and logs that Xcode regenerates. Quit Xcode first. The cost is a slower first build and a re-index of each project.
Is iOS DeviceSupport safe to delete?
Yes. Each folder holds symbols copied from a device running that iOS version. If you connect a device on that version again, Xcode copies the symbols again, which takes a few minutes.
Should I delete Xcode Archives?
Usually not. Archives contain the dSYM files you need to symbolicate crash reports from builds you shipped. Delete an archive only when that build is no longer in use or its dSYMs are stored elsewhere.
How do I delete old iOS simulators?
Run xcrun simctl delete unavailable to remove simulators whose runtime is no longer installed. Remove whole runtimes with xcrun simctl runtime delete or from the Components pane in Xcode settings.
Does Product > Clean Build Folder free the same space?
No. Clean Build Folder removes build products for the current project only. It leaves that project's index, other projects' folders and the shared module cache in DerivedData.