How to Clean Up Xcode Cache on Mac and Reclaim Storage

You open About This Mac, click Storage, and there it is: a huge slab of System Data or Developer files with no obvious way to click into it. If you build iOS or Mac apps, Xcode is almost always the reason. The app download is about 15 GB on its own, but the real weight comes from everything Xcode generates while you work and then never cleans up.

On an active machine that adds up fast. Build caches for every project you have opened, debug symbols for every iPhone iOS version you have ever plugged in, a stack of simulator runtimes at several gigabytes each, and archived builds going back years. It is common to find 30, 50, or even 100 GB tied up in files you will never look at again.

The good news is that almost all of it is safe to remove, because Xcode either rebuilds or re-downloads it on demand. This guide walks through each storage area in plain terms, tells you which parts are safe and which deserve a second look, and gives you the commands to reclaim the space without breaking your setup.

Why Xcode Eats So Much Disk Space

Xcode does not have one big cache. It has a dozen small ones that grow independently, and macOS hides most of them inside your user Library where you never browse. Four patterns are doing most of the damage:

• It caches per project, forever. Every project you build gets its own DerivedData folder full of compiled output and index data. Delete a project from disk and its cache often stays behind.
• It keeps symbols for every device version. The first time you debug on a physical iPhone running a given iOS version, Xcode copies several gigabytes of debug symbols and holds onto them.
• Simulators are full operating systems. Each simulator runtime is effectively a copy of iOS, watchOS, or tvOS, weighing 5 to 7 GB. Stack up a few versions and the folder balloons.
• Nothing expires on its own. There is no built-in rule that clears an old runtime or a stale archive. Everything sits there until you remove it by hand.

None of this is a bug. Xcode holds these files so that rebuilds are faster and debugging works offline. The problem is only that it never decides you are done with them. That decision is yours to make.

Measure First: Find Where the Space Went

Before deleting anything, look at what is actually big. Guessing wastes time, and the biggest folder on your Mac is not always the one the internet tells you to clear. Quit Xcode and the Simulator first, then run this in Terminal:

du -sh ~/Library/Developer/Xcode/* 2>/dev/null | sort -hr
du -sh ~/Library/Developer/CoreSimulator/* 2>/dev/null | sort -hr

The -sh flags give you a human-readable total per folder, and sort -hr puts the largest on top. A typical result looks something like this, with the fat targets obvious at a glance:

 42G  ~/Library/Developer/Xcode/iOS DeviceSupport
 28G  ~/Library/Developer/CoreSimulator/Devices
 19G  ~/Library/Developer/Xcode/DerivedData
  6G  ~/Library/Developer/Xcode/Archives

Now you know where to spend your effort. If DeviceSupport and simulators are your giants, clearing DerivedData alone barely moves the needle. Measure, then aim.

The Xcode Storage Map

Here is every major location Xcode uses, what it holds, whether it is safe to clear, and what happens after you do. Keep this table handy as you work through the rest of the guide.

Clear DerivedData (The Fast, Safe Win)

DerivedData is where Xcode stores compiled output, the module cache, and the search index for every project you build. For a project you have compiled hundreds of times across a few Xcode versions, this alone can reach 10 to 20 GB. It is completely safe to delete. Xcode rebuilds it the next time you hit build.

There are two ways to clear it.

From Xcode

Go to Xcode → Settings → Locations. Click the small arrow next to the DerivedData path to open the folder in Finder, then delete everything inside it. This is the safest route because you can see exactly what you are removing.

From Terminal

Faster if you are comfortable with the command line:

rm -rf ~/Library/Developer/Xcode/DerivedData

Xcode recreates the folder automatically. Your first build after this will be slower than usual because everything compiles from scratch, but that is the only cost.

Trim Old iOS DeviceSupport

This one is often the single biggest folder on a developer Mac, and almost nobody knows it exists. Every time you connect a physical iPhone or iPad running an iOS version Xcode has not seen before, it copies that version's debug symbols into iOS DeviceSupport. Each folder runs 2 to 5 GB, and they pile up as iOS releases march on.

Look at what you have:

du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport/* | sort -hr

You will usually see a folder for nearly every point release you have ever debugged against: 16.4, 17.1, 17.5, 18.0, and so on. You only need the versions you actively test on. Keep the current one or two and delete the rest. To remove everything from iOS 16, for example:

rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/16.*

There is no permanent loss. The next time you plug in a device running a version you deleted, Xcode simply re-copies the symbols. The same folders exist for watchOS and tvOS under watchOS DeviceSupport and tvOS DeviceSupport if you build for those platforms.

Delete Unused Simulators and Runtimes

Simulators are two separate storage costs, which is why people clean one and wonder why the space did not come back. There is the runtime, which is the actual iOS or watchOS system image, and there is the device data, which is everything installed inside each simulated phone.

Clear out broken and unavailable simulators

When you update Xcode, old simulators that point at runtimes you no longer have become unavailable but keep taking up space. One command removes them all:

xcrun simctl delete unavailable

This is safe. It only removes simulators macOS can no longer run. If you want to wipe the installed apps and data out of your working simulators without deleting the devices themselves, use xcrun simctl erase all instead.

Remove simulator runtimes you do not use

Runtimes are the heavyweight. A single iOS runtime is 5 to 7 GB, and if you are holding iOS 16, 17, and 18 plus a couple of watchOS versions, that is easily 30 GB. List what is installed:

xcrun simctl runtime list

Then delete a specific runtime by its identifier:

xcrun simctl runtime delete <identifier>

If you prefer a visual interface, open Xcode → Settings → Components, where recent Xcode versions list every downloaded simulator runtime with its size and a delete control. You can also manage the devices themselves under Xcode → Window → Devices and Simulators. Whatever you remove is re-downloadable the moment you need it again.

Review Archives (Delete With Care)

Archives are the one Xcode folder where you should slow down. Every time you archive a build to distribute to TestFlight or the App Store, Xcode saves that build along with its dSYM symbol files under ~/Library/Developer/Xcode/Archives. These are useful for two real reasons: re-submitting or re-exporting an older build, and symbolicating crash reports that come back from users on that version.

Open Xcode → Window → Organizer and select the Archives tab. You will see every archive grouped by app and date. Old betas, abandoned experiments, and builds several versions behind your current release are usually safe to remove. Keep the archives for versions still live in the App Store so you can symbolicate their crash logs.

The Smaller Caches Worth Clearing

After the big four, a handful of smaller caches are worth a look. Individually they are modest, but together they can add up to a few gigabytes.

• Swift Package Manager cache. Downloaded package sources and clones live in ~/Library/Caches/org.swift.swiftpm and ~/Library/org.swift.swiftpm. Both are safe to delete. Xcode re-fetches packages the next time it resolves your dependencies.
• Old Xcode versions. If you keep a beta alongside the release, or an old Xcode.app you stopped using, each one is 15 GB or more in /Applications. Deleting the app you no longer open is one of the largest single wins available.
• Documentation cache. Downloaded developer documentation sits under the Xcode caches. It is small compared to simulators but re-downloadable if you clear it.
• Device backups. Not strictly Xcode, but iPhone backups made through Finder pile up in ~/Library/Application Support/MobileSync/Backup and are frequently many gigabytes. Manage them from Finder rather than deleting the folders blindly.

The 5-Minute Safe Cleanup

If you just want the space back and do not want to think about each folder, here is a conservative sequence that reclaims most of the storage while leaving anything risky alone. Quit Xcode and the Simulator first.

rm -rf ~/Library/Developer/Xcode/DerivedData

xcrun simctl delete unavailable

du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport/* | sort -hr

Four steps, no risk to your code, and on a typical developer Mac you will get back somewhere between 20 and 60 GB. Leave Archives for a separate, more careful pass.

What Not to Delete

Cleanups go wrong when people delete the wrong thing to save a little space. A few folders should stay put:

• Xcode/UserData. This holds your code snippets, key bindings, themes, and behaviors. Deleting it resets Xcode to defaults and loses your personal setup.
• Provisioning profiles you still use. They live under Library and are small. Clearing them blindly can break code signing until Xcode regenerates them.
• Archives for shipped versions. As covered above, keep the ones you may still need to symbolicate or re-submit.
• Your actual project folders. This should be obvious, but do not go hunting for space inside your repositories. The caches are all in Library, never in your source.

Keeping It From Filling Back Up

Xcode will start rebuilding these caches the moment you get back to work, so cleanup is not a one-time event. A few habits keep it manageable without turning storage into a chore:

• Run the quick cleanup every couple of months. DerivedData, unavailable simulators, and old DeviceSupport are the recurring offenders. A short pass on a schedule beats a panic when the disk fills.
• Delete runtimes when you drop support. The day you stop testing on an old iOS version, remove its runtime and DeviceSupport. That is the moment they turn into pure dead weight.
• Clean up after shipping. Once a version is safely live and you have its dSYMs backed up, prune the older archives so the Organizer does not become its own graveyard.
• Watch your whole disk, not just Xcode. Developer machines also collect node_modules folders, Docker images, and other caches. Xcode is often the biggest single culprit, but rarely the only one.

That last point is where a lot of developers lose the thread. You clear Xcode, reclaim 40 GB, feel good, and two weeks later the disk is full again from a completely different pile of build artifacts scattered across your projects folder.

When a cleanup tool earns its place

If you would rather see every developer cache on your Mac in one view instead of running commands folder by folder, that is where a tool helps. Files Magic AI includes a System Cleaner with a dedicated Developer Caches view that finds node_modules folders, Xcode DerivedData, and other build caches across your whole Mac, shows their sizes, and lets you clear them with a review step so nothing goes without your say-so. It sits alongside the on-device file organizing and offline Magic Rename that the app is built around, so cleanup is one part of keeping the machine tidy rather than a separate errand.

None of that replaces the Terminal commands above. If you like living in the command line, keep doing exactly that. The tool is for the developers who would rather glance at a list and click, and who want the same pass to catch the non-Xcode caches too.

Frequently Asked Questions

Want the bigger picture on Mac storage beyond Xcode? Our guide on how to free up disk space on Mac covers duplicates, DMG installers, and other developer caches, and the best Mac disk cleaner apps roundup ranks the tools that automate it.

Published July 8, 2026 · More guides · Files Magic AI