SwiftUI previews use disk space in a folder most developers never open. Xcode runs previews on simulators of their own, kept in ~/, and each one holds builds of the apps you've previewed and the data they saved.
That folder usually stays at a few gigabytes. On Apple's forums, developers have reported it at 20 GB, 110 GB and 165 GB, because nothing removes it while you keep previewing new projects and devices.
It's safe to clear: Xcode creates the preview simulators again for the next preview, which then takes longer to appear. What Xcode lacks is a documented button for it, so they're removed with Xcode's own command-line tool.
Previews aren't alone. Xcode keeps clones of simulators for parallel tests, simulators for playgrounds, a small set for Interface Builder, and several caches. This post explains each one, what it costs to remove, and how to keep it small.
How much disk space do SwiftUI previews use?
Less than the parts of Xcode people usually worry about, and more than you'd guess from a feature that shows a small view in a canvas. The research behind the app's rules catalog puts preview and test simulators, together with Xcode's caches, at about 1 to 20 GB on Macs that have them.
The top of that range is reached by Macs that preview many projects, on many device types, over months or years. A Mac that previews one app on one device stays near the bottom.
- Preview and test simulators, Xcode caches1–20 GB · Safe
- DerivedData5–100 GB · Safe
- Device support files5–60 GB · Safe
- Simulator runtimes20–200 GB · Managed by macOS
Typical ranges on Macs that have these items, from the research behind the app's rules catalog. Single reports on Apple's forums put the Previews folder alone at 20, 110 and 165 GB; those are rare.
Where do previews and Xcode's other hidden data live?
All of it is in your own Library folder, away from the simulators you pick as run destinations. That's why a disk map shows it in several places, and why it's easy to miss.
| What it is | Where it lives | Made by | Level |
|---|---|---|---|
| Preview simulators | ~/Library/Developer/Xcode/UserData/Previews/Simulator Devices | SwiftUI previews | Safe |
| Parallel testing clones | ~/Library/Developer/XCTestDevices | Tests run in parallel | Safe |
| Playground simulators | ~/Library/Developer/XCPGDevices | Playgrounds for iOS and others | Safe |
| Interface Builder simulators | ~/Library/Developer/Xcode/UserData/IB Support/Simulator Devices | Storyboards and XIB files | No rule |
| Xcode's caches | ~/Library/Caches/com.apple.dt.Xcode | Xcode and xcodebuild | Safe |
| Shared build folders | Inside ~/Library/Developer/Xcode/DerivedData | Every build | Safe |
The first three are device sets: folders of simulators that the simulator service manages as a group, apart from your own. The CoreSimulator post explains device sets and your own simulators in detail; this post stays with the ones Xcode makes for itself.
Why does the Previews folder keep growing?
Because each preview simulator keeps what it was given. It holds builds of every app you've previewed on it and whatever those apps saved, and the folder grows as you preview more projects and platforms.
Nothing in Xcode trims it. Updating Xcode doesn't, closing a project doesn't, and moving Xcode to the Trash doesn't either, since the folder lives in your Library folder rather than inside the app.
Is the Previews folder the same as DerivedData?
No. DerivedData holds the build output of your projects. The Previews folder holds simulators: small virtual devices with their own apps, data and settings.
The two are linked, though. Since Xcode 16, previews use the same build products as Build and Run, so the output of a preview build sits in DerivedData with everything else, and the preview simulators hold what runs.
How SwiftUI previews work behind the canvas
Knowing what a preview does on disk makes the folder less mysterious. A preview is your code, built by Xcode, running on a device that the canvas shows you.
Which device does a preview run on?
The one chosen in the preview device picker at the bottom of the canvas. Apple's WWDC23 session on previews says most people can stay with Automatic, which follows the device family of the run destination you've selected.
The picker's More submenu lists the simulators you've added, so you can pick an exact model. A simulator is always one model, so previewing on several models gives the Previews set several devices to keep.
Do previews of Mac apps use a simulator?
No. Simulator runtimes exist for iOS, watchOS, tvOS and visionOS, not for macOS, so previews of Mac views run on the Mac itself. They don't add devices to the Previews folder, though their build output still goes to DerivedData like any build.
Apple's release notes for Xcode 27 fixed a related bug. Before, trying to preview without the needed simulator runtime could fall back to macOS without saying so.
Do watchOS and visionOS previews add more?
Yes, in the same way. A preview for watchOS or visionOS runs on a simulator for that platform, so it needs that platform's runtime installed and adds preview devices of its own. The folder grows with each platform you preview, not only with each project.
Removing a platform's runtime in Components settings stops previews for that platform until you install it again. In Xcode 27, the canvas then shows a placeholder.
What happens when you preview on a connected iPhone?
Xcode builds and previews only for that device, bypassing the simulator entirely, as Apple's WWDC23 session puts it. That's useful when a view needs real data, such as a photo library, and it adds nothing to the Previews folder on the Mac.
What the preview saves goes to the iPhone instead. The build output still lands in DerivedData on the Mac.
Does data saved during a preview stay on disk?
Yes, if your code writes it. A preview runs your real code, so a view that saves a database, downloads images or writes files does so inside the preview simulator, and that data stays there between previews.
It's removed with the preview simulators, so there's nothing to rescue. It's also a reason the folder can grow faster for apps that store a lot locally.
How do you keep preview data off the disk?
Give previews sample data in memory rather than real storage. For SwiftData, a model configuration whose isStoredInMemoryOnly property is true keeps its store only in memory, so a preview doesn't leave a database behind.
Xcode 16 added PreviewModifier, which Apple describes as a way to load data once and share it between previews, such as a SwiftData model container. Previews that share one in-memory container don't leave a SwiftData store in the preview simulator.
What about #Playground and Xcode playgrounds?
Xcode 26 added the #Playground macro, for interactive debugging and code exploration in the preview panel, as Apple's release notes put it. It's part of the canvas, like previews, and Apple doesn't document a separate folder for it.
Playground files are different. To run a playground for iOS or another device platform, Xcode builds it as a small app and runs it on a simulator in ~/, which keeps the apps and data from earlier runs.
Do coding agents in Xcode add to it?
They can. Apple's release notes for Xcode 27 say the Preview Snapshot tool that agents use can render variants, such as light and dark appearance, both orientations and several type sizes, and reports the simulator that rendered each preview. Agents can also boot simulators and install apps to check your UI.
Apple doesn't document which device set those simulators come from. If you let agents work in Xcode, check the Previews folder and your own simulators now and then, as you would after a busy month of previewing by hand.
What changed in recent versions of Xcode
Previews have changed a lot in the last few releases. Some changes affect disk space; others only affect memory or speed, which is worth knowing before you go looking for savings that aren't there.
| Xcode | What changed | What it means for space |
|---|---|---|
| Xcode 16 | Previews use the same build products as Build and Run | No separate copy of each build for previews |
| Xcode 16 | PreviewModifier shares data between previews | Easier to keep preview data in memory |
| Xcode 26 | The #Playground macro runs code in the canvas | Not documented as a separate folder |
| Xcode 26 | Compilation caching, an opt-in build setting | A cache that grows if you turn it on |
| Xcode 27 | Preview simulators shut down when no longer used | Less memory in use; their data stays on disk |
| Xcode 27 | Simulator runtimes come with a prebuilt dyld cache | Faster first launch; Apple doesn't say how it affects space |
Xcode 16: no more separate copy
Apple's WWDC24 session on Xcode 16 says the new previews engine reuses your project's build products and puts the program together as it runs, so it no longer makes a separate copy.
So on Xcode 16 and later, switching between a preview and Build and Run doesn't build twice or keep two outputs. Older versions made that separate copy, so projects you still preview in an older Xcode keep more build output.
Xcode 26: compilation caching and previews
Xcode 26 introduced compilation caching, an opt-in feature that keeps the results of compiling a set of source files and reuses them when the same files are compiled again, such as after switching branches. It's turned on with the Enable Compilation Caching build setting.
The release notes say it works with previews too. The cache has its own entry in Xcode › Settings › Locations. On the Mac we checked, it was a folder named CompilationCache.noindex inside DerivedData, and it held 28 KB.
Xcode 27: preview simulators shut down when idle
Apple's release notes for Xcode 27 say simulators booted for previews are now shut down once they're no longer in use, keeping the number running within a budget based on your Mac's resources.
That frees memory, not disk. A shut-down preview simulator keeps its apps and data in the Previews folder, ready for the next preview.
Xcode's other hidden device sets
Previews are the best known, but Xcode makes simulators for two other jobs and keeps a fourth, small set for Interface Builder. All of them are kept apart from the simulators you pick as run destinations.
Parallel testing clones in XCTestDevices
When tests run in parallel on a simulator, Xcode clones the simulator you chose several times and runs part of the tests on each clone. The clones live in ~/, and clones from earlier test runs can stay behind.
Apple's WWDC19 session on testing shows the setting: in a test plan, a test target's options can run all its tests in parallel on multiple clone simulators. Apple's example is a UI test target, which it says runs a lot faster that way.
Does Swift Testing make clones too?
Apple's WWDC24 session on Swift Testing says it runs test functions in parallel by default. It contrasts that with XCTest, which can run tests in parallel only by using several processes, one test each.
Apple doesn't document how each framework uses clones on disk. What's clear is that the Execute in parallel option in the test plan controls whether Xcode spreads a target across several simulators.
How do you stop test clones from piling up?
Turn on parallel testing only for the targets that gain from it. In the test plan editor, click Tests, then click Options next to a test target; Apple's WWDC22 session shows Execute in parallel there.
Clones left from earlier runs take space until they're removed, and they're safe to remove when you're not testing. Apple's notes for Xcode 27 say clones may not appear in Device Hub while they're running tests, so remove them only when no tests are running.
What about tests in Xcode Cloud?
Tests in Xcode Cloud run on Apple's servers, which Apple's WWDC22 session says test your platforms in parallel by default. Those runs don't add clones to your Mac. Only the tests you run locally, in Xcode or on your own build machine, do.
Playground simulators in XCPGDevices
Playgrounds for iOS and other device platforms run on simulators in ~/. They keep the apps and data from earlier playground runs, and Xcode sets them up again when it needs them.
The folder grows with each device platform you run playgrounds for, and with what those playgrounds save. On a Mac that doesn't use playground files, it stays empty.
Interface Builder's small set
Interface Builder keeps a few simulators of its own in ~/, for working with storyboards and XIB files. On the Mac we checked, the folder took 35 MB.
No catalog rule covers it, and there's nothing worth gaining there. Leave it alone.
How do these sets compare?
| Device set | Grows with | Comes back by itself? | What removing it costs |
|---|---|---|---|
| Previews | Projects, device types and their saved data | Yes, on the next preview | A slower first preview; preview data is lost |
| Parallel testing clones | Test runs with parallel testing on | Yes, on the next parallel run | A slower start to the next run |
| Playgrounds | Playgrounds for device platforms | Yes, on the next playground run | A slower next run |
| Interface Builder | Rarely grows | Not covered by a rule | Nothing worth the risk |
Xcode's caches and the shared parts of DerivedData
The rest of Xcode's hidden data is caches: files kept so Xcode doesn't have to fetch or compute them again. Most are small, and one shared folder inside DerivedData can be larger than you'd expect.
What's in Xcode's own caches?
Xcode and its command-line build tool keep cached network data and other temporary files in ~/ and ~/. On the Mac we checked, they took 3.8 MB and 2.6 MB.
The catalog rates Xcode caches as Safe. Afterwards, Xcode may take a little longer to open or to load some information the first time.
What are the shared folders in DerivedData?
Next to the folder for each project, DerivedData keeps a few folders that every project uses. On the Mac we checked in October 2026, they were:
| Folder | Size on that Mac | What it is |
|---|---|---|
ModuleCache.noindex | 1.4 GB | Compiled modules shared by every project |
SDKExplicitPrecompiledModules | 136 MB | Precompiled SDK modules |
SDKStatCaches.noindex | 16 MB | Cached information about the SDKs |
CompilationCache.noindex | 28 KB | The compilation cache, when it's turned on |
Apple doesn't document these folders one by one, so the descriptions follow their names. They're part of DerivedData, which the catalog rates Safe: Xcode rebuilds them, and the next build of each project is a full, slower one.
Should you clear the module cache on its own?
Rarely. It's shared by every project, so removing it makes every project's next build slower, not just one. When a build misbehaves, it's simpler to quit Xcode and remove the whole DerivedData folder, or the folder of the one project that's misbehaving.
For disk space, folders of projects you've stopped working on are a better target. The shared folders come back as soon as you build anything.
CoreSimulator's caches and logs
The simulator service keeps a cache in ~/ and logs in ~/. Both are Safe: the cache is rebuilt, which can slow the next simulator boot, and new logs start with the next simulator.
A separate cache of system libraries for each runtime, in /, is managed together with your installed runtimes, so it's Managed by macOS. On the Mac we checked, it took 3.8 GB for one iOS 26 runtime. Keeping fewer runtimes is how it gets smaller.
How to see what Xcode's hidden data takes on your Mac
Before removing anything, look at the sizes. Most Macs have little in these folders, and a few have a lot; the numbers tell you which you have.
Check the folders in Finder
- In Finder, choose Go › Go to Folder, start typing
~/, then double-click the folder in the list.Library/ Developer - Choose View › as List, then View › Show View Options, and select Calculate all sizes.
- Click the Size column heading, so the largest folders come first.
- Look at XCTestDevices and XCPGDevices here, then open Xcode, then UserData, and check Previews.
To see a single folder's size, select it and choose File › Get Info. Finder may take a moment to add up a large folder.
Why doesn't Storage settings show them?
Storage settings sorts files into categories, such as Applications, Documents and System Data, and Apple's guide doesn't name a category for Xcode's simulators or caches. These folders don't appear there by name.
The File Browser in System Settings › General › Storage, under Documents, shows folders across your file system with their sizes, in both macOS 26 and macOS 27. Finder's list view is the quicker way to reach these particular folders.
Which numbers are worth acting on?
A Previews folder of a few gigabytes is normal on a Mac that previews often, and clearing it buys little that won't come back. A folder in the tens of gigabytes, on a Mac that's short of space, is worth clearing.
The same goes for XCTestDevices. A large one usually comes from many parallel test runs, and clearing it between busy periods is reasonable.
Which folder should you check first?
It depends on the work you do. This table matches common kinds of work to the folder most likely to have grown.
| If you mostly | Check first | Why |
|---|---|---|
| Build SwiftUI apps with many previews | Previews in UserData | Grows with projects and models previewed |
| Run UI tests in parallel | XCTestDevices | Clones stay after the runs |
| Learn or teach with playground files | XCPGDevices | Keeps earlier runs' apps and data |
| Work on many projects | DerivedData's project folders | Old projects stay until removed |
| Test on many OS versions | Runtimes in Components settings | Usually the largest part, managed by Xcode |
Is it safe to delete SwiftUI preview data?
Yes. The catalog rates SwiftUI Previews simulators as Safe: Xcode creates the devices again the next time it shows a preview. Nothing in the folder is your code, and your projects aren't touched.
What changes is the next preview. It takes longer to appear while Xcode sets up a new preview device, and any data your app created while previewing is gone.
What does removing each part cost?
| Part | What removing it costs | How it comes back |
|---|---|---|
| Preview simulators | A slower first preview; data saved in previews | By itself, on the next preview |
| Parallel testing clones | A slower start to the next parallel run | By itself, on the next run |
| Playground simulators | A slower next playground run | By itself |
| Xcode's caches | A slower first launch or load | By itself |
| Shared DerivedData folders | A full build of every project | By itself, on the next build |
| CoreSimulator's caches and logs | A slower first boot; old logs | By itself |
Why not delete the Previews folder in Finder?
Because Xcode may be using it. On Apple's forums, one developer reported that deleting the folder's contents stopped previews from working. Another quit Xcode first, deleted the folder, and previews worked when Xcode opened again.
An Apple engineer on the forums gives the general rule: manage CoreSimulator through Xcode or its simctl tool rather than by hand, and make sure Xcode is quit before deleting anything behind its back. Preview simulators are simulators, so the same care applies.
Is there a way to remove them in Xcode?
Not one Apple documents. Apple's documentation for Device Hub in Xcode 27 covers the simulators you add or choose as run destinations, and says nothing about the sets Xcode keeps for previews, tests and playgrounds.
Xcode's command-line tool has a way to work on a device set by name. On Apple's forums, a developer relayed an Apple engineer's advice to remove the preview set that way, and reported the folder dropped from 110 GB to 6 GB with previews still working. That's what the app runs, as the last section shows.
Does Clean Build Folder clear previews?
Partly. Product › Clean Build Folder removes the build output of the project you have open, and since Xcode 16 previews share that output. It doesn't touch the preview simulators, so it frees little space in the Previews folder.
Use it when a preview or build misbehaves. For space, it's the preview simulators and old projects' DerivedData that matter.
Mistakes to avoid
- Moving the whole UserData folder to the Trash to get rid of Previews. UserData also holds your key bindings and, since Xcode 16, your downloaded provisioning profiles.
- Deleting the Previews folder's contents while Xcode is open and using them.
- Removing XCTestDevices during a test run, including one started by a build machine or an agent.
- Treating the runtimes' dyld cache as a cache to delete. It's managed with your runtimes, and keeping fewer runtimes is how it shrinks.
- Pasting commands from a web page into Terminal. Commands that delete files can't be undone, and fake cleanup guides are a known way to install malware.
A safe order for clearing Xcode's hidden data
- Measure first, in Finder, so you know which folders are worth the trouble.
- Let any running tests finish, then quit Xcode and the Simulator app.
- Remove the preview, test and playground simulators with Xcode's own tool. Apple documents no button for it in Xcode's windows; the app runs that tool for you after its review sheet.
- In Finder, move the DerivedData folders of projects you've stopped working on to the Trash.
- Leave the rest of UserData, the IB Support folder and the runtimes' dyld cache alone.
- Open Xcode, show a preview and run your tests, so the folders you need are made again while you're watching.
- Empty the Trash once everything works.
Keeping previews and test data small
These folders come back by design, so the goal isn't to keep them empty. It's to keep them from growing for months while you're not looking.
Habits that keep the Previews folder small
- Give previews sample data in memory, so they don't leave databases and files in the preview simulators.
- Stay with the Automatic preview device unless you need a specific model, since each model you preview on needs a simulator of its own.
- Preview on a connected iPhone when a view needs real data; nothing is added to the Mac's Previews folder.
- Clear the preview simulators after finishing a large SwiftUI project, rather than all the time.
Habits that keep test clones small
- Turn on Execute in parallel for test targets that gain from it, such as UI tests, rather than for every target.
- Clear XCTestDevices after a period of heavy testing, when no tests are running.
- On a Mac that runs tests unattended, such as a build machine, clear the clones on a schedule.
After an Xcode update or a runtime change
Preview simulators are tied to a runtime, like any simulator. Apple doesn't document whether Xcode removes preview devices whose runtime you've deleted, and the forum thread that asked was never answered.
If you remove old runtimes in Xcode › Settings › Components, it's a good moment to clear the preview set too. The next preview makes devices for the runtimes you still have. The guide to Xcode cleanup covers runtimes and the rest of Xcode's data.
Can you move the Previews folder to another drive?
Not in a way Apple supports. Apple's Developer Technical Support has said the items in Xcode › Settings › Locations, Derived Data, Archives and the Compilation Cache, can live on an external APFS drive. The Previews folder and the other device sets aren't among them.
On Apple's forums, one developer described mounting a disk image from an external drive in the Previews folder's place, with a script to quit and reopen Xcode around it. It's undocumented and depends on the drive being connected whenever Xcode shows a preview, so clearing the folder now and then is the simpler answer.
Will clearing them make Xcode faster?
No. Clearing preview, test and playground simulators frees disk space and nothing else. The first preview, test run or playground run afterwards is slower while Xcode sets up new devices.
Xcode 27's release notes list many fixes for slow or failing previews, such as a clearer error when a preview build times out. None of them involve clearing these folders.
How does this fit with the rest of the Developer folder?
These sets are a small part of ~/. The post on the Library Developer folder goes through every folder in it, including the archives and settings that should never be removed as part of a cleanup.
How the app does it
Wombit explains these folders like everything else on the disk. Select one in the map or the list, 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 preview, test and playground simulators, Xcode's caches, DerivedData, and CoreSimulator's caches and logs are Safe, so they count toward the safe total and start checked. The runtimes' dyld cache is Managed by macOS and only explained.
~/
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
~/
Library/ Developer/ XCTestDevices Copies of simulators that Xcode makes so tests can run on several simulators at the same time.
Safe · Runs xcrun simctl --set testing delete all
~/
Library/ Developer/ XCPGDevices Simulator devices that Xcode uses to run playgrounds for iOS and other device platforms.
Safe · Runs xcrun simctl --set playgrounds delete all
~/
Library/ Caches/ com.apple.dt.Xcode Cached network data and other temporary files that Xcode and its command-line build tool keep so they don't have to fetch them again.
Safe · Moves it to the Trash
Folders go to the Trash, where you can put them back. For the preview, test and playground simulators, the app runs Xcode's own tool instead, after the review sheet, which offers to quit Xcode if it's open. What a command removes can't be put back, and the sheet says so.
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
Seeing all of this is free. Removing it 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
Where does Xcode store SwiftUI previews?
Xcode runs previews on simulators kept in ~/Library/Developer/Xcode/UserData/Previews/Simulator Devices, apart from the simulators you run apps on. Each holds builds of the apps you've previewed and the data they saved. Since Xcode 16, the build output itself is shared with Build and Run in DerivedData.
Can I delete the Xcode Previews folder?
Yes. Its contents are safe to remove: Xcode creates new preview simulators for the next preview, which takes longer to appear, and data saved in previews is lost. Quit Xcode first. On Apple's forums, one developer reported previews breaking after deleting the contents by hand, while another who quit Xcode first had no trouble.
Why is my SwiftUI Previews folder so large?
Each preview simulator keeps builds of every app previewed on it and whatever those apps saved, and nothing in Xcode trims it. Previewing many projects, on several platforms and models, over months or years, adds up. Apps that save databases or download media during previews make it grow faster.
How do I clear the SwiftUI preview cache?
There are two parts. Product › Clean Build Folder removes the build output of the open project, which previews share since Xcode 16. The preview simulators themselves have no button in Xcode; they're removed with Xcode's own command-line tool, which is what the app runs after its review sheet.
What is the XCTestDevices folder on a Mac?
It holds the simulator clones Xcode makes when tests run in parallel, so each clone can run part of the tests. Clones from earlier runs can stay behind. They're safe to remove when no tests are running, and Xcode makes new ones on the next parallel run.
What is the XCPGDevices folder?
It holds the simulators Xcode uses to run playgrounds for iOS and other device platforms. Each keeps the apps and data from earlier playground runs. It's safe to clear, and Xcode sets the simulator up again the next time you run a playground.
Do SwiftUI previews use a lot of memory?
Each preview simulator uses memory while it runs. Apple's release notes for Xcode 27 say simulators booted for previews are now shut down once they're no longer in use, keeping the number running within a budget based on your Mac's resources. Their data stays on disk.
Will deleting preview simulators delete my code?
No. Your projects and source code live in your own folders, not in the simulators. Removing the preview simulators deletes only the copies of apps installed for previews and the data they saved while previewing.
Sources
- Xcode 27 Release Notes · Apple
- Xcode 26 Release Notes · Apple
- What's new in Xcode 16 (WWDC24) · Apple
- Build programmatic UI with Xcode Previews (WWDC23) · Apple
- SwiftUI Previews - Disk space issue · Apple Developer Forums
- Xcode Using 90GB with ~/Library/Developer — What Can I Safely Clean? · Apple Developer Forums