SwiftUI Previews Cache: The Hidden 80GB Storage Killer

SwiftUI Previews are one of Xcode's best features. They're also one of the biggest silent consumers of disk space. Here's how to find, clean, and manage the Previews cache before it devours your SSD.

SwiftUI Previews changed how iOS developers build interfaces. Instead of compiling, launching the simulator, navigating to the right screen, and squinting at the result, you get a live rendering right inside Xcode's canvas. It's fast, it's iterative, and it's — if we're being honest — addictive.

But there's a cost nobody talks about. Every time you use SwiftUI Previews, Xcode compiles a special version of your project, builds it for a lightweight simulator-like environment, and caches the result. Over weeks and months, these cached builds accumulate silently in a directory most developers never check. The result: 20, 40, even 80+ gigabytes of disk space consumed by Preview builds you'll never use again.

This guide covers everything you need to know about the SwiftUI Previews cache: where it lives, why it grows, how to clean it safely, and how to keep it under control going forward.

Where the Previews Cache Lives

The SwiftUI Previews cache is stored at:

~/Library/Developer/Xcode/UserData/Previews/

Inside this directory, you'll find a subdirectory called Simulator Devices, which contains what are essentially lightweight simulator instances used exclusively for rendering Previews. Each one has its own filesystem, frameworks, and cached build products.

To check how much space it's using right now:

du -sh ~/Library/Developer/Xcode/UserData/Previews/

If you've been using SwiftUI Previews regularly for six months or more, you'll likely see a number that surprises you. It's common to find 20-40GB here. Developers working on large SwiftUI-heavy projects with multiple build configurations can see 60-80GB or more.

For a more detailed breakdown:

du -sh ~/Library/Developer/Xcode/UserData/Previews/Simulator\ Devices/*/

Each subdirectory corresponds to a Preview simulator device. You may find dozens of them, each consuming several hundred megabytes to a few gigabytes.

Why the Previews Cache Grows So Large

Understanding why this cache grows helps you manage it more effectively. Several factors contribute:

A Full Compilation Pipeline

SwiftUI Previews don't just render your view code. They compile your entire target (or at least the modules your view depends on), link it, and run it in a sandboxed preview simulator. That means every preview session generates compiled binaries, linked frameworks, and intermediate build products — essentially a stripped-down version of DerivedData, but stored in a separate location.

Per-Device, Per-Configuration Caching

Xcode creates separate Preview simulator devices for different contexts. If you preview on "iPhone 16 Pro" and then switch to "iPad Air," that's two separate cached environments. If you change your build configuration from Debug to Release, that may create another. Over time, these permutations multiply.

No Automatic Cleanup

This is the core of the problem. Xcode does not automatically clean old Preview caches. When you close a project, the Preview cache stays. When you update Xcode, old caches from the previous version stay. When you refactor your code so that old cached builds are completely invalid, the old caches stay. They accumulate indefinitely until you manually intervene.

Multiple Projects Compound the Problem

If you work on three different apps and use Previews in each, you get three independent sets of Preview caches. A freelance developer working on client projects can easily have 10+ projects contributing to the Previews cache over the course of a year.

Xcode Version Upgrades

When you upgrade Xcode (say, from 16 to 17), the Preview infrastructure changes. Old caches from the previous Xcode version become orphaned — they'll never be used again, but they aren't cleaned up either. This means a major Xcode update can leave behind 10-20GB of dead Preview data.

How to Clean the Previews Cache

Method 1: The Official Command (Recommended)

Apple provides a command specifically for cleaning Preview simulator devices:

xcrun simctl --set previews delete all

This is the safest and most thorough approach. It:

  • Removes all Preview simulator devices and their data
  • Cleans up the associated caches and build products
  • Doesn't affect your regular (non-Preview) simulators
  • Doesn't affect DerivedData or any other Xcode data

Important: Close Xcode before running this command. If Xcode is running and actively using Previews, some files may be locked, resulting in incomplete cleanup.

After running the command, verify the cleanup:

du -sh ~/Library/Developer/Xcode/UserData/Previews/

The directory should now be a few megabytes at most, down from potentially tens of gigabytes.

Method 2: Manual Deletion (If the Command Fails)

In some cases, xcrun simctl --set previews delete all may fail or not fully clean up — particularly if there are corrupted Preview simulator states. In that case, you can delete the directory manually:

# Make sure Xcode is closed first
killall Xcode 2>/dev/null

# Remove the entire Previews directory
rm -rf ~/Library/Developer/Xcode/UserData/Previews/

Xcode will recreate this directory (and a fresh Preview simulator) the next time you use SwiftUI Previews. Nothing is permanently lost — it's all regeneratable cache data.

Method 3: Selective Cleanup

If you want to keep recent Preview caches (for projects you're actively working on) and only remove old ones, you can target devices by modification date:

# Find Preview device directories not modified in the last 14 days
find ~/Library/Developer/Xcode/UserData/Previews/Simulator\ Devices/ \
  -maxdepth 1 -type d -mtime +14

# Remove only those old directories
find ~/Library/Developer/Xcode/UserData/Previews/Simulator\ Devices/ \
  -maxdepth 1 -type d -mtime +14 -exec rm -rf {} +

This approach preserves your current project's Preview cache, avoiding the brief delay of recompilation the next time you open Previews.

What Happens After Cleanup

After deleting the Previews cache, here's what to expect:

  • First preview will be slower: Xcode needs to create a new Preview simulator device and compile your project for it. This typically takes 10-30 seconds for the first preview, depending on your project size.
  • Subsequent previews are normal speed: Once the initial compilation is done, incremental preview updates are fast as usual.
  • No data loss: Preview caches are purely derived data. Your source code, project settings, and everything else are untouched.
  • No impact on regular simulators: Your iOS Simulator devices (the ones you see in Xcode's device dropdown) are stored separately in ~/Library/Developer/CoreSimulator/ and are not affected.

Monitoring Previews Cache Growth Over Time

Since the cache regrows every time you use Previews, monitoring is essential. Here are practical approaches:

Monthly Check Script

Add this to your shell profile (e.g., ~/.zshrc) as an alias:

alias xcode-preview-size='echo "Previews cache: $(du -sh ~/Library/Developer/Xcode/UserData/Previews/ 2>/dev/null | cut -f1)"'

Then just run xcode-preview-size whenever you want a quick check.

Automated Cleanup Script

You can create a script that runs on a schedule (via launchd or a cron job) to clean Preview caches older than a certain age:

#!/bin/bash
# clean-old-previews.sh
# Remove Preview simulator devices not modified in 30+ days

PREVIEW_DIR="$HOME/Library/Developer/Xcode/UserData/Previews/Simulator Devices"

if [ -d "$PREVIEW_DIR" ]; then
  echo "Checking for old Preview caches..."
  OLD_SIZE=$(du -sh "$PREVIEW_DIR" | cut -f1)

  find "$PREVIEW_DIR" -maxdepth 1 -type d -mtime +30 -exec rm -rf {} + 2>/dev/null

  NEW_SIZE=$(du -sh "$PREVIEW_DIR" 2>/dev/null | cut -f1)
  echo "Before: $OLD_SIZE, After: ${NEW_SIZE:-0B}"
fi

Track Growth Week Over Week

For a quick growth check, record the size weekly and compare:

# Append current size and date to a log file
echo "$(date '+%Y-%m-%d') $(du -sh ~/Library/Developer/Xcode/UserData/Previews/ | cut -f1)" \
  >> ~/xcode-previews-growth.log

# View the growth log
cat ~/xcode-previews-growth.log

This gives you a simple time series showing how fast the cache is growing and helps you decide on a cleanup frequency.

Factors That Accelerate Cache Growth

Not all projects generate Previews cache at the same rate. Understanding the factors helps you predict and manage growth:

  • Large projects with many modules: Each module needs to be compiled for Previews. More modules = larger cache per preview session.
  • Frequent preview device switching: Switching between iPhone and iPad previews, or between different iPhone models, creates multiple cached environments.
  • Heavy use of #Preview macros: Projects with preview macros in every file generate more cached builds.
  • Multi-platform targets: If you preview for both iOS and macOS (or watchOS, visionOS), each platform creates separate caches.
  • Build configuration changes: Switching between Debug/Release or custom build configurations can create new cache entries.

SwiftUI Previews vs. DerivedData: Understanding the Difference

A common confusion is why Previews have their own cache when DerivedData already stores build artifacts. Here's the distinction:

  • DerivedData (~/Library/Developer/Xcode/DerivedData/): Stores build products for your main target — the app you run on simulators or devices. One folder per project workspace.
  • Previews cache (~/Library/Developer/Xcode/UserData/Previews/): Stores build products specifically for the Preview canvas. Previews use a different compilation mode (with special injected code for live updates), so the builds are different from your main build and can't share DerivedData.

This means that working with SwiftUI Previews can double your effective cache size — you have DerivedData for your main builds and a separate Previews cache for canvas rendering. Both grow independently, and both need to be managed.

Best Practices for Managing Previews Cache

  1. Clean monthly: Run xcrun simctl --set previews delete all once a month. The 10-30 second recompilation cost on your next Preview session is negligible compared to recovering 20-40GB.
  2. Clean after Xcode updates: Immediately after updating to a new Xcode version, clean old Preview caches. They're incompatible with the new version anyway.
  3. Clean after finishing a project: When you wrap up a client project or archive an app version, clean the Previews cache. You won't need those cached builds again.
  4. Monitor, don't guess: Check the cache size periodically rather than assuming it's fine. A developer who checks once a quarter might find 60GB of dead cache data waiting to be cleaned.
  5. Use a storage management tool: Tools like DiskPort can monitor Previews cache size automatically and alert you when it crosses a threshold, or clean it on a schedule.

A Note on Xcode Versions and Previews Architecture

Apple has been improving the Previews system with each Xcode release. In Xcode 15, Apple introduced a new Preview macro system (#Preview) that replaced the older PreviewProvider protocol. The underlying compilation and caching architecture has also evolved. In Xcode 16 and 17, Preview builds are faster and somewhat more space-efficient than in earlier versions.

However, even with these improvements, the fundamental problem remains: Preview builds are cached indefinitely and never automatically cleaned up. Until Apple adds automatic cache management to Xcode (and don't hold your breath), this is something developers need to handle themselves.