How to Clear the Swift Package Manager Cache on Mac the Right Way (2026)

If your Mac's available storage has been quietly shrinking and you do Swift development, the Swift Package Manager cache is one of the first places worth checking. SPM is deeply integrated into Xcode and the Swift open-source toolchain, and on an active machine it can accumulate several gigabytes of resolved packages, build artifacts, and cloned source repositories — often without any obvious indicator in Finder. This guide covers where those files live, how to safely clear them, and how to keep things tidy going forward on both Apple Silicon and Intel Macs running macOS Sequoia or Tahoe.

Where Swift Package Manager Stores Its Cache

SPM uses several distinct directories, and the exact paths depend on whether you're working through Xcode or the standalone swift command-line tool. Understanding the difference matters before you start deleting anything.

• Source cache (checkouts): ~/.swiftpm/cache — cloned package repositories reused across builds.
• Package repositories (global): ~/.swiftpm/repositories — bare Git clones SPM maintains as a local registry mirror.
• Build products (per-project): <project-root>/.build/ — compiled object files, Swift module interfaces, and the final binary. This folder stays inside each project directory.
• Xcode-integrated SPM manifests: ~/Library/Developer/Xcode/DerivedData/ — when SPM dependencies are resolved through Xcode, derived data for those packages lands here alongside your own project's build output.
• System-level caches: ~/Library/Caches/org.swift.swiftpm/ — used by some toolchain versions for additional resolution metadata.

A single package used across ten projects is typically only fetched once into the global cache and then reused — which is efficient, but it also means the global directories balloon over time as package versions multiply.

How Much Space Are We Talking?

Cache sizes vary widely based on how many packages you pull in and how long your machine has been active. The table below gives realistic ballparks based on a moderately active Swift developer workflow in 2026.

For context on why Xcode's DerivedData figures so prominently here, see our deeper look at why Xcode takes up so much space.

How to Clear the Swift Package Manager Cache Step by Step

The cleanest approach uses the swift package subcommand when possible, falling back to direct deletion for items the CLI doesn't cover. Work through these steps in order.

Step 1 — Use the built-in purge command

SPM ships with a dedicated purge command that clears the global cache directory without touching anything you haven't explicitly cached:

1. Open Terminal (Applications > Utilities > Terminal).
2. Run: swift package purge-cache
3. This removes the contents of ~/.swiftpm/cache. The command works from any directory — you don't need to be inside a Swift project.

Step 2 — Reset a specific project's resolved state

Inside a project that uses SPM (either standalone or Xcode-managed), you can reset the full dependency resolution:

1. Navigate to the project root in Terminal: cd /path/to/YourProject
2. Run: swift package reset
3. This deletes the local .build/ directory and the resolved checkouts for that project, forcing a clean resolve on the next build.

Step 3 — Clear the global repositories cache manually

The repositories directory isn't purged by purge-cache and can grow large over time. You can safely remove it:

1. Quit Xcode if it is open.
2. Run: rm -rf ~/.swiftpm/repositories
3. SPM will re-clone repositories the next time you build a project that requires them.

Step 4 — Clear DerivedData for Xcode-integrated packages

If your SPM packages are resolved through an Xcode project, much of the build output lives in DerivedData:

1. In Xcode, open Settings > Locations and click the arrow next to the DerivedData path to open it in Finder, then delete its contents.
2. Or from Terminal: rm -rf ~/Library/Developer/Xcode/DerivedData
3. Xcode will recreate the folder on the next build.

Is It Safe to Delete the SPM Cache?

Yes — all of the directories above are reconstructed automatically. Deleting them does not remove your source code, your Package.swift manifest, or your Package.resolved lock file. The lock file is key: SPM reads it to know exactly which version of each dependency to fetch, so you'll get the same versions back, not random newer ones.

The trade-off is build time. After a full cache clear, the next build needs to re-clone and recompile everything from scratch. On a project with many dependencies this can take several minutes. If you're on a slow connection, clearing ~/.swiftpm/repositories in particular means SPM has to re-download all bare repository data. Plan accordingly.

Checking Sizes Before You Delete

It's worth knowing what you're reclaiming. These commands report disk usage for each cache location:

• du -sh ~/.swiftpm/cache
• du -sh ~/.swiftpm/repositories
• du -sh ~/Library/Developer/Xcode/DerivedData
• du -sh ~/Library/Caches/org.swift.swiftpm

Run them together in one pass: du -sh ~/.swiftpm/cache ~/.swiftpm/repositories ~/Library/Developer/Xcode/DerivedData ~/Library/Caches/org.swift.swiftpm

A tool like Crumb can audit all of these locations at once, surface what's taking up the most space, and let you confirm what to delete before anything is removed — which is useful when you have many language toolchain caches accumulating side by side (Cargo, npm, CocoaPods, and so on). For a broader look at reclaiming disk space beyond SPM, see how to free up space on Mac.

Preventing Cache Bloat Going Forward

Periodic maintenance is more effective than one big purge. A few habits that keep SPM cache growth manageable:

• Archive old projects: Projects you haven't opened in months still have a .build/ directory sitting on disk. Zip the project before archiving or run swift package clean inside it first to remove the build folder.
• Use swift package clean routinely: Unlike reset, clean removes only the compiled build artifacts in .build/ while keeping the checked-out source so the next build is faster than a full reset.
• Audit DerivedData periodically: Xcode accumulates a DerivedData entry for every project it has ever opened, including ones long deleted from your drive. Clearing stale entries from ~/Library/Developer/Xcode/DerivedData every few months is low-risk and often recovers double-digit gigabytes.
• Keep your toolchain current: Older toolchains leave their own cache footprint in /Library/Developer/Toolchains/. Remove toolchain versions you no longer need via xcode-select or the Downloads section in Xcode Preferences.

Apple Silicon vs Intel: Any Differences?

The cache paths are identical on both architectures. The only notable difference is that .build/ on Apple Silicon Macs may contain separate subdirectories for arm64-apple-macosx and x86_64-apple-macosx slices if you've ever built for Rosetta compatibility or run the simulator on an Intel target. These simulator-arch artifacts add up quickly and are safe to clear with swift package clean or direct deletion of the architecture-specific subfolder.

Related Toolchain Caches Worth Knowing About

If you work across multiple languages, each toolchain maintains its own cache hierarchy. SPM is just one contributor. Others that commonly appear on developer Macs include:

• CocoaPods: ~/Library/Caches/CocoaPods/
• Carthage: ~/Library/Caches/org.carthage.CarthageKit/ and per-project Carthage/Build/
• Homebrew: ~/Library/Caches/Homebrew/ (cleared with brew cleanup)
• npm / Node: ~/.npm/ and per-project node_modules/

Addressing all of these at once is where a systematic disk audit pays off more than clearing caches one tool at a time.