How to clear Xcode DerivedData, archives and simulators

Photo: luis gomes on Pexels

Xcode is often the largest single reason a developer's Mac runs out of space. Most of it is build output and downloaded support files that come back on their own. Here is what each folder holds and how to clear it.

Updated October 2026 6 min readmacOS 15 to 27

Where Xcode keeps its data

Xcode itself lives in Applications, but the space it uses grows somewhere else: in the Developer folder inside your Library. A quick look in Terminal shows how it splits up:

~ % du -sh ~/Library/Developer/Xcode/* ~/Library/Developer/CoreSimulator/* 2>/dev/null | sort -h
1.2G	/Users/you/Library/Developer/Xcode/UserData
4.8G	/Users/you/Library/Developer/CoreSimulator/Caches
9.6G	/Users/you/Library/Developer/Xcode/iOS DeviceSupport
 14G	/Users/you/Library/Developer/CoreSimulator/Devices
 22G	/Users/you/Library/Developer/Xcode/Archives
 31G	/Users/you/Library/Developer/Xcode/DerivedData

Your numbers will differ, but the order is typical. In Storage settings, all of this counts toward Developer or System Data, which is why those bars can grow so quickly on a Mac used for app development.

Each folder has a different job, so each one deserves a different decision.

DerivedData: safe to clear

~/Library/Developer/Xcode/DerivedData holds build products, intermediate files, the source index and logs, one folder per project. Xcode creates it on every build and never removes old projects on its own. A project you opened once two years ago still has its folder here.

Everything in DerivedData rebuilds. The only cost of clearing it is a slower first build and a few minutes of indexing the next time you open a project.

  1. Quit Xcode. Deleting DerivedData while Xcode builds or indexes can leave it confused until the next restart.
  2. Delete the contents. Either drag the folders inside DerivedData to the Trash in Finder, or run:
~ % rm -rf ~/Library/Developer/Xcode/DerivedData/*

To clear only one project, use Product > Clean Build Folder (Shift-Command-K) in Xcode. It removes that project’s build products but keeps the folder and its index.

If you moved DerivedData to a custom location, Xcode shows the path in Xcode > Settings > Locations, with an arrow that opens it in Finder.

Archives: review before you delete

~/Library/Developer/Xcode/Archives holds every build you made with Product > Archive, grouped by date. An archive contains the built app and its debug symbols (dSYM files).

Those symbols matter. Crash reports from TestFlight and the App Store are symbolicated with them, so an archive for a version people still use is worth keeping. Archives for test builds, internal betas or versions nobody runs anymore can go.

The safest way to delete them is in Xcode:

  1. Choose Window > Organizer and select Archives.
  2. Select an app on the left, then the archives you no longer need.
  3. Press Delete, or Control-click and choose Delete.

If your symbols are uploaded to a crash reporting service, or you keep dSYM files elsewhere, you can be more generous. Otherwise, keep at least the archive for every release that is still in use.

iOS DeviceSupport: safe, comes back when needed

When you connect an iPhone, iPad, Apple Watch or Vision Pro to Xcode, it copies that device’s system symbols to your Mac, one set per OS version. They live in folders such as:

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

Each set is several gigabytes, and a new one arrives with every OS update on every device you debug on. Old versions are rarely needed. Delete the folders for versions you no longer run; Xcode copies them again the next time you connect a device with that version, which takes a few minutes.

Simulators and simulator runtimes

Simulators take space in two places, and they are cleared in different ways.

Simulator devices

Each simulator device you create (an iPhone 17 on iOS 26, for example) has its own data folder in ~/Library/Developer/CoreSimulator/Devices, with installed apps, caches and media. When you update Xcode, devices for runtimes you no longer have stay behind as unavailable. Remove them with:

~ % xcrun simctl delete unavailable

This only removes devices that Xcode can no longer start. Your working simulators stay. To see what you have first, run xcrun simctl list devices.

If a working simulator has grown large, reset it in Simulator with Device > Erase All Content and Settings, or remove it in Xcode under Window > Devices and Simulators.

Simulator runtimes

The runtimes themselves (a whole copy of iOS, watchOS, tvOS or visionOS for the simulator) are much larger, often 7 to 10 GB each. They are stored as disk images that macOS manages, outside your home folder. Do not delete them in Finder.

Remove them in Xcode > Settings > Components (called Platforms in Xcode 15), where each runtime has a delete option. Or use the command line:

~ % xcrun simctl runtime list
# preview what would go, then run it without --dry-run
~ % xcrun simctl runtime delete --notUsedSinceDays 90 --dry-run

The --notUsedSinceDays, --unusable and --outdated options are available in recent versions of Xcode. Run xcrun simctl runtime without arguments to see what yours supports. A runtime you delete can be downloaded again from the same settings pane.

Smaller leftovers worth knowing

A few more folders add up on a busy Mac:

  • Simulator caches. ~/Library/Developer/CoreSimulator/Caches holds shared caches the simulator rebuilds. Safe to clear with the simulator closed.
  • SwiftUI previews. Previews run in their own simulator devices. xcrun simctl --set previews delete all removes them; Xcode creates new ones when you open a preview.
  • Swift Package Manager. Downloaded package repositories are cached in ~/Library/Caches/org.swift.swiftpm. Run swift package purge-cache to clear it; packages download again on the next resolve.
  • Old Xcode versions. If you keep several copies of Xcode in Applications for older projects, each one is 10 GB or more. Delete the ones you no longer build with.

How often to do this

There is no need to clear DerivedData every week. It is a working cache, and a warm cache makes builds faster. A good rhythm is:

  • After a major Xcode update, clear DerivedData and run xcrun simctl delete unavailable.
  • A few times a year, review archives and device support folders.
  • Whenever you drop an old OS version, remove its simulator runtime.

The one time to act right away is when your disk is nearly full. Xcode needs free space to build and index, and a full disk can make builds fail with confusing errors.

Was this guide helpful?