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/DerivedDataYour 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.
- Quit Xcode. Deleting DerivedData while Xcode builds or indexes can leave it confused until the next restart.
- 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:
- Choose Window > Organizer and select Archives.
- Select an app on the left, then the archives you no longer need.
- 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 unavailableThis 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/Cachesholds 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 allremoves them; Xcode creates new ones when you open a preview. - Swift Package Manager. Downloaded package repositories are cached
in
~/Library/Caches/org.swift.swiftpm. Runswift package purge-cacheto 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.
