Is it safe to delete ~/Library/Developer?

Part of: Mac disk cleanup for developers: every cache, what it costs to rebuild (Developers)

Do not delete the whole ~/Library/Developer folder in one go. Most of it is disposable, but a few parts are not. Go through it one subfolder at a time and the answer for each is simple.

The tilde, ~, is shorthand for your home folder. The hidden Library folder inside it holds app data. Developer is where Xcode keeps your user-level data.

See what is inside

Run this in Terminal:

du -sh ~/Library/Developer/*/* ~/Library/Developer/CoreSimulator

You may see only some of the folders below. Not every Mac has used every feature.

Safe, risky, never

• Safe: Xcode/DerivedData and CoreSimulator/Caches. They rebuild on their own. Cost: a slower next build.
• Risky: CoreSimulator/Devices. It holds simulated devices and the apps and data in them. Cost: you lose that test data and set the device up again.
• Never: Xcode/Archives unless you are sure you do not need to read crash reports from those builds. Also be careful with Xcode/UserData, which can hold your own settings such as key bindings and code snippets.

The subfolders

Xcode/DerivedData. Build output and indexes. Safe to clear. The next build of each project starts from scratch.

Xcode/iOS DeviceSupport. Debug symbols copied from real devices. Safe to clear. Xcode copies them again when you reconnect a device on that system version.

Xcode/Archives. The builds you shipped, with the symbols needed to read their crash reports. Keep them unless you are certain you will never need them.

Xcode/UserData. Your own settings. It is small, so there is little to gain and something to lose. Leave it.

CoreSimulator/Devices. One folder per simulated device. Each holds the apps you installed on it and their data. Removing a device deletes all of that. You can also list devices with xcrun simctl list devices before you decide.

CoreSimulator/Caches. Cache files for the simulators. Safe, and often small.

The simulated operating systems themselves, called runtimes, are usually stored outside your home folder, under /Library/Developer/CoreSimulator. Remove them from Xcode’s own settings. See the CoreSimulator guide.

What breaks and what it costs

• Clearing DerivedData breaks nothing. You pay with a rebuild of every project you open next.
• Clearing DeviceSupport breaks nothing. You pay with a symbol copy of a few minutes per device and system version.
• Removing simulator devices loses their apps and data. You pay with setup time.
• Removing Archives can make old crash reports unreadable. Nothing rebuilds them. A build you have to recreate may not produce the same symbols.

If you delete the whole folder by mistake, Xcode recreates the empty structure and works. The things that are gone for good are archives and the data inside simulators. The file in the Xcode guide goes further into each build cost.

How to remove a subfolder

1. Quit Xcode and any running simulator.
2. Check the sizes with the command above and choose what is worth removing.
3. Move the chosen subfolders to the Trash in Finder, not the whole Developer folder.
4. Empty the Trash. The space comes back only then, as the Trash article explains.

What about a Mac without Xcode?

If you uninstalled Xcode, or only installed the command line tools, the Developer folder may be small or missing. A leftover folder with only caches in it is fine to remove. Check its contents with du -sh first so you know what you are deleting.

The wider list of developer folders, including those outside Library, is in the developer cleanup guide.

Worked example: a quick audit

List the top level of the folder first:

ls ~/Library/Developer

On the Mac used to check this article, it showed CoreDevice, CoreSimulator, DVTDownloads, Xcode and XCTestDevices. Three of them are not covered above:

• CoreDevice was about 1.4 MB, and XCTestDevices was empty. We did not look inside, so we cannot say what they are for. Leave them. They are too small to matter.
• DVTDownloads was empty (0 bytes) on that Mac. Check its size with du -sh on yours before you decide anything.

The rule is simple. If you cannot name what a folder is, do not remove it. Look up the name first.

A three-step safe order

1. Clear Xcode/DerivedData for projects you have finished. It is the lowest risk.
2. Look at the runtimes with xcrun simctl list runtimes and remove old ones in Xcode.
3. Stop there, and measure again. Archives and UserData stay.

The first step usually gives the best return per minute. If it frees enough room, you are done.

If something goes wrong

• Xcode will not start a simulator. A device folder may be damaged. Quit Xcode and the simulator, and open Xcode again. If it still fails, create a new device.
• You deleted Archives and now need a crash report. The archive is gone. A new build will not match the old symbols. This is why we say never.
• Your key bindings or snippets vanished. They were in Xcode/UserData. Restore from a Time Machine backup if you have one.
• Xcode complains about a missing folder. It recreates it on the next launch. Restart Xcode.

When not to clean

Do not touch this folder while Xcode is archiving or running tests. A half-finished build and a deleted folder do not mix. Wait for it to end.

See it before you decide

DiskJoy is our product. Its scan shows how large ~/Library/Developer and its parts are, read-only. Cleanup is not built yet, so DiskJoy does not delete any of this today. Use the scan to find the big parts and the steps above to remove them.