If you have Flutter installed on your Mac, dart pub cache clean is one of the fastest ways to claw back several gigabytes from a folder most developers never think about. The Dart package manager keeps every version of every package you have ever fetched in ~/.pub-cache, and on an active machine that directory can quietly grow to 5 GB, 10 GB, or more. This guide explains exactly what is inside that cache, which parts are safe to delete, and how to handle it both manually and automatically — whether you are running an Apple Silicon M-series Mac or an older Intel machine on macOS Sequoia or the upcoming Tahoe release.
What Lives Inside ~/.pub-cache
Dart's package cache sits at ~/.pub-cache in your home directory. It is not inside ~/Library/Caches, so macOS's built-in storage manager does not touch it, and it never shows up under System Settings → General → Storage unless you look at developer data explicitly. The directory has two main subdirectories:
~/.pub-cache/hosted/pub.dev/— downloaded tarballs and extracted source for every package from pub.dev, versioned by name and semver.~/.pub-cache/git/— clones of any packages you have pulled directly from Git repositories via thegit:dependency syntax.
Each package version is stored individually, so if your projects have collectively used flutter_bloc 8.1.3, flutter_bloc 8.1.4, and flutter_bloc 8.1.6, all three copies sit on disk simultaneously. Over months of active development, this accumulates fast.
How Much Space Are We Talking?
The exact size depends on how many packages your projects consume and how many versions you have cycled through. The table below shows representative sizes from a typical Flutter developer's machine in 2026:
| Cache Subfolder | Typical Size | What It Contains | Safe to Delete? |
|---|---|---|---|
~/.pub-cache/hosted/pub.dev/ |
3 – 12 GB | All pub.dev package source trees | Yes — re-downloaded on next pub get |
~/.pub-cache/git/ |
200 MB – 2 GB | Git-sourced dependency clones | Yes — re-cloned on next pub get |
~/.pub-cache/global_packages/ |
50 – 500 MB | Globally activated tools (e.g. dart_style, flutterfire_cli) |
Partial — deleting removes the activation; re-run dart pub global activate |
How to Check the Current Size Before You Delete Anything
Open Terminal and run:
- Check total pub-cache size:
du -sh ~/.pub-cache - Break it down by subfolder:
du -sh ~/.pub-cache/*/ - List the ten largest individual packages:
du -sh ~/.pub-cache/hosted/pub.dev/* | sort -rh | head -10
On a machine with two or three years of Flutter development, it is common to see ~/.pub-cache/hosted/pub.dev/ alone sitting at 6 GB or above.
How to Run dart pub cache clean (Step-by-Step)
Dart ships a built-in command that clears the entire hosted and git cache in one shot. Here is how to use it safely:
- Confirm your Flutter/Dart installation path. On Apple Silicon the Flutter SDK typically lives at
/opt/homebrew/Caskroom/flutter/or wherever you placed it; on Intel Macs it is often under/usr/local/or your home directory. Verify the Dart version:dart --version - Run the clean command:
dart pub cache clean
Dart will ask you to confirm before deleting anything. Typeyand press Return. - Optional — force without prompt:
dart pub cache clean --force
Use this in CI pipelines or scripts where interactive confirmation is not possible. - Verify the result:
du -sh ~/.pub-cache
You should see the size drop to a few kilobytes or nothing at all. - Restore packages for active projects. Navigate to each Flutter or Dart project and run:
flutter pub get
ordart pub get
This re-downloads only the packages each project actually needs at the pinned versions in itspubspec.lock.
After this cycle, your ~/.pub-cache will contain only the packages fetched for the projects you just restored, so it tends to be 60–80% smaller than before the clean.
Removing Old Flutter SDK Versions
The pub cache is not the only place Flutter takes up space. If you manage Flutter via the Flutter SDK directly (not Homebrew), you may have multiple SDK versions sitting in side-by-side directories. Each SDK clone contains its own pre-compiled tools, Dart runtime, and binaries. Check with:
ls -lh ~/flutter/
If you use fvm (Flutter Version Manager), cached SDK versions live in ~/.fvm/versions/. List them with fvm list and remove unneeded ones with fvm remove <version>. Each SDK version is 1–2 GB, so this is often the biggest Flutter-related win on the disk.
Xcode, iOS Simulators, and the Flutter Build Cache
Flutter on macOS also touches Xcode's infrastructure. Two locations deserve attention:
~/Library/Developer/Xcode/DerivedData/— Xcode stores build artifacts for every Flutter iOS or macOS target here. A single project can produce 3–8 GB. Safe to delete: Xcode rebuilds on next build. See our guide on why Xcode takes up so much space for a full breakdown.~/Library/Developer/CoreSimulator/Devices/— iOS Simulator disk images, each 5–15 GB. You can remove unused simulators from Xcode → Window → Devices and Simulators, or withxcrun simctl delete unavailable.
Flutter's own build cache for Android lives under each project's build/ directory (not in a shared location), so deleting the project's build/ folder is safe and reclaims space without affecting other projects.
Comparing Flutter Cache to Other Language Toolchain Caches on macOS
Flutter is far from the only toolchain that caches aggressively. If you are doing a full disk audit, these are the other major offenders to check alongside ~/.pub-cache. For Node.js projects, cleaning up node_modules on Mac follows a similar pattern of per-project reinstallation.
~/.gradle/caches/— Gradle (Android build system used by Flutter). Often 3–10 GB.~/.m2/repository/— Maven local repository. Common on machines that also run Java or Kotlin projects.~/.cargo/registry/— Rust crate registry. Similar design to pub-cache: one copy per version.~/Library/Caches/CocoaPods/— CocoaPods download cache for iOS/macOS dependencies.
A tool like Crumb can audit all of these caches at once and show you how much each one holds before you decide what to remove, which is especially useful when you want a comprehensive picture rather than hunting each path manually.
Automating Pub Cache Maintenance
Running dart pub cache clean manually every few months is effective, but you can also take a lighter-touch approach: repair rather than wipe. The repair command re-downloads any packages whose files are corrupted without touching healthy ones:
dart pub cache repair
For CI environments, it is common to add dart pub cache clean --force as a step before archiving build artifacts, ensuring the cache does not balloon across pipeline runs. On local machines, the cleanest workflow is to run the full clean once a quarter and then let flutter pub get rebuild only what each project requires.