How to Clean Up Xcode Storage on Mac

If you've ever watched your Mac's free storage shrink for no obvious reason, Xcode is a prime suspect. It's not unusual for developers to find tens of gigabytes tied up in Xcode-related data without a single large project file in sight. This guide walks through where that space actually goes and what you can safely do about each piece of it.

Why Xcode eats so much storage

Xcode itself is a large application — the install, including its bundled simulator runtimes and platform SDKs, typically runs into several gigabytes on its own. But the app's footprint is only the starting point. The real storage cost comes from what Xcode generates every time you build and test: compiled object files, indexes, module caches, simulator "devices" with their own installed apps and data, and archived builds you created for distribution.

None of this is a bug or a sign something's wrong — it's just how the toolchain works. Compilation needs intermediate output, testing needs simulated devices with persistent state, and shipping to the App Store needs an archived copy of what you submitted. The problem is that almost none of it gets cleaned up on its own, so it accumulates quietly for months across every project you've ever opened.

Clear out DerivedData (it's safe)

The single biggest and easiest win is ~/Library/Developer/Xcode/DerivedData/. This folder holds build artifacts and intermediate compilation output — object files, module caches, build logs, and indexing data — organized into a subfolder per project. Every project you've built in Xcode has one of these subfolders, and they keep growing as you rebuild.

DerivedData is, by design, entirely regenerable. Xcode rebuilds whatever it needs the next time you open a project and build it, so deleting the contents of this folder doesn't put any project or source file at risk — the only cost is that your next build after clearing it will take longer than usual, since it has to recompile from scratch instead of reusing cached intermediate output.

You can clear it from inside Xcode itself: open Settings (or Preferences on older versions) and go to the Locations tab, where Xcode shows the DerivedData location and usually provides a button to clear it directly. If you'd rather do it by hand, you can navigate to ~/Library/Developer/Xcode/DerivedData/ in Finder (use Go → Go to Folder to get there quickly) and delete the per-project subfolders inside it. Either way, it's worth doing periodically — this is usually the largest chunk of reclaimable space on a developer's Mac.

Clean up iOS Simulator data

The iOS Simulator keeps its own storage under ~/Library/Developer/CoreSimulator/, separate from DerivedData. Each simulated device — and you likely have several, across different iOS versions and device types — maintains its own installed test builds, app data, and simulated user content, much like a real device would. Multiply that across every simulator you've created while testing different OS versions or screen sizes, and it adds up fast.

A good first step is removing simulator runtimes that are no longer supported by your installed Xcode version — these can linger after Xcode updates even though nothing can actually use them anymore. From Terminal, running:

xcrun simctl delete unavailable

removes exactly those orphaned, unavailable runtimes. It's a safe, well-known command that only touches simulator data that your current Xcode installation can no longer use — it won't affect your projects or your working simulators.

If you'd rather manage things visually, Xcode's Window → Devices and Simulators window lets you see every simulator device you've created and delete the ones you no longer need, one at a time, without touching Terminal at all. It's a reasonable place to start if you've accumulated a long list of simulators for device/OS combinations you no longer actively test against.

Archives: think before you delete

~/Library/Developer/Xcode/Archives/ is a different situation entirely, and it's worth calling out because it's easy to lump in with the rest of this cleanup. This folder holds the actual archived builds you've created for App Store submission or other distribution — organized by date, with each archive representing a specific build you shipped.

Unlike DerivedData or simulator caches, archives are not automatically regenerated. If you need to symbolicate a crash report from a version you shipped months ago, the matching archive (with its debug symbols) is often the only way to turn that crash log back into readable source locations. Deleting an archive you later need means you've lost that ability for good.

That doesn't mean you should let them pile up indefinitely — old archives from abandoned projects or very old versions nobody is still running are reasonable to clear out. It just means archives deserve a quick review before bulk deletion, rather than the "delete without a second thought" treatment that's fine for DerivedData. Keep archives for versions that are still in active use or recent enough that a crash report might still come in, and clear out the rest.

Old Xcode versions and unused runtimes

If you support multiple iOS SDK versions, or you've just never gotten around to removing old copies, you may have more than one full version of Xcode installed — maybe an older one kept around for a project that hasn't been updated to the latest SDK yet, alongside the current version for everything else. Each full Xcode installation can easily run several gigabytes or more once you include its bundled simulator runtimes and platform SDKs, so a couple of old versions sitting in Applications can represent a meaningful amount of reclaimable space on their own.

It's worth periodically checking which older Xcode versions you actually still need for active projects versus which ones are just taking up space out of habit. The same goes for individual simulator runtimes you can install or remove independently of a full Xcode version — if you're no longer testing against a particular older iOS version, there's little reason to keep its runtime installed.

Where a general Mac cleaner fits in

DerivedData and simulator caches are exactly the kind of storage that a general-purpose Mac cleaner is built for: large, safe to clear, and automatically regenerated by the system that created them. CleanMyApple's junk cleaner scans your Mac for cache and temporary files like these and shows you what it found — including large caches sitting under ~/Library/Developer/ — before anything is removed, so you can review and confirm rather than guessing.

It's worth being clear about what that does and doesn't mean. CleanMyApple doesn't have Xcode-specific logic — it won't label a folder "DerivedData" and offer a dedicated one-click button for it, and it has no special awareness of simulator runtimes or any way to help you decide which Archives are safe to remove. What it will do is surface large, stale cache and junk files generally, which happens to catch a good share of what Xcode leaves behind, the same way it would for any other app's bloated cache folder. For the Xcode-specific steps above — DerivedData, simulators, archives — the commands and Xcode settings covered in this guide are still the right tool.

If you want a broader look at what else might be using space on your Mac beyond developer tools, our guide on how to free up space on Mac covers the general cleanup steps worth doing alongside this one.

Between DerivedData, simulator data, and old Xcode versions, it's common to free up tens of gigabytes without touching a single archive or source file. Make a habit of clearing DerivedData periodically, running xcrun simctl delete unavailable after Xcode updates, and reviewing old Xcode installs every so often — it's a small amount of maintenance for a meaningful amount of reclaimed disk space.