If you've found CoreSimulator taking up space on your Mac, the folder to look at is ~/, and almost all of its size is in one place: the Devices folder inside it. That's every simulator you've created or run, each with its own apps, their data and a full set of the simulated system's own files.
Two smaller things add to it. Each simulator can keep a folder named Dead, where discarded app data waits to be deleted and sometimes stays. And a Caches folder holds data the simulator service can build again.
The simulator runtimes, the system images simulators boot, aren't in this folder at all. They live in system folders that Xcode manages, and the post on deleting old simulator runtimes covers them.
So the fix comes in three parts. Remove the simulators you no longer use in Xcode, and reset the ones full of old test data. Move the Dead folders and the Caches folder to the Trash after quitting Xcode. Leave the rest of the folder alone, because it's the state of simulators you still use.
What's inside the CoreSimulator folder
Your Mac has two folders with this name, and they hold different things. The one in your own Library folder belongs to your account and holds your simulators. The one in the Library folder at the top of the disk belongs to the whole Mac and holds runtimes.
Which CoreSimulator folder are you looking at?
Check the start of the path. ~/, with the tilde, is inside your home folder. /, without it, is the system-wide folder that holds runtime images, mounted runtimes and the runtimes' library cache.
The system folder is owned by macOS, and its contents are removed through Xcode's Components settings, not in Finder. Everything below is about the folder in your own Library, unless it says otherwise.
What does each folder inside it hold?
Open it in Finder with Go › Go to Folder… and you'll usually find three folders. Each has a different job and a different cost if it goes.
| Item | What it holds | Level |
|---|---|---|
Devices | One folder per simulator, with its apps, data and settings | Usually safe, with a cost |
Devices/device_set.plist | The set's list of default simulators and watch pairs | Leave it |
Devices/…/com.apple.containermanagerd/Dead | App data a simulator discarded but kept | Safe |
Caches | Data the simulator service builds again by itself | Safe |
Temp | Not documented by Apple; usually empty | Leave it |
Apple doesn't document the Temp folder. On the Mac we measured for this post, it held one empty folder, so there's nothing to gain there.
Simulator logs aren't in this folder either. CoreSimulator writes them to ~/, a folder for each simulator you've started, and they're covered further down.
How much space is normal?
It depends almost entirely on how many simulators you've used and what your apps saved on them. A simulator that has never been started is small: on the Mac we measured, each such simulator took about 17 MB.
A simulator you use every day is a different matter. It holds the apps you've installed, everything they wrote, and the files the simulated system creates for itself as it runs, from caches to downloaded assets.
- All your simulators (Devices)10–600 GB · Usually safe
- Simulator runtimes, in system folders20–200 GB · Managed by macOS
- Preview and test simulators, Xcode caches1–20 GB · Safe
Typical ranges on Macs that have these files, from the research behind the app's catalog. The top of the Devices range is rare and usually means Dead folders or years of unused simulators.
The Devices range is wide because Macs differ so much. The top end usually comes from Dead folders that were never emptied, which developers on Apple's forums have reported in the hundreds of gigabytes, or from years of simulators nobody removed.
Why does it show up as System Data?
Storage settings doesn't name this folder. Depending on how macOS sorts it, its space appears under a Developer category or inside System Data, which Apple describes as files that don't fit the other categories and says you can't manage there.
Either way, Storage settings won't list your simulators one by one. Finder's Get Info on the Devices folder gives the total, and the steps below show how to find which simulator holds it. The System Data guide explains what else lands in that category.
CoreSimulator taking up space: the usual causes
Nothing in the Devices folder is removed by itself. Xcode updates, new runtimes and finished projects all leave it as it was, so the folder only grows until you step in.
Simulators pile up with every runtime
When you install a runtime, Xcode sets up simulators for common hardware on it, so they appear as run destinations. The file device_set.plist keeps a list of these defaults for each runtime. They cost little until you start one, but each one you do start begins to collect data.
Then there are the simulators you add yourself: a particular iPad for a layout bug, an older iPhone for a customer's report, a watch paired with a phone. Each stays until you remove it.
Simulators outlive their runtime
When you delete a runtime or move to a newer Xcode, the simulators that used it stay on disk. Xcode lists them as unavailable, and they can't start. Their apps and data are still there, taking the same space as before.
Unavailable simulators are the easiest space to recover. Nothing on them can be used until that runtime is installed again, and often it never is.
Your apps keep data between runs
When you run an app from Xcode again, the simulator keeps its data container. Databases, downloaded images, cached video and files the app saved all stay, run after run, so a simulator is as large as everything your app has stored on it.
The simulated system adds its own files too. It keeps caches, indexes and downloaded assets inside the simulator, just as a real iPhone keeps them on its storage.
Discarded data isn't always discarded
When you reinstall or remove an app in a simulator, the simulator can move the app's old data into a folder named Dead, to delete later. Developers on Apple's forums report that these folders aren't always emptied, even after a restart.
That's how a single folder can hold more than every runtime on the Mac. One developer found nearly 600 GB in Dead folders; another reported a new folder after each run, reaching about 60 GB quickly.
Xcode keeps more simulators elsewhere
SwiftUI previews, parallel test runs, playgrounds and Interface Builder each use simulators of their own, kept outside the CoreSimulator folder. They're covered in their own section below, because a disk map shows them in different places.
Inside a simulator's folder
Every folder in Devices is named with a long identifier, such as 256FDA93-84E6-4E1D-A4DE-97CC3201BB6E. That identifier is the simulator's UDID, and Finder can't tell you which iPhone or iPad it belongs to.
How do you tell which folder is which simulator?
Each folder holds a small file named device.plist, which records the simulator's name, device type, runtime and UDID. The quicker route is to match the UDID in Xcode.
- In Xcode 27, open Device Hub with Xcode › Open Developer Tool › Device Hub.
- Select the simulator in the sidebar, then click the Info button at the right of the toolbar.
- Compare the UDID field with the folder name. If the field isn't shown, click Edit Visibility at the bottom of the inspector and turn it on.
In Xcode 26, choose Window › Devices and Simulators and click Simulators. Selecting a simulator shows its identifier, which is the same UDID.
How do you find the largest simulators?
Sort the folders by size in Finder, then look up only the biggest ones. That usually means checking two or three identifiers, not dozens.
- In Finder, choose Go › Go to Folder…, enter the path to the Devices folder and press Return.
- Choose View › as List, then View › Show View Options and select Calculate all sizes.
- Click the Size column to sort. Finder takes a moment to add up each folder.
- Note the identifiers at the top and match them in Device Hub or Devices and Simulators.
Why are some simulators only a few megabytes?
Because they've never been started. Simulators Xcode set up for a runtime hold little more than their settings until you run something on them, so a list of thirty simulators can still be small.
Removing those frees almost nothing. The space is in the few simulators you've actually used, so start there.
What's in a simulator's data folder?
Inside each simulator's folder, a data folder looks like a small iPhone's storage. These are the parts that matter for space.
Folder in data | What it holds |
|---|---|
Containers/Bundle | The apps you installed on the simulator |
Containers/Data | Each app's own data, built-in apps included |
Containers/Shared | Data shared through app groups |
Library | The simulated system's settings, databases and caches |
Library/Caches/com.apple.containermanagerd/Dead | Discarded app data waiting to be deleted |
Media | The simulator's photo library and other media |
private/var | System files, including assets the system downloaded |
None of these folders is meant to be edited by hand, except Dead. They work together, like the storage of a real device, and the simulated system keeps track of what's in each.
Where does a simulator's size come from?
Often less from your own app than you'd expect. Here's one iPhone simulator, used for testing over several months, measured for this post.
- Downloaded system assets0.8 GB
- System settings, data and caches0.7 GB
- System databases in var0.2 GB
- App containers0.1 GB
- Photos and media0 GB
One simulator on one developer's Mac, measured for this post with Finder sizes; about 1.9 GB in all. Your simulators will differ, especially if your app stores large files.
The simulated system's own files took most of the space. So removing your app from a simulator often frees less than you'd expect, while resetting or removing the simulator frees the most.
Can you look at an app's data without digging?
Yes, in Xcode 27. Apple's documentation says the files of every started simulator and paired device appear at ~/, which Finder shows as Devices. That's a view of the simulator's files, not a second copy.
Each device there has folders such as AppDataContainers and AppGroupContainers. It's a cleaner way to see what your app has stored than opening the data folder, and it only lists simulators that are running.
Should you delete files inside a simulator by hand?
No, apart from the Dead folder. Removing files from a simulator's Containers or Library folders behind the system's back can leave it in a state it doesn't expect. Remove the app, reset the simulator or remove it instead; each is a single step in Xcode.
The Dead folders in com.apple.containermanagerd
These folders are the part of CoreSimulator that grows without anyone asking it to. They're also the part that's simplest to clear, because nothing you use is stored in them.
What is the Dead folder?
Inside each simulator, at data/, the service that manages app containers puts the old data of apps you reinstalled or removed. Developers have found it filled with folders named temp followed by an identifier, one for each set of discarded data.
The data is meant to be deleted later. On Apple's forums, developers report that it isn't always, even after a restart, and Apple hasn't explained how long the folders are meant to last.
Is it safe to delete the Dead folder?
Yes. The catalog rates Simulator discarded app data as Safe: it holds only data the simulator had already discarded, and the current data of your apps isn't stored there. Removing it doesn't affect the apps or data you're using.
Shut down the simulator first, so it isn't moving data into the folder while you remove it. Quit Xcode too, since it installs apps on simulators whenever you run them.
How do you remove the Dead folders in Finder?
Any simulator that has been started can have a Dead folder. Start with the largest simulators from the size sort above.
- Shut down every running simulator, then quit Xcode.
- In Finder, open the Devices folder and then a simulator's folder.
- Open data, then Library, then Caches, then com.apple.containermanagerd.
- Select Dead, choose File › Get Info to see its size, and drag it to the Trash if it's large.
- Repeat for the other large simulators, then empty the Trash when you're sure.
Leave the com.apple.containermanagerd folder itself in place. Only the Dead folder inside it holds discarded data.
Why do the Dead folders come back?
Because the simulator keeps working the same way. Each reinstall can move another set of data into Dead, so a simulator you run apps on every day can fill it again.
Apple hasn't documented a fix. Checking the largest simulators after each big round of testing keeps it in hand, and resetting a simulator clears everything on it, Dead included.
The Caches folder and the logs
Next to Devices, CoreSimulator keeps data it can make again. The logs live in another folder but belong to the same service.
What's in CoreSimulator's Caches folder?
The simulator service keeps cached data for your account in ~/. It can include prebuilt copies of the system libraries each runtime uses, which can take several gigabytes. Caches for runtimes you've since removed can stay behind.
It's a different folder from the runtimes' library cache in the system-wide CoreSimulator folder. That one is managed with the runtimes, and the way to shrink it is to keep fewer runtimes.
Is it safe to delete CoreSimulator's Caches?
Yes. Simulator caches are Safe: the service creates what it needs again the next time you use a simulator. The cost is time, because the next simulator you start may take longer to boot while the cache is rebuilt.
Quit Xcode and shut down your simulators first. Move the folders inside Caches to the Trash, or the Caches folder itself; the service creates it again.
What about simulator logs?
CoreSimulator and the simulators write logs to ~/, with a folder for each simulator you've started. They're only used to investigate problems, so they're Safe to remove. You lose the history, and new logs start with the next simulator.
Xcode 27 fixed one cause of large logs. Apple's release notes say CoreSimulator's logs are now rotated continually, rather than only when its service starts. That stops them from growing without limit on Macs that run for a long time between restarts.
What about the Temp folder?
Leave it. Apple doesn't document it, no catalog rule covers it, and on the Mac we measured it held a single empty folder. There's no space to gain there.
Device sets: previews, tests, playgrounds and Interface Builder
The Devices folder is one device set: the simulators you see as run destinations. Xcode keeps several more, each in a folder of its own. A disk map shows them apart from CoreSimulator, so they're easy to miss.
What is a device set?
A device set is a folder of simulators that the simulator service manages as a group. Xcode's command-line tool, simctl, can work on any set by its location, and Xcode uses named sets for its own jobs. Simulators in one set don't appear in another set's lists.
That's why these simulators don't show up in Device Hub or in your run destinations. They belong to Xcode's features, not to you.
Where are the other device sets?
| Device set | Where it lives | Used for |
|---|---|---|
| Your simulators | ~/Library/Developer/CoreSimulator/Devices | Running and debugging your apps |
| Previews | ~/Library/Developer/Xcode/UserData/Previews/Simulator Devices | SwiftUI previews in the canvas |
| Parallel testing | ~/Library/Developer/XCTestDevices | Clones made for parallel test runs |
| Playgrounds | ~/Library/Developer/XCPGDevices | Playgrounds for iOS and other devices |
| Interface Builder | ~/Library/Developer/Xcode/UserData/IB Support/Simulator Devices | Opening storyboards and XIB files |
Why do preview simulators get so big?
Xcode runs SwiftUI previews on simulators of their own, and each one holds builds of the apps you've previewed and the data they created. On Apple's forums, developers have reported the previews folder at 20 GB, 110 GB and 165 GB.
SwiftUI Previews simulators are Safe: Xcode creates them again the next time it shows a preview, which then takes longer to appear. A developer on those forums reported that removing files by hand stopped previews from working, so it's better removed with Xcode's own tool, as the app does.
Xcode 27 changed how preview simulators run, not how much they store. Apple's release notes say simulators booted for previews are now shut down when they're no longer in use, which keeps fewer running at once but leaves their data on disk.
What about parallel testing clones?
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 in ~/.
They're Safe, and Xcode makes new ones next time. Apple's notes for Xcode 27 also say these clones may not appear in Device Hub while they run tests, so don't remove them during a test run.
What about playground and Interface Builder simulators?
To run a playground for iOS or another device platform, Xcode builds it as a small app and runs it on a simulator in ~/. Those are Safe too, and come back on the next playground run.
Interface Builder keeps a small set of its own, which it sets up when it opens a storyboard or XIB file. On the Mac we measured, it held two simulators and 35 MB. No catalog rule covers it, so it's best left alone.
Can other tools create device sets?
Yes. Simctl can create a set in any folder, so a test runner or build tool can keep simulators of its own outside the folders above. Those simulators are kept apart from yours: one developer found they didn't even appear in Safari's Develop menu.
If a disk map shows simulator folders in an unexpected place, check which tool you've installed made them. That tool's own settings or cleanup command is the right way to remove them.
How to clean up CoreSimulator, step by step
Work from the cheapest step to the one that costs the most. Every step here leaves your projects alone, because your source code lives in your own folders, not in a simulator.
Remove simulators you no longer use
In Xcode 27, open Device Hub with Manage Devices… from the run destination menu, or with Xcode › Open Developer Tool › Device Hub. Control-click a simulator you no longer need and choose Remove.
In Xcode 26, choose Window › Devices and Simulators and click Simulators. Control-click a simulator and choose Delete, then confirm.
Apple notes that Device Hub's sidebar lists only simulators you added there or chose as run destinations, so it may not show every folder on disk. The runtime post covers both windows in more detail, including unavailable simulators.
Reset a simulator you still use
Resetting erases every app and its data, and keeps the simulator with its device type and OS version. It suits the simulator you test on every day, once it has filled with old data, and it empties its Dead folder along the way.
In Xcode 27, shut the simulator down in Device Hub, select it, then choose Device › Reset Content and Settings. In Xcode 26, start it and choose Device › Erase All Content and Settings in the Simulator app.
Remove one app and its data
When one app holds most of a simulator's space, remove just that app. In Device Hub, select the simulator, click Apps in the inspector's toolbar, select the app and click the Remove button below the list. A simulator that isn't running needs Start first, so its apps can be listed.
Removing the app takes its data container with it. The next run from Xcode installs it fresh, with no data.
Clear the Dead folders, caches and logs
Quit Xcode and shut down every simulator. Then move the Dead folders of your largest simulators, the contents of CoreSimulator's Caches folder and the folders in the CoreSimulator logs folder to the Trash, as described above.
What each step costs
| Step | What you lose | How it comes back |
|---|---|---|
| Remove a Dead folder | Nothing you use | Not needed |
| Clear CoreSimulator's Caches | A slower first boot | By itself |
| Clear simulator logs | Old troubleshooting history | New logs on the next run |
| Remove one app from a simulator | That app's data on the simulator | Run the app again from Xcode |
| Reset a simulator | Every app and its data | Reinstall from Xcode |
| Remove a simulator | The simulator, its apps and data | Create a new, empty one |
| Remove preview, test or playground simulators | Nothing; Xcode makes them again | By itself, on the next use |
Simulators you remove or reset in Xcode don't go to the Trash; they're gone at once. Folders you drag to the Trash in Finder can be put back until you empty it.
Why didn't the free space go up?
Folders you move to the Trash still take space until you empty it. Check the Trash first, then look again.
If you use Time Machine, its local snapshots can hold on to what you deleted for a while, and the space comes back as they age out. The guide to Time Machine's local snapshots explains how to check. Storage settings also works its figures out in the background, so give it a few minutes.
A worked example
Say Finder shows 48 GB in Devices. Sorting by size puts three folders at the top, at 22 GB, 9 GB and 6 GB, with the rest under 1 GB each.
The 22 GB folder matches an iPhone simulator you test on daily, and its Dead folder holds 15 GB: move that folder to the Trash. The 9 GB folder is an iPad simulator listed as unavailable: remove it in Xcode.
The 6 GB one is a phone you test media uploads on, full of old uploads: reset it. About 30 GB comes back, and nothing you were using is gone.
Mistakes and edge cases
Most trouble with CoreSimulator comes from removing too much at once, or from removing things behind the simulator service's back.
Can you delete the whole CoreSimulator folder?
It's the advice you'll find most often, and it's the one to avoid. It takes every simulator's apps and data at once, including test accounts and saved states you'd have to set up again by hand, and it doesn't touch the runtimes, which live elsewhere.
An Apple engineer advised on the forums that it's best to manage CoreSimulator through Xcode's windows or simctl rather than editing it yourself, and to quit Xcode before deleting anything. Developers who removed the folder's contents by hand have reported errors afterwards, with Xcode unable to find a simulator on disk.
Can you move CoreSimulator to an external drive?
Apple doesn't document a way to. Xcode's Locations settings let you move DerivedData and archives, but not simulators. Workarounds that point the folder at another drive aren't something Apple describes or supports.
Treat simulators as something you remove and create again, not something you move. Keeping fewer of them works better on a small disk than storing them on another one. For a budget of what iOS work needs in all, see how much storage iOS development takes.
What about a Mac with several accounts?
Each account has its own CoreSimulator folder in its own Library, so cleaning up yours doesn't touch anyone else's simulators. Runtimes are shared by every account, which is why deleting one affects everyone; simulators aren't.
What about build servers?
Macs that run tests in continuous integration create simulators and clones on every job, and they rarely need yesterday's. Their own setup is the place to remove simulators after each run. A commenter on Stack Overflow advised against clearing the folder by hand on build servers that use xcodebuild or fastlane.
Does clearing CoreSimulator make a Mac faster?
No. It frees disk space and nothing else. Your Mac and Xcode won't run faster, and the first simulator boot afterwards is slower while caches are rebuilt. The space matters when the disk is nearly full, for example to fit a macOS update or the next Xcode.
Keeping CoreSimulator small
Nothing here is removed automatically, so a few habits do most of the work.
Habits that keep it small
- Keep one simulator for each screen size you design for, rather than one for every model.
- Remove simulators you created for a one-off test when you're done with it.
- After an Xcode update, remove simulators left unavailable by runtimes you deleted.
- Reset your daily simulator when its test data stops being useful.
- Check the Dead folders of your busiest simulators every month or two.
- Clear preview simulators after finishing a large SwiftUI project.
A routine for each Xcode release
- Delete runtimes you no longer test on in Xcode › Settings › Components.
- Remove the simulators that used them in Device Hub or Devices and Simulators.
- Sort the Devices folder by size and check the largest simulators' Dead folders.
- Clear CoreSimulator's Caches folder and the simulator logs.
- Build and run once, so the simulators you kept are ready for work.
The rest of Xcode's files, from DerivedData to archives, are covered in the post on why Xcode takes up so much space.
How the app does it
Wombit explains CoreSimulator's folders 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 them by level:
- The Dead folders inside simulators, CoreSimulator's caches and logs, and the preview, test and playground simulators are Safe. They count toward the safe total and start checked.
- Your simulators are Usually safe. They're explained with the steps for your Xcode version, and the app leaves removing them to Xcode, because only you know which test data matters.
- Runtimes and their library cache are Managed by macOS: explained, and removed through Xcode's Components settings.
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.
What the app runs, after you review itPRO
- xcrun simctl --set previews delete all
- The simulators Xcode made for SwiftUI previews
- xcrun simctl --set testing delete all
- The simulator clones left behind by parallel test runs
- xcrun simctl --set playgrounds delete all
- The simulators Xcode made to run playgrounds
~/
Library/ Developer/ CoreSimulator/ 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/ CoreSimulator/ Devices/ */ data/ Library/ Caches/ com.apple.containermanagerd/ Dead Data from apps you reinstalled or removed in a simulator, which the simulator set aside to delete but kept.
Safe · Moves it to the Trash
~/
Library/ Developer/ CoreSimulator/ Caches Cached data that the simulator service keeps for your user account.
Safe · Moves it to the Trash
~/
Library/ Logs/ CoreSimulator Log files that the simulator service and the Simulator app write while simulators run.
Safe · Moves it to the Trash
~/
Library/ Developer/ Xcode/ UserData/ Previews/ Simulator Devices Simulator devices that Xcode creates to show SwiftUI previews in the canvas.
Safe · Runs xcrun simctl --set previews delete all
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.
Frequently asked questions
Can I delete the CoreSimulator folder on my Mac?
Not as a whole. It holds every simulator's apps and data, and removing it by hand can leave Xcode looking for simulators that are gone. Remove simulators in Device Hub or Devices and Simulators, and move only the Dead folders, the Caches folder and the logs to the Trash.
Why is my CoreSimulator Devices folder so big?
Every simulator you've run keeps its apps, their data and the simulated system's own files, and nothing is removed when you update Xcode. Simulators left unavailable by deleted runtimes and Dead folders that never emptied are the usual extra weight.
What is the Dead folder in com.apple.containermanagerd?
It's where a simulator puts the old data of apps you reinstalled or removed, to delete later. Developers report it isn't always emptied, even after a restart. It holds only discarded data, so it's safe to move to the Trash once the simulator is shut down.
Does deleting a simulator remove the iOS runtime?
No. A simulator is your copy of a device with its apps and data; the runtime is the system image it boots, stored elsewhere and shared by every simulator of that version. Delete runtimes separately in Xcode's Components settings.
Will removing simulators delete my Xcode projects?
No. Your projects and source code live in your own folders. Removing a simulator deletes only the copies of apps installed on it and the data they saved there, which Xcode installs fresh the next time you run.
Is it safe to delete the SwiftUI Previews folder?
The preview simulators are safe to remove, and Xcode creates them again for the next preview, which takes longer to appear. Developers have reported that deleting files there by hand broke previews, so remove them with Xcode's own tool rather than in Finder.
How often should I clean up CoreSimulator?
There's no schedule Apple recommends. Checking after each major Xcode update works well: remove simulators left unavailable, reset the busy ones, and look at the Dead folders of the largest simulators.
Sources
- Managing your simulated and physical devices in Device Hub · Apple
- Configuring the environment of a simulated device · Apple
- Xcode 27 Release Notes · Apple
- Issue with Core Simulator Cache Consuming Disk Space · Apple Developer Forums
- SwiftUI Previews - Disk space issue · Apple Developer Forums
- Xcode Using 90GB with ~/Library/Developer — What Can I Safely Clean? · Apple Developer Forums