Is it okay to delete the macOS Xcode CoreSimulator devices folder?

Question

My ~/Library/Developer/CoreSimulator/Devices folder is 26 GB.

Is it safe to just delete all the content? Will those files be automatically regenerated?

Anton

See furbo.org/2022/11/09/managing-xcode-downloads (can remove some large Xcode downloads via Xcode preferences -> platforms) – Unclad

Answer 1

Try to run xcrun simctl delete unavailable in your terminal.

Original answer: Xcode - free to clear devices folder?

Fonsie

does this clear the Cache folder as well on only the Devices folder? – Formation

Answer 2

That directory is part of your user data and you can delete any user data without affecting Xcode seriously. You can delete the whole CoreSimulator/ directory. Xcode will recreate fresh instances there for you when you do your next simulator run. If you can afford losing any previous simulator data of your apps this is the easy way to get space.

Update: A related useful app is "DevCleaner for Xcode" https://apps.apple.com/app/devcleaner-for-xcode/id1388020431

Edholm

A note of caution: The fresh instances are only re-created if you use the xCode IDE. If you're trying to free space on a CI server which uses xcodebuild script, fastlane or other to build and run your test, best to avoid this method. – Protamine

DevCleaner cleaned my Library/Developer/Xcode folder but not CoreSimulator. Any idea why? – Becka

@Roberto, maybe so that you can still run your apps on the Simulator. I did rm ~/Library/Developer/CoreSimulator/*, opened Xcode, and then tried to run my app on the Simulator. I got an error: "Unable to boot device because it cannot be located on disk. Domain: NSPOSIXErrorDomain Code: 2 Failure Reason: The device's data is no longer present at ~/Library/Developer/CoreSimulator/Devices/B2EFB6F6-6A64-4521-83A4-94EA45420073/data. Recovery Suggestion: Use the device manager in Xcode or the simctl command line tool to either delete the device properly or erase contents and settings." – Fain

It may have been safe to remove this directory before but Xcode seems to need it now. Otherwise one gets @Fain 's error. – Adytum

I guess you'll need to re-create devices. Before deleting the whole directory I guess it's best to delete the simulators one by one in xcode->window->devices and simulators – Spurt

Answer 3

For iOS developers who find that they have very little available storage space without knowing why:

Check how many simulators that you have downloaded as they take up a lot of space (previous ones are not removed when you update XCode so this will quickly add up):

Go to: ~/Library/Developer/Xcode/iOS DeviceSupport

Also delete old archived apps that are no longer important to you:

Go to: ~/Library/Developer/Xcode/Archives

I cleared 100GB doing this.

UPDATE: You can now easily do this by just going to the Apple icon in the top left corner -> About this Mac -> Storage -> Manage... -> Developer

Sipes

Be careful. You may want to keep the archives for builds you've released. Technical Note TN2151: Understanding and Analyzing Application Crash Reports: Symbolicating Crash Reports says: "Important: To symbolicate crash reports from testers, app review, and customers, you must retain the archive for each build of your application that you distribute." – Fain

Yeah I store relevant archives (esp of prod builds) on a hard drive in case I need them later – Scornik

This is outdated, in xcode 15 (and 14 in some cases) simulators are stored in ~/Library/Developer/CoreSimulator – Spurt

Answer 4

for Xcode 8:

What I do is run sudo du -khd 1 in the Terminal to see my file system's storage amounts for each folder in simple text, then drill up/down into where the huge GB are hiding using the cd command.

Ultimately you'll find the Users//Library/Developer/CoreSimulator/Devices folder where you can have little concern about deleting all those "devices" using iOS versions you no longer need. It's also safe to just delete them all, but keep in mind you'll lose data that's written to the device like sqlite files you may want to use as a backup version.

I once saved over 50GB doing this since I did so much testing on older iOS versions.

Tuneberg

GrandPerspective is a great tool to find what space is being used where, clearer & faster than du. (grandperspectiv.sourceforge.net). – Aleshia

I would recommend using ncdu (also available via Homebrew and MacPorts) instead of running du over and over again. it gives you an interactive drill-down interface in your terminal, and will also let you delete folders, etc. – Pineapple

Diskinventory also works. ~/Library/Logs/CoreSimulator/CoreSimulator.log grew over 2GB in a few days. Probably because I leave my simulator running the background all the time (out of lazyness) and it would log everything including all the verbose hardware and keeplalive and whatnot that ios produces. just guessing – Spurt

Answer 5

In addition to xcrun simctl delete unavailable, you can also clean up all simulated OS data and apps at once:

 xcrun simctl erase all

That is, in case you don't need the data and installed apps on the simulators. Which you most likely don't - Xcode will install the OS and your app(s) next time you run it in one of the simulators.

This might free up some more gigabytes of disk space.

(Also in case xcrun says simctl could not be found: make sure the location of your dev tools is correctly specified in Xcode Preferences -> Locations -> Command Line Tools)

Szymanski

Answer 6

You can also remove ~/Library/Developer/CoreSimulator/Caches/dyld/ directory and free a lot of memory.

Outofdoors

Answer 7

I created a small command-line utility that cleans the CoreSimulator folder and some other Xcode-related folders that might take up extra space, specified in this answer. If you think this is something that would help you, you can check it out here.

Bareback

Although this is probably a good solution, I downvoted for a requirement to install a language (Go) and a whole brew package with a host of dependencies. Things should be kept simpler, you could have written this in bash/zsh to make it more usable for everyone. – Szymanski

This looks awesome, I love that you've been maintaining it with updates! – Graceless

@Szymanski Go compiles to native code, when you get this from brew, you don't need to install a language. Second thing you got wrong is that this brew has 0 dependencies. Third, I would argue that a brew is much simpler and your a bash/zsh suggestion is actually unnecessarily complex. (Think about how difficult it would be to receive updates and bugfixes with a bash/zsh script, and I would have to manually setup an alias to use the tool from the terminal directly). Also, from the developer's perspective, with Go he gets a great testing framework (which he has used to write tests). – Graceless