~/Library/Developer is huge: what every folder inside it does

If you've found your Library Developer folder huge, tens or even hundreds of gigabytes in ~/Library/Developer, the space almost always sits in four places. Your simulators, Xcode's DerivedData, device support files and archives together usually make up nearly all of it.

Every other folder in there is small: settings, indexes, profiles and a few files Xcode keeps for itself. They're worth knowing about, but they're rarely why the folder is large.

What differs is what removing each part costs. Some folders come back by themselves, some are downloaded or copied again, and two kinds can't be made again at all: archives of builds you shipped, and your own Xcode settings.

So don't move the whole folder to the Trash. Work through it folder by folder, using Xcode's own windows where they exist. This post explains what every folder inside does, which ones matter for space, and the order to clean them up in.

For Xcode's storage as a whole, including the simulator runtimes kept outside this folder, see why Xcode takes up so much space.

What is ~/Library/Developer?

It's the working folder for Apple's developer tools in your user account. Xcode, the simulator service and the tools that talk to your devices all keep their data here. It appears the first time you open Xcode or install developer tools, and it stays when you remove them.

How do you open it in Finder?

Your Library folder is hidden by default, so the quickest way in is Go › Go to Folder… in Finder. Enter ~/Library/Developer and press Return. The tilde stands for your home folder.

To see sizes, choose View › as List, then View › Show View Options and select Calculate all sizes. Click the Size column to put the largest folders first.

Is it the same as /Library/Developer?

No. /Library/Developer, without the tilde, is a separate folder at the top of the disk that belongs to the whole Mac. It holds simulator runtimes, the Command Line Tools and parts Xcode installs for every account. It's covered near the end of this post.

Which tools write to it?

Mostly Apple's: Xcode and its build system, the simulator service behind CoreSimulator, the device service that talks to iPhones and other devices, and Swift toolchain installers.

Third-party tools that work with Xcode sometimes add a folder of their own. On the Mac we measured, one such tool had added a folder of under 1 MB. Those folders follow their tool's rules, not Xcode's.

Why doesn't Storage settings explain it?

Storage settings doesn't list this folder's contents. Depending on how macOS sorts them, its files count under a Developer category or under System Data, which Apple describes as files that don't fit the other categories and doesn't let you manage there.

Finder's sizes and Xcode's own windows are the tools that show what's inside, and they're what this post uses.

Why the Library Developer folder is huge

Nothing in it is removed when you update Xcode, and very little is removed when you stop using something. It's a record of every project you've built, every device you've connected and every simulator you've run.

Which folders hold the space?

• CoreSimulator: your simulators10–600 GB · Usually safe
• Xcode/DerivedData5–100 GB · Safe
• Xcode: device support folders5–60 GB · Safe
• Xcode/Archives1–50 GB · Review first
• Preview and test simulators1–20 GB · Safe

Typical ranges on Macs that have these folders, from the research behind the app's catalog. The top of each range is rare. The last range also covers Xcode's caches, which live elsewhere. Simulator runtimes aren't in this folder and are left out.

The ranges are wide because developers' Macs differ so much. What they show is the shape: simulators and DerivedData usually lead, device support follows, and archives grow slowly with each release.

A measured example

On the developer's Mac we measured for this post, with Xcode 27, ~/Library/Developer held about 12 GB. DerivedData took 7.9 GB, the CoreSimulator folder 2.4 GB and archives 2 GB. Every other folder in it, together, came to less than 50 MB.

That Mac had no device support folders at all. On a Mac that debugs on several iPhones and an Apple Watch across years of updates, device support can be one of the largest folders.

Why doesn't it shrink when you update or remove Xcode?

An Xcode update replaces the app and nothing else. Moving Xcode to the Trash removes only the app, too. Your simulators, DerivedData, device support and archives stay where they are, because they're yours, not part of the app.

That's also why reinstalling Xcode doesn't free space. The folder is still there when the new copy opens.

Does it grow when you're not using Xcode?

Barely. Almost everything in it is written when you build, test, run a simulator, connect a device or archive a build. A Mac that hasn't opened Xcode in months keeps the folder at the size it was then.

It doesn't shrink on its own either. Apple doesn't document any automatic clean-up of these folders, so what you stopped using is still there until you remove it.

Every folder inside, at a glance

Here's what you'll usually find, what each folder does, and what removing it costs. Not every Mac has all of them: some appear only when you use a feature.

Folder	What it does	Comes back?
CoreSimulator	Your simulators, their apps and data	Only as new, empty simulators
Xcode/DerivedData	Build files, indexes and logs per project	Yes, on the next build
Xcode/iOS DeviceSupport and siblings	System symbols copied from your devices	Yes, from a device on that version
Xcode/Archives	Builds you archived, with their dSYMs	No
Xcode/UserData	Your Xcode settings, profiles, preview simulators	Settings: no. Previews: yes
XCTestDevices	Simulator clones from parallel test runs	Yes, on the next test run
XCPGDevices	Simulators that run playgrounds	Yes, on the next playground run
CoreDevice	A view of your devices' files	Not a copy; almost no space of its own

The smaller folders, such as Products, CodingAssistant, DVTDownloads and Toolchains, are covered further down.

Which folders come back by themselves?

DerivedData, Xcode's preview, test and playground simulators, and CoreSimulator's caches and logs. Xcode or the simulator service makes them again when they're needed. Removing them costs time: a slower first build, preview, test run or simulator boot.

Which come back only with your help?

Device support comes back when you connect a device on that OS version, but not for versions no device of yours runs anymore. Simulators come back only as new, empty ones, without the apps and test data you had.

Which can't be made again?

Archives of builds you shipped, because each build is unique, and your Xcode settings in UserData, such as custom key bindings. These are the reason the folder as a whole should never go to the Trash.

Simulators: CoreSimulator, XCTestDevices and XCPGDevices

Three folders here hold simulators, and together they're often the largest part. Each is a separate group of simulators, called a device set.

CoreSimulator

~/Library/Developer/CoreSimulator/Devices has one folder for each simulator you've created or run, each holding its installed apps, their data and the simulated system's own files. Next to it, a Caches folder holds data the simulator service can build again.

Simulators are Usually safe in the catalog: remove the ones you no longer use in Xcode's Device Hub, or in Devices and Simulators in Xcode 26. Inside each simulator, discarded app data can also pile up in Dead folders, which are Safe to remove. The post on CoreSimulator taking up space covers every part of this folder.

XCTestDevices

When you run tests in parallel on a simulator, Xcode clones it several times and runs part of the tests on each clone. Clones from earlier runs can stay behind here.

They're Safe: Xcode makes new clones the next time you run tests in parallel. Don't remove them while a test run is going, because it stops.

XCPGDevices

To run a playground for iOS or another device platform, Xcode builds it as a small app and runs it on a simulator kept here. These playground simulators are Safe, and Xcode creates them again on the next playground run.

What about simulator runtimes?

Runtimes, the system images simulators boot, aren't in your Library folder at all. They're in system folders that macOS manages, removed in Xcode › Settings › Components. The post on deleting old simulator runtimes explains where they are and how to remove them.

The Xcode folder

~/Library/Developer/Xcode is where Xcode keeps everything that belongs to your projects, your devices and your setup. It mixes parts that rebuild by themselves with parts you can't get back.

DerivedData

DerivedData holds one folder per project, named after the project with a string of letters added, with its intermediate build files, the index Xcode uses for code navigation, and build logs. Next to the project folders sit shared ones, such as the module cache, that every project uses.

DerivedData is Safe: Xcode rebuilds it the next time you build or open a project. The cost is a full, slower build, a fresh index and a new download of each project's packages.

Quit Xcode first, and start with the folders of projects you've stopped working on. In Xcode 27, Product › Delete Derived Data… removes the open project's folder for you. The post on Xcode DerivedData goes through each part of it.

iOS DeviceSupport, watchOS DeviceSupport and others

When you connect an iPhone, iPad, Apple Watch, Apple TV or Apple Vision Pro for development, Xcode copies that OS version's symbols from it, one set per OS version and device model. They're Safe, because Xcode copies a set again from a device running that version.

Sets for versions none of your devices run anymore can't be copied again, so keep those only if you still read crash reports from them. The post on iOS DeviceSupport and Xcode archives goes through which sets to keep.

Each platform has its own folder: iOS DeviceSupport, watchOS DeviceSupport, and so on for tvOS and visionOS. The catalog notes that copying a set again takes a few minutes for an iPhone and can take much longer for an Apple Watch, so the watchOS folder is the one to trim with the most care.

Archives

Each time you choose Product › Archive, Xcode keeps the build and its dSYM files here, in a folder for each day. Apple's guidance is to keep the archive of every build you distribute, because its dSYMs are the only ones that match that build's crash reports.

Archives are Review first in the catalog and never start checked. Remove test archives that never left your Mac, and copy old shipped ones to a backup drive rather than deleting them. Apple's crash report steps use Spotlight to find a missing dSYM, so a drive Spotlight can search is the handiest place.

UserData

UserData is your Xcode setup, not a cache. Depending on what you've used, it holds your custom key bindings, color themes and code snippets, and Apple's release notes say Xcode 16 and later keep your downloaded provisioning profiles here, in a Provisioning Profiles folder.

It also holds two device sets. Previews holds the simulators Xcode runs SwiftUI previews on, which can grow to many gigabytes. They're Safe, because Xcode makes them again for the next preview, but Xcode's windows have no button to remove them; the last section shows what the app runs instead.

IB Support holds a small set of simulators that Interface Builder uses. On the Mac we measured, it took about 37 MB, so there's nothing to gain from it.

Leave the rest of UserData alone. App settings aren't caches, and clearing them frees almost no space while resetting your Xcode setup.

Folder in UserData	What it is	Remove it?
KeyBindings	Key bindings you customized	No: it's your setup
FontAndColorThemes	Editor themes you made or imported	No: it's your setup
CodeSnippets	Code snippets you saved	No: it's your work
Provisioning Profiles	Profiles Xcode downloaded for signing	No: signing uses them
Previews	Simulators for SwiftUI previews	Yes: Xcode makes them again
IB Support	Simulators Interface Builder uses	No need: it's small

Other folders can appear here as you use features, such as Xcode Cloud or capabilities. Apple doesn't document most of them, and on the Mac we measured, none took more than 1 MB.

Products and CodingAssistant

A folder named Products holds a folder for each app you've distributed, named after its bundle ID, with a folder for each version and its icon. Apple doesn't document it; Xcode's Organizer appears to use it to show your apps. On the Mac we measured, it took under 5 MB.

Folders named CodingAssistant can appear both in the Xcode folder and in UserData. On the Mac we measured, both were nearly empty, and Apple doesn't document what goes in them.

DocumentationCache and DocumentationIndex

On some Macs, Xcode keeps folders with these names for its developer documentation. An Apple engineer said on the forums that you can delete DocumentationCache, with DocumentationIndex at the same time, and that Xcode rebuilds it, probably smaller.

Recent versions of Xcode download documentation as a system asset, managed by macOS, so these folders may not exist on your Mac at all. The app's catalog doesn't cover them yet.

The small files at the top

You may also see files such as SDKToSimulatorIndexMapping.plist. They're small indexes Xcode keeps for itself, under 100 KB each. There's no space to gain from them, so leave them in place.

CoreDevice, Toolchains, DVTDownloads and other folders

The rest of ~/Library/Developer is a handful of smaller folders. One looks large to some disk tools without taking any space, and one holds tools you may have installed yourself.

CoreDevice

Apple's current documentation says the files of every paired device and started simulator can be browsed at ~/Library/Developer/CoreDevice/DeviceFS, which Finder shows as Devices. That's a mount point: a view of files that live elsewhere, not a second copy.

A disk tool that adds up mounted folders can count a simulator's files twice, once in CoreSimulator and once here. The space is only used once.

You also can't move DeviceFS to the Trash, and there's no reason to try. Apple notes that the device files there are mostly read-only, and the folder holds no space of its own to gain.

Toolchains

If you've installed Swift toolchains from swift.org or with swiftly, they live in ~/Library/Developer/Toolchains, or in the system-wide Developer folder for every account. Each one is a complete Swift compiler and its tools, and Xcode lists them in Xcode › Toolchains.

Swift toolchains are Review first in the catalog. Projects, scripts or editors set to use one stop working until it's installed again, and old snapshots may not be available to download. The Swift that comes with Xcode isn't affected; toolchains installed with swiftly can also be removed with swiftly.

DVTDownloads

Apple doesn't document this folder. On the Mac we measured, it held an empty folder named after the Metal toolchain, and nothing else. Its name and contents suggest Xcode uses it while it downloads components. There's no space to gain there.

Folders from other tools

Third-party developer tools sometimes keep their own folders in ~/Library/Developer, named after the tool. They're not Xcode's, so Xcode's rules don't apply to them. Check the tool's own documentation or settings before removing one, and look at its size first: most are small.

The system-wide /Library/Developer folder

Many people find this folder while looking for the one in their Library. It belongs to the whole Mac, its contents are owned by the system, and most of it is managed through Xcode or Software Update rather than Finder.

What's in it?

Folder	What it holds	How it's managed
CoreSimulator	Simulator runtimes and their library cache	Xcode › Settings › Components
CommandLineTools	The Command Line Tools for Xcode package	Software Update; removal only in Terminal
Toolchains	Swift toolchains installed for every account	Remove after checking nothing uses them
CoreDevice, DeviceKit, DeveloperDiskImages, PrivateFrameworks	Parts Xcode installs for devices and simulators	Installed and updated by Xcode

The Command Line Tools

Apple's documentation says the Command Line Tools for Xcode package installs at /Library/Developer/CommandLineTools. It contains the same macOS SDK, manual pages and compilers that ship with Xcode, as an alternative to a full Xcode for people who work outside it. On the Mac we measured, it took about 2 GB.

If you have Xcode, Apple says you don't need the package separately. But other tools, such as git from the command line, can rely on it. Apple documents removing it only as an administrator command in Terminal, with no app or Finder route, so leave it unless you're sure nothing uses it.

Do you need both Xcode and the Command Line Tools?

Usually not, but many Macs have both. Package managers and other developer tools often install the Command Line Tools on their own, and Xcode arrives later, or the other way round.

At about 2 GB, the duplicate is rarely worth the risk of removing. Apple also notes that after you remove the package, Software Update keeps offering new releases of it unless its receipt is removed too, which is another Terminal-only step.

Simulator runtimes and the rest

The CoreSimulator folder here holds runtime images and their library cache. Runtimes are Managed by macOS: remove them in Components settings, and never in Finder. The other folders are installed by Xcode, typically when it first opens or after an update, and they belong to it.

A safe order for cleaning up ~/Library/Developer

Start with what comes back by itself, then decide on what costs you something. Quit Xcode and shut down your simulators before you remove anything in Finder.

Before you start

• Make sure every app you shipped has its archive backed up somewhere other than this Mac.
• Let any build or test run finish, then quit Xcode.
• Shut down running simulators, in Device Hub or in the Simulator app.
• Copy any app or tool you built and still use out of DerivedData.
• Note the folder's total size, so you can see what each step gained.

Step by step

1. Measure. Open the folder in Finder with Calculate all sizes on, and note which folders are large.
2. Delete runtimes you don't test on, in Xcode › Settings › Components. They're elsewhere, but removing them leaves simulators unavailable, which you'll remove next.
3. Remove unused simulators in Device Hub in Xcode 27, or Devices and Simulators in Xcode 26, and reset busy ones full of old test data.
4. Quit Xcode. Then move the DerivedData folders of projects you've finished to the Trash.
5. Move old device support sets for OS versions none of your devices run to the Trash.
6. Review archives in Window › Organizer. Back up shipped builds, and remove test archives.
7. Check your work: build a project, open a preview and connect a device. Then empty the Trash.

What each folder costs to remove

Folder	What removing it costs	Level
Xcode/DerivedData	A full build and re-index per project	Safe
Device support sets	A wait when a device connects; old versions lost	Safe
Preview, test and playground simulators	A slower first preview, test run or playground	Safe
CoreSimulator's caches and Dead folders	A slower first simulator boot	Safe
Your simulators	Their apps, data and settings	Usually safe
Xcode/Archives	The build and its dSYMs, for good	Review first
Xcode/UserData settings	Your Xcode setup and profiles	Leave it

A worked example

Say ~/Library/Developer holds 140 GB. Finder shows CoreSimulator at 70 GB, DerivedData at 38 GB, iOS DeviceSupport at 22 GB, Archives at 8 GB and everything else under 2 GB.

Remove eight unavailable simulators and the Dead folder of your daily one: about 45 GB. Clear DerivedData for the six projects you've finished: 25 GB. Keep the device support set for the iOS version your phone runs and remove the other five: 18 GB. Keep the archives. About 88 GB comes back, and every project still builds.

Mistakes and edge cases

The folder has a few traps, most of them from advice that treats it as one big cache.

Can you delete ~/Library/Developer entirely?

It's the most common advice, and it's the one to avoid. It takes your shipped archives, your simulators' test data, your Xcode settings and profiles, and device support for devices you no longer have, along with the parts that rebuild. Some of that can't be made again.

An Apple engineer advised on the forums to quit Xcode before deleting anything, and to manage simulators through Xcode's windows or its command-line tool rather than by hand. Working folder by folder keeps the parts you need.

Do any apps run from this folder?

Only ones you built yourself. If you use a Mac app or tool you built in Xcode and never copied anywhere else, the only copy may be in a DerivedData project's Products folder, and deleting DerivedData removes it.

Copy anything you rely on to Applications, or archive and export it properly, before you clear DerivedData. Apps you downloaded or installed don't live here.

Does removing Xcode clean it up?

No. Moving Xcode to the Trash leaves this folder exactly as it was. If you're done with Xcode for good, delete the runtimes you don't need in Components settings first, while Xcode can still show them, then remove the app, then work through this folder.

What about a Mac with several accounts?

Each account has its own ~/Library/Developer, so cleaning yours doesn't touch anyone else's simulators, archives or settings. The system-wide folder, with runtimes and the Command Line Tools, is shared by everyone, so changes there affect all accounts.

Does Time Machine back it up?

Apple doesn't document how Xcode marks these folders. On the Mac we measured, Time Machine was set to skip CoreSimulator's caches and each project folder in DerivedData, but to back up simulators, archives and UserData.

That's a sensible split: archives and your settings are worth backing up, while simulators are bulky and mostly test data. To leave simulators out too, choose Apple menu › System Settings, click General, then Time Machine, click Options, and add the CoreSimulator folder to the list.

Will a smaller folder make Xcode faster?

No. Removing these folders frees disk space and nothing else. The first build, preview and simulator boot afterwards are slower while Xcode rebuilds what it needs. The space matters when the disk is nearly full, for example to fit a macOS update or the next Xcode.

Keeping it small on a Mac with little storage

On a 256 GB or 512 GB Mac, this folder can crowd out everything else. The aim isn't to empty it, which only costs you rebuilds, but to stop it collecting what you no longer use.

Which folders can live on another drive?

Three of them. Apple's Developer Technical Support has said that Xcode itself, and the Derived Data, Archives and Compilation Cache locations in Xcode › Settings › Locations, can live on an external drive. Format it as APFS, and use a fast one, since DerivedData is read and written on every build.

The rest, including simulators and device support, has no setting to move it. Apple doesn't describe a supported way to keep them elsewhere, so keep those small instead.

How many simulators do you need?

Fewer than most Macs have. A simulator is quick to create when you need it, and a new one starts empty anyway, so there's no reason to keep one for every device and OS version you've ever tested.

Keep one or two for the devices you test on daily, and erase them when their test data grows. Create others for a specific check, then remove them in Device Hub when you're done.

What to do after each update

When	What to remove	Where
A device updates its OS	The device support set for the old version	Finder, in the Xcode folder
A major Xcode release	Runtimes and simulators you no longer test on	Components settings and Device Hub
You finish a project	Its DerivedData folder	Product › Delete Derived Data… or Finder
You remove a git worktree	Its DerivedData folder	Finder
A release has shipped	Test archives that never left your Mac	Window › Organizer

None of these takes more than a few minutes, and together they keep the folder close to what you use now.

What changed in recent Xcode versions

The folder's layout has stayed much the same for years, but a few recent changes affect what you'll find and where you manage it.

Change	Version	What it means here
Provisioning profiles stored in UserData	Xcode 16	A Provisioning Profiles folder in UserData
Opt-in compilation caching	Xcode 26	A CompilationCache.noindex folder in DerivedData
Device Hub manages simulators	Xcode 27	Remove simulators there, not in Devices and Simulators
Delete Derived Data in the Product menu	Xcode 27	One project's DerivedData, without Finder
A shared mount point for device files	Current documentation	CoreDevice/DeviceFS, shown in Finder as Devices

If you use both Xcode 26 and Xcode 27, they share this folder. Simulators, DerivedData and archives made by one are visible to the other, so clean up from either, not both at once.

How the app does it

Wombit explains the folders in ~/Library/Developer like everything else on the disk. Select one in the map, the app's home screen, and the inspector says what it is, how safe it is to remove and what removing it costs, from the catalog's entry. It reads only names, sizes and dates, and file names and paths never leave your Mac.

Cleanup lists the parts the catalog knows by level:

• DerivedData, device support, Xcode's caches, CoreSimulator's caches and logs, the Dead folders inside simulators, and the preview, test and playground simulators are Safe. They count toward the safe total and start checked.
• Archives and Swift toolchains are Review first and wait for your choice.
• Your simulators are Usually safe, explained with Xcode's steps, and runtimes are Managed by macOS: the app leaves removing both to Xcode.

Folders go to the Trash, where you can put them back. For the three device sets Xcode makes for itself, the app runs Xcode's own tool instead, after the review sheet, and the sheet says that can't be undone.

• ~/Library/Developer/Xcode/DerivedData

  Xcode DerivedData

  Build products, indexes and logs Xcode keeps for every project you've built.

  Safe · Moves it to the Trash

• ~/Library/Developer/Xcode/* DeviceSupport

  Xcode device support files

  Symbol files Xcode copies from each iPhone, iPad, Apple Watch, Apple TV or Apple Vision Pro you connect, one set per OS version.

  Safe · Moves it to the Trash

• ~/Library/Developer/Xcode/Archives/*/*.xcarchive

  Xcode archives

  Copies of each build you archived in Xcode, with the dSYM files needed to read crash reports from that build.

  Review first · Moves it to the Trash

• ~/Library/Developer/CoreSimulator/Devices

  Simulator devices

  The simulated devices you run apps on from Xcode, each with its own installed apps, data and settings.

  Usually safe · Explained only: the app shows you how

• ~/Library/Developer/Xcode/UserData/Previews/Simulator Devices

  SwiftUI Previews simulators

  Simulator devices that Xcode creates to show SwiftUI previews in the canvas.

  Safe · Runs xcrun simctl --set previews delete all

• ~/Library/Developer/Toolchains/*.xctoolchain

  Swift toolchains

  Swift compilers and tools you installed from swift.org or with swiftly, separate from the Swift that comes with Xcode.

  Review first · Moves it to the Trash

Seeing all of this is free. Cleanup is PRO, one $4.99 payment with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.