What Is Xcode DerivedData and Can You Safely Delete It?

What Is DerivedData?

DerivedData is Xcode's central build cache directory. Every time you press Command-B (Build) or Command-R (Run) in Xcode, the compiler takes your Swift and Objective-C source files, compiles them into object files, links those object files into an executable, processes your asset catalogs, compiles storyboards and XIBs, and copies all the results into a folder inside DerivedData. This is the "derived" data — files derived from your source code by the build process.

But DerivedData stores much more than just build outputs. It is also the home of:

• Build products — the compiled .app bundle, frameworks, and their intermediate object files (.o files)
• SourceKit index — the database that powers Xcode's code completion, syntax highlighting, jump-to-definition, Find in Project, and refactoring features
• Build logs — detailed records of every compilation step, linker invocation, and code signing operation
• Module cache — pre-compiled Swift and Clang modules that speed up subsequent builds
• Index data store — the on-disk representation of the project's symbol index, stored in a DataStore subfolder
• TextIndex — full-text search index for Find in Project functionality
• SwiftUI Previews artifacts — when you use live previews, Xcode builds a separate preview target whose output also lands here

Where Does DerivedData Live?

By default, DerivedData is stored at:

~/Library/Developer/Xcode/DerivedData/

Since the Library folder is hidden in Finder by default, most developers never see it. To navigate to it in Finder:

1. Open Finder
2. Press Command-Shift-G (Go to Folder)
3. Paste ~/Library/Developer/Xcode/DerivedData/
4. Press Enter

Or from Terminal:

# Open DerivedData in Finder
open ~/Library/Developer/Xcode/DerivedData/

# List contents with sizes
du -sh ~/Library/Developer/Xcode/DerivedData/* | sort -hr

You can also change the DerivedData location in Xcode. Go to Xcode > Settings > Locations and you will see the DerivedData path with a small arrow to reveal it in Finder. You can set it to a custom location or to "Relative" (which places DerivedData inside the project folder), though the default location is what most developers use.

How DerivedData Folder Names Map to Projects

Inside the DerivedData directory, you will see folders with names like:

MyApp-abcdef1234567890ghijklmn/
AnotherProject-zyxwvu9876543210/
ModuleCache.noindex/

Each folder name starts with your project name (or workspace name), followed by a hyphen and a hash. This hash is derived from the full path to your .xcodeproj or .xcworkspace file. That means if you move a project to a different directory, Xcode creates a new DerivedData folder for it, and the old one becomes orphaned — still consuming disk space but never used again.

The info.plist Trick

If you are looking at a DerivedData folder and wondering which project it belongs to, check its info.plist:

# Read the workspace path from the info.plist
plutil -p ~/Library/Developer/Xcode/DerivedData/MyApp-abcdef1234567890/info.plist

This outputs a dictionary like:

{
  "LastAccessedDate" => "2026-03-15T10:42:33Z"
  "WorkspacePath" => "/Users/you/Projects/MyApp/MyApp.xcworkspace"
}

The WorkspacePath key tells you exactly which project generated this folder. The LastAccessedDate tells you when it was last used. This is extremely useful for identifying and cleaning up folders for projects you no longer work on.

Finding Orphaned DerivedData Folders

You can script this to find DerivedData folders whose source projects no longer exist:

# List all DerivedData folders with their workspace paths
for dir in ~/Library/Developer/Xcode/DerivedData/*/; do
  if [ -f "$dir/info.plist" ]; then
    workspace=$(plutil -extract WorkspacePath raw "$dir/info.plist" 2>/dev/null)
    size=$(du -sh "$dir" | cut -f1)
    if [ ! -e "$workspace" ]; then
      echo "ORPHANED [$size]: $workspace"
      echo "  -> $dir"
    fi
  fi
done

This script checks whether the original workspace path still exists on disk. If it does not, the DerivedData folder is orphaned and is safe to delete.

Why DerivedData Grows So Large

Several factors contribute to DerivedData's growth:

1. Multiple Projects

Every project you open in Xcode gets its own DerivedData folder. If you work on five projects, you have five separate sets of build artifacts, indexes, and caches. Switch projects frequently and they all accumulate.

2. Multiple Build Configurations

Building for Debug and Release creates separate products. Building for simulator (x86_64/arm64) and device (arm64) creates more. Testing adds yet another. Each configuration is cached independently.

3. Swift Package Manager Dependencies

When you add SPM packages, their source code is checked out into SourcePackages/ inside the DerivedData folder, and their compiled modules are cached as well. Large dependency trees (Firebase, AWS, Realm) can add gigabytes.

4. Project Moves and Renames

As mentioned above, moving a project directory or renaming a workspace creates a new DerivedData folder. The old folder stays behind, orphaned and unused. Over months, you accumulate dead folders.

5. SourceKit Index Growth

The index database grows as your project grows. For large projects with hundreds of Swift files, the index alone can be several hundred megabytes.

6. Xcode Never Cleans Up

This is the fundamental issue. Xcode has no built-in garbage collection for DerivedData. Old folders from deleted projects, previous workspaces, or old build configurations persist indefinitely. There is no automatic pruning, no TTL, no "clean up folders older than 30 days" feature.

Can You Safely Delete DerivedData?

Here is what happens after you delete DerivedData:

1. Code completion stops working temporarily. The SourceKit index needs to be rebuilt. Xcode starts re-indexing as soon as you open a project. For a large project, this can take 1-5 minutes. During indexing, you will see a progress bar in Xcode's status area.
2. Your next build is a full build. Without the cached object files, Xcode must compile every file from scratch. Depending on your project size, this could take 30 seconds (small projects) to 10+ minutes (large projects with many dependencies).
3. SPM packages are re-resolved. If your project uses Swift Package Manager, Xcode re-clones and re-builds all packages. This requires an internet connection and takes proportional time to the number of packages.
4. Everything else works normally. Your project settings, schemes, breakpoints, and all source files are untouched. DerivedData contains nothing irreplaceable.

How to Delete DerivedData

Method 1: Terminal (Fastest)

# Delete all DerivedData for all projects
rm -rf ~/Library/Developer/Xcode/DerivedData/*

# Check it worked
du -sh ~/Library/Developer/Xcode/DerivedData/
# Should show 0B or a few KB

Method 2: Delete a Specific Project's DerivedData

# Find your project's DerivedData folder
ls ~/Library/Developer/Xcode/DerivedData/ | grep -i "myapp"

# Delete just that project
rm -rf ~/Library/Developer/Xcode/DerivedData/MyApp-abcdef1234567890/

Method 3: From Within Xcode

Xcode does not have a one-click "Delete All DerivedData" button, but you can clean individual project data:

1. Go to Xcode > Settings > Locations
2. Click the small gray arrow next to the DerivedData path
3. This opens the folder in Finder
4. Select all folders and move them to Trash

Alternatively, Product > Clean Build Folder (Shift-Command-K) cleans the build products for the current project, but does not delete the index or other cached data. It is less thorough than deleting the folder directly.

Method 4: Delete Only Old/Orphaned Folders

# Delete DerivedData folders not accessed in 30+ days
find ~/Library/Developer/Xcode/DerivedData/ -maxdepth 1 -type d \
  -not -name "DerivedData" -not -name "ModuleCache.noindex" \
  -mtime +30 -exec rm -rf {} +

This is a more conservative approach that only removes folders you have not used recently. Active projects are left intact.

Automated Cleanup Options

Launchd Script (DIY Automation)

You can create a macOS launchd agent that periodically cleans DerivedData. Create a plist file at ~/Library/LaunchAgents/com.user.clean-deriveddata.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.user.clean-deriveddata</string>
  <key>ProgramArguments</key>
  <array>
    <string>/bin/bash</string>
    <string>-c</string>
    <string>find ~/Library/Developer/Xcode/DerivedData/ -maxdepth 1 -type d -not -name "DerivedData" -not -name "ModuleCache.noindex" -mtime +14 -exec rm -rf {} +</string>
  </array>
  <key>StartCalendarInterval</key>
  <dict>
    <key>Weekday</key>
    <integer>1</integer>
    <key>Hour</key>
    <integer>3</integer>
  </dict>
</dict>
</plist>

Load it with:

launchctl load ~/Library/LaunchAgents/com.user.clean-deriveddata.plist

This runs every Monday at 3 AM and removes DerivedData folders older than 14 days. It works, but it is fragile, hard to customize, and provides no visibility into what was deleted or how much space was saved.

The Better Approach: Use DiskPort

Instead of maintaining shell scripts and launchd plists, you can use DiskPort to manage DerivedData cleanup visually. DiskPort shows you exactly how large each project's DerivedData is, identifies orphaned folders, and lets you clean selectively or set up automatic schedules with configurable rules — all from a native macOS interface.

Frequently Asked Questions

Does deleting DerivedData fix Xcode bugs?

Often, yes. Many common Xcode issues — code completion failures, phantom build errors, stale interface previews, "module not found" errors that should not occur — are caused by a corrupted index or stale build cache. Deleting DerivedData is the first troubleshooting step recommended by Apple and the community for most Xcode misbehavior.

Will I lose my breakpoints or project settings?

No. Breakpoints are stored in your project's .xcuserdata or .xcshareddata directory, which is inside your project folder (not in DerivedData). Schemes, build settings, and signing configurations are stored in the .xcodeproj or .xcworkspace bundle. DerivedData contains only build outputs and caches.

How often should I clean DerivedData?

There is no universally correct answer, but a reasonable schedule for most developers is:

• Every 2-4 weeks — a full clean of all DerivedData (good for 256GB drives)
• Monthly — clean orphaned and old folders only (good for 512GB+ drives)
• On demand — when you notice disk space getting tight or Xcode acting up

Can I move DerivedData to an external drive instead?

Yes. You can either change the path in Xcode Settings > Locations, or create a symbolic link. See our guide on moving Xcode data to an external SSD for step-by-step instructions. Keep in mind that build performance will depend on the external drive's speed — a Thunderbolt NVMe SSD is recommended.