Field guide
Xcode Disk Space: What You Can Delete and What You Can't
Xcode is one of the largest single consumers of disk space on a Mac, and almost none of it is your code. This is a directory-by-directory map of everything Xcode writes under ~/Library/Developer and ~/Library/Caches, what each one actually contains, whether deleting it is safe, and what it costs you. Written for people who have run out of space and want to make an informed decision rather than guess.
By Naman Namdev
Clepsydra Technologies
Updated
Version 1.0.4
Start by measuring rather than guessing. This finds the ten largest directories Xcode has created, which is a more useful first move than any cleanup tool:
du -sh ~/Library/Developer/* ~/Library/Caches/com.apple.dt.Xcode 2>/dev/null | sort -h | tail -10
On a machine that has been developing iOS for a couple of years, expect the answer to be dominated by four directories, and to be measured in tens of gigabytes rather than hundreds of megabytes.
The safe to delete group
~/Library/Developer/Xcode/DerivedData
What it is: per-project compiled intermediates — object files, module caches, generated headers, Swift module data and the incremental build index. Xcode creates one subdirectory per project, identified by a hash of the project path, and never evicts them.
Size: commonly 2–10 GB for a single active project, and easily 40–60 GB once several finished projects, branches and dependency changes have accumulated. This is the directory that catches people out, because it grows silently and is never mentioned.
Safe? Yes. Entirely rebuilt from source on the next build. The cost is a cold rebuild — minutes rather than seconds on a large project. Close Xcode first, because a running instance writing into a directory that is being deleted produces confusing errors.
~/Library/Developer/Xcode/Products
What it is: build products from the current workspace, a legacy location that predates DerivedData. Size: usually small on modern setups, occasionally enormous on older ones. Safe? Yes — regenerated on the next build.
~/Library/Caches/com.apple.dt.Xcode
What it is: Xcode's own cache: module validation data, Swift compilation caching, and assorted transient state. Size: 1–5 GB. Safe? Yes. Xcode rebuilds it, at the cost of a slower first build after clearing.
~/Library/Developer/CoreSimulator/Caches
What it is: caches belonging to the simulator subsystem, not the runtimes themselves. Size: 1–10 GB depending on how much simulator testing you do. Safe? Yes. Note carefully that this is Caches, not Profiles/Runtimes, which is on the protected list below.
~/Library/Developer/XCTestDevices
What it is: temporary device data created for UI and unit testing. Size: variable, occasionally large after a test run that generated many screenshots. Safe? Yes.
~/Library/Caches/org.swift.swiftpm
What it is: the SwiftPM package cache — checked-out and downloaded dependency repositories. Size: 0.5–5 GB. Safe? Yes, but it is re-download rather than regenerate: expect every dependency to be fetched again on the next resolve.
The group you must not delete
This is where most third-party “Xcode cleaners” do damage. These three are not caches in any recoverable sense, and several popular tools will happily remove them:
Xcode paths that are protected, and why| Path | What it holds | What you lose |
|---|
~/Library/Developer/Xcode/Archives | Distribution binaries for apps you shipped or are about to ship | The archive. Re-shippable only by re-archiving and re-signing from source. |
|---|
~/Library/Developer/Xcode/iOS DeviceSupport | Symbol bundles for physical devices | Symbols for that device version. Re-obtained only by re-attaching the device and rebuilding. |
|---|
~/Library/Developer/CoreSimulator/Profiles/Runtimes | Installed iOS simulator runtimes | A multi-gigabyte download, and a working simulator. |
|---|
Device support in particular. It is easy to assume it is regenerable because Xcode appears to manage it. It is not — the symbols are generated by your compiler for a specific device and OS build, and cannot be reproduced without that exact toolchain and device. If you have a device you can no longer attach, deleting its symbols can cost you a debugging session you cannot repeat.
The group that is not Xcode's fault
A common misdiagnosis. If the space is not under ~/Library/Developer, Xcode is not the cause, even though you were last building an iOS app when the disk filled. Three frequent culprits:
- CocoaPods and Carthage —
~/Library/Caches/CocoaPods and ~/Library/Caches/org.carthage.CarthageKit hold downloaded pod sources. Large, and re-downloadable. (Note: Worm Cleaner does not currently have a CocoaPods rule, so manage these yourself with pod cache clean --all.) - Node and package managers —
node_modules inside projects, plus ~/.npm/_cacache, ~/.yarn and ~/.gradle. Frequently larger than all of Xcode combined. - Device backups and simulators on the Mac itself —
~/Library/Developer/Xcode/Archives is the archive store, but iPhone backups live under ~/Library/Application Support/MobileSync/Backup and belong to the backup system, not Xcode.
A reasonable clearing order
- Close Xcode entirely. Check no
Xcode, CoreSimulator or XCTRunner process is running.
- Measure first with the
du command above, so you know what you are dealing with.
- Clear
DerivedData for projects you are finished with first — they are usually the largest and cost you nothing you still need.
- Clear
com.apple.dt.Xcode and the simulator Caches directory.
- Decide separately on SwiftPM: clearing it is safe but means re-downloading every dependency.
- Leave Archives, DeviceSupport and simulator Runtimes alone.
- Rebuild once and note how long it takes. That is the real cost, and now you know it.
Making it stop coming back
DerivedData accumulates because Xcode has no eviction policy: it keeps one directory per project path, forever. Three habits genuinely reduce it:
- Delete on project completion. When a client project ends, remove its DerivedData subdirectory then, not eighteen months later.
- Prune unused runtimes and devices. Xcode → Settings → Platforms. Each runtime is several GB.
- Keep your volume 15–20% free. A nearly-full SSD makes builds fail and slows the whole system, well before macOS reports the disk as full.
About the word “optimizer”. People search for it, so Worm uses it — but be clear about what it means. A storage cleaner frees disk space and reduces clutter. It does not make your Mac faster, and no cleaner honestly can promise that. What a nearly-full drive does is cause real problems: Xcode builds fail, macOS swaps heavily, updates stall, and caches stop being written. Freeing space fixes those. It is not a speed hack.
Every target carries one of four risk tiers, and the tier decides what is ticked by default:
- Safe — rebuilt automatically by the app. Deleting costs only time.
- Re-download — fetched again from the network. Anything expired in there is gone for good.
- Keep — your content, not a cache. Off by default, and needs an explicit per-item opt-in.
- Blocked — system-owned or not rebuildable. Never offered as a target at all.
Frequently asked questions
Is it safe to delete Xcode DerivedData?
Yes. It contains only compiled intermediate files that Xcode regenerates from source on the next build, so the cost is a slower cold rebuild and nothing else. Your repositories, project files and signing material are all stored elsewhere. Close Xcode before deleting so a running instance is not writing into a directory that is disappearing underneath it.
Why is my Xcode folder so large?
Almost always DerivedData accumulating across projects. Xcode creates one subdirectory per project path and never evicts them, so a machine that has worked on a dozen projects over two years accumulates the sum of all of them. Add the Xcode cache, the simulator caches, SwiftPM, and any CocoaPods or node_modules directories in the same projects, and tens of gigabytes is normal.
What is the difference between DerivedData and the Xcode cache?
DerivedData is per-project compiled output: object files, module data and the incremental build index, in a subdirectory named after a hash of the project path. The Xcode cache in ~/Library/Caches/com.apple.dt.Xcode is application-level state that is shared across all your projects — module validation data and Swift compilation caching. Both are safe to delete; DerivedData is usually much larger.
Can I delete iOS DeviceSupport?
Technically you can, but it is a bad idea, and Worm Cleaner refuses to do it. Device support holds symbol bundles generated by your compiler for a specific device and OS build. They cannot be reproduced without that exact toolchain and that device attached. If you still have the device, re-attaching it once regenerates them — and if you no longer do, you have lost the ability to symbolicate crashes from that device.
How do I find out which Xcode directories are taking up space?
Run: du -sh ~/Library/Developer/* ~/Library/Caches/com.apple.dt.Xcode 2>/dev/null | sort -h | tail -10 — that lists the ten largest, sorted. Alternatively a scan in Worm Cleaner reports the measured size of each Xcode target individually, including DerivedData, build products, the Xcode cache, simulator cache and XCTest device data as separate entries.
Download Worm Cleaner
Worm Cleaner is free, MIT licensed and runs on macOS 14+ and Windows 10/11. No account, no subscription, no telemetry in the app.
