How to Safely Empty the ~/Library/Developer Folder on macOS (2026)

If you have ever opened About This Mac and winced at the storage bar creeping toward full, the Library/Developer folder on Mac (~/Library/Developer) is one of the first places worth investigating. For developers—or anyone who has ever installed Xcode—this hidden folder quietly accumulates gigabytes of build artifacts, device support bundles, simulator runtimes, and cached indexes. On a 512 GB MacBook Pro, it is not unusual to find 40–80 GB sitting in here untouched for months. The good news is that most of what lives inside is regenerable, and a careful cleanup carries very little risk to your actual projects or app data.

What Is the ~/Library/Developer Folder?

The ~/Library/Developer folder is a user-level directory that Apple's developer tools—primarily Xcode, but also Instruments, Reality Composer, and Simulator—use to store data that does not belong inside your project directories. It is separate from the system-level /Library/Developer folder (which requires administrator rights to modify), and separate from Xcode's actual application bundle at /Applications/Xcode.app. Think of it as Xcode's working scratch space: essential while a build is running, but often stale and bloated after months of development.

To open it directly in Finder, press Shift + Cmd + G in any Finder window and type ~/Library/Developer. You can also reach it from the Terminal:

open ~/Library/Developer

What Is Actually Inside—and How Much Space Does Each Part Use?

The folder is divided into several subdirectories, each serving a distinct purpose. The table below maps out the main subfolders, where they live, and a realistic size range you might see on an active Mac development machine.

How to Clean Up DerivedData (The Biggest Win)

DerivedData is the single largest and safest target in the entire folder. Xcode stores compiled object files, index data, build logs, and module caches here. You lose nothing permanent by deleting it—Xcode will recreate the folder on the next build, which will be slightly slower the first time as it reindexes.

Option 1: Delete from inside Xcode

1. Open Xcode and go to Settings → Locations.
2. Click the small arrow next to the DerivedData path to reveal it in Finder.
3. Close Xcode, then delete the entire DerivedData folder contents.

Option 2: Delete from Terminal

This is the fastest approach and works whether Xcode is installed or not:

rm -rf ~/Library/Developer/Xcode/DerivedData

Xcode will recreate the directory automatically the next time it needs it. You do not need to create it yourself.

Removing Old Device Support Bundles

Every time you connect an iPhone or iPad running a new OS version, Xcode downloads a matching Device Support bundle so it can attach the debugger. These bundles are version-specific and accumulate over time. If you no longer need to debug on iOS 16 or iOS 17 devices, those folders are dead weight.

To check what you have:

ls -lh ~/Library/Developer/Xcode/iOS\ DeviceSupport/

Delete any version folder that corresponds to an OS you no longer support:

rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/16.7*

Apply the same logic to ~/Library/Developer/Xcode/watchOS DeviceSupport and tvOS DeviceSupport if they exist.

Cleaning Up Simulator Runtimes and Devices

Simulator runtimes are the full OS images that power the iOS, watchOS, and tvOS simulators in Xcode. A single runtime can be 4–7 GB. In macOS Sequoia and the upcoming macOS Tahoe release, Apple moved simulator runtime storage to ~/Library/Developer/CoreSimulator/Volumes (previously they lived inside the Xcode app bundle itself on older installs).

The safest way to manage these is through xcrun simctl rather than deleting files manually:

# List all available runtimes
xcrun simctl list runtimes

# Delete unused simulators (devices with no paired runtime)
xcrun simctl delete unavailable

To remove a specific simulator runtime through Xcode's UI: open Xcode → Settings → Platforms, find the runtime you want to remove, hover over it, and click the minus button. Xcode will cleanly uninstall the runtime and free the space.

For a broader look at what is consuming space across your entire system—not just the Developer folder—see our guide on what is taking up space on a Mac to put these numbers in context.

Archives: The One Area to Treat Carefully

The ~/Library/Developer/Xcode/Archives folder stores the .xcarchive bundles you created when you built for distribution or App Store submission. Each archive contains a release build and—critically—the dSYM debug symbol files that let you symbolicate crash reports from production users.

If you use a crash reporting service (Crashlytics, Sentry, or Apple's own Xcode Organizer), you need the dSYM files from the exact build version a user is running in order to decode a crash. Deleting an archive erases those symbols permanently. The rule of thumb:

• Keep archives for any app version still live in the App Store or deployed to internal testers.
• Delete archives for versions that have been superseded by major updates and are no longer in active use.
• If space is critical, you can export and archive the dSYMs separately before removing the full .xcarchive bundle.

Other Developer Caches Worth Cleaning Outside the ~/Library/Developer Folder

The Developer folder is the most prominent target, but macOS developer setups scatter additional caches in other locations. Here are the most common ones that accumulate significant space:

• ~/Library/Caches/com.apple.dt.Xcode — Xcode's general cache; safe to delete.
• ~/.gradle/caches — Gradle build caches for Android or Kotlin Multiplatform projects.
• ~/.m2/repository — Maven local repository; can grow to several gigabytes on Java/Kotlin projects.
• ~/.cargo/registry — Rust crate registry cache; safe to prune with cargo cache -a if you have the cargo-cache crate installed.
• ~/.nuget/packages — .NET NuGet package cache for .NET MAUI or cross-platform C# development.
• ~/Library/Caches/CocoaPods — CocoaPods download cache; regenerable with pod cache clean --all.

Node.js projects deserve their own attention. The node_modules directories scattered across your project folders can collectively consume tens of gigabytes. For a focused walkthrough on that specific problem, see our post on cleaning up node_modules on Mac.

If tracking all of these locations manually sounds tedious, a tool like Crumb can audit all of them at once and show what is safe to remove before you delete anything—which is particularly useful if you work across multiple language ecosystems.

How to Check Your Savings Before and After

Before you start, record a baseline so you can confirm the cleanup worked:

# Size of the entire Developer folder
du -sh ~/Library/Developer

# Drill into the top subfolders
du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport
du -sh ~/Library/Developer/CoreSimulator/Volumes

Run the same commands after cleanup to verify the reclaimed space. Changes may take a minute to reflect in About This Mac because macOS updates the storage estimate asynchronously. On Apple Silicon Macs (M1 through M4 generations) the du output is instant and reliable; on older Intel machines you may need to wait for Spotlight to re-index before the Finder info panel updates.