How to Reclaim Disk Space After an Xcode Build

You finish a long iOS build, archive a release for App Store Connect, and notice your SSD now shows 80 GB less free than it did this morning. Xcode is one of the most aggressive disk consumers on any Mac, and almost none of it cleans up automatically. After a year of working on iOS apps, you can easily have 100 GB of build artifacts, archives, and device support files that contribute nothing to current builds.

Here’s exactly where Xcode hides its data and how to clean it safely.

DerivedData: the big one

Xcode’s DerivedData folder caches build outputs, intermediate object files, and indexes for every project you’ve ever opened. It lives at:

• ~/Library/Developer/Xcode/DerivedData/

For a working iOS developer, this folder routinely hits 30-80 GB. It’s safe to delete entirely — Xcode rebuilds what it needs on next build.

To clean from inside Xcode:

1. Xcode menu > Settings > Locations
2. Click the small arrow next to Derived Data to open the folder in Finder
3. Move the contents (or the whole folder) to Trash

To clean from Terminal:

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

After deleting, your next build will be a full rebuild — slower than usual. Subsequent builds are normal speed.

Skip the manual huntSweep finds the cache and cruft slowing down your workflow. Try Sweep free →

Archives: keep recent, delete old

Every time you Archive a build for distribution, Xcode saves the bundle plus debug symbols (dSYMs) in:

• ~/Library/Developer/Xcode/Archives/

These can each be 200 MB to 2 GB depending on app size. After dozens of TestFlight builds and App Store submissions, the folder can balloon to 30+ GB.

Why you might want to keep some: dSYMs are needed to symbolicate crash reports for that specific build. If users on an older app version are reporting crashes, you need the matching archive to symbolicate them.

Reasonable retention policy:

• Keep the last 3 production releases
• Keep recent TestFlight builds for the last month
• Delete everything older

In Xcode > Window > Organizer > Archives, you can review and delete old archives directly.

iOS DeviceSupport and watchOS DeviceSupport

When you connect an iPhone or iPad for the first time, Xcode downloads and stores symbol files for that exact iOS version. These live in:

• ~/Library/Developer/Xcode/iOS DeviceSupport/
• ~/Library/Developer/Xcode/watchOS DeviceSupport/
• ~/Library/Developer/Xcode/tvOS DeviceSupport/

Each iOS version per device family is typically 500 MB to 2 GB. Over years, this adds up to dozens of GB. You only need DeviceSupport for iOS versions you actively support — old iOS 12 entries can go.

Open the folder in Finder, sort by date or size, and delete versions you don’t support anymore. Xcode redownloads them automatically if you connect a device with that iOS version later.

Simulators: clean unavailable ones

Xcode keeps simulator runtimes for every iOS version you’ve installed. Old simulators for iOS versions you no longer test against are pure waste.

The clean way:

xcrun simctl delete unavailable

This removes simulators marked as unavailable (usually because their iOS version was uninstalled).

To check what’s installed:

• Xcode > Settings > Platforms

You can uninstall iOS simulator runtimes you don’t need from there. Each iOS version simulator runtime is about 6-10 GB.

Module cache and CoreSimulator caches

Xcode uses a module cache for Swift compilation:

• ~/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/

This is part of DerivedData and goes when you clean DerivedData. If you’ve seen weird Swift compilation errors after upgrading Xcode versions, deleting this often fixes them.

CoreSimulator has its own cache:

• ~/Library/Developer/CoreSimulator/Caches/

Safe to delete; regenerated as needed.

Free RAM after a long build

Xcode is RAM-hungry, especially during Swift compilation of large projects. After a build, macOS holds the memory as “Inactive”. If you’re going to keep working in Xcode, that’s fine — but if you’re switching to Final Cut or another heavy app, free it first.

Sweep’s speed boost frees inactive memory in one click. Or quit Xcode entirely between major tasks if you don’t need it open.

Archive-related: the .xcodeproj/.xcworkspace user files

Each developer’s project file accumulates user-specific data in xcuserdata/ folders that aren’t in version control. These are usually small, but if your project has many schemes and breakpoints, they grow.

These are safe to delete with the project closed:

• Inside YourProject.xcodeproj/xcuserdata/
• Inside YourProject.xcworkspace/xcuserdata/

Xcode regenerates them on open. You’ll lose breakpoints and IDE state, but the project itself is untouched.

Free up RAM in one clickSweep frees inactive memory and pauses runaway processes. Get Sweep free →

Update Xcode (after the cleanup)

Xcode itself is enormous (15+ GB just for the app). If you have multiple versions installed (Xcode_15.4.app and Xcode_16.app), you may be paying double.

After major Xcode updates, the older version is rarely needed unless you’re maintaining apps for an old SDK. Delete the old Xcode bundle to recover 10-15 GB.

For developers who download Xcode betas regularly, keeping only the current beta plus current stable is plenty.

Empty Trash to actually free the space

After moving DerivedData, Archives, and old Xcode versions to Trash, the space isn’t actually freed until you Empty Trash. Right-click the Trash, Empty Trash, and confirm.

Some folders contain hundreds of thousands of small files (especially DerivedData), which makes emptying the Trash take a few minutes. That’s normal.

A monthly Xcode maintenance pass

For active iOS developers, run this monthly:

1. Clear all DerivedData
2. Review Archives in Window > Organizer, delete anything older than your support window
3. Trim iOS DeviceSupport to only versions you actively support
4. xcrun simctl delete unavailable for old simulators
5. Empty Trash
6. Reboot if Xcode has been running for a long time

Most iOS developers reclaim 30-60 GB doing this. Builds that started feeling slow run faster. Cmd+R no longer takes a minute to spin up. The Mac feels new again.

When DerivedData isn’t enough

If your builds are slow even with fresh DerivedData, the issue is elsewhere:

• CocoaPods/Swift Package Manager caches — try pod cache clean --all or delete ~/Library/Caches/org.swift.swiftpm/
• CarThage builds — Carthage/ folder per project can be huge
• Generated documentation — DocC archives in DerivedData and elsewhere

For really persistent build issues, a clean install of Xcode plus a fresh DerivedData is the gold standard. Time-consuming but reliable.

The Xcode storage problem is universal and predictable. Stay on top of it monthly and your Mac keeps the disk space and build speed it had on day one.