The Flutter pub cache on a Mac is a hidden folder in your home folder, ~/. Pub, the package manager Dart and Flutter share, downloads every package version your projects use into it once, so all your projects can reuse the same copy. It never trims itself, so it grows with every new package version you fetch.
It's rarely the only thing Flutter keeps. The Flutter SDK folder holds its own cache of downloaded engine files, and tools such as FVM keep a whole SDK for each version you install.
Every project adds a build folder and a hidden .dart_tool folder, and builds for iPhone and Android leave CocoaPods, Xcode and Gradle files elsewhere on the Mac.
Most of it comes back by itself. Packages download again, and build output is rebuilt, at the cost of a slower next build. The exceptions are the tools you activated globally through pub, which live inside the pub cache, and release builds in a project's build folder, which you may need to keep.
The sections below go through each folder: where it is, what fills it, what removing it costs and how to do it in Finder or with the tool's own commands. None of this makes Flutter faster. Clearing caches frees space, and the next build is slower while they fill again.
Where Flutter and Dart keep files on a Mac
A working Flutter setup spreads over four kinds of place: shared caches in your home folder, the SDK wherever you put it, folders inside each project, and the native tools' folders for iPhone and Android.
Which folders does a Flutter setup create?
| Location | What it holds | Comes back by itself? |
|---|---|---|
~/.pub-cache | Downloaded packages, git dependencies, globally activated tools | Packages yes, tools no |
| Your Flutter SDK folder | Flutter's source, plus the Dart SDK and engine files in bin/cache | Downloaded files yes |
~/fvm | Extra Flutter SDKs installed with FVM, and its git cache | Only if you install them again |
build in each project | Output of every build, release builds included | Yes, on the next build |
.dart_tool in each project | Package configuration and build caches | Yes, on the next run |
~/.flutter, ~/.dart-tool and friends | Settings for the Flutter and Dart tools | Recreated with defaults |
The last row covers six small folders Flutter's uninstall page names: ~/, ~/ and ~/ for Flutter, and ~/, ~/ and ~/ for Dart. They hold configuration rather than downloads.
Where does the space show up in Storage settings?
In System Settings › General › Storage, hidden folders in your home folder such as ~/ usually fall under System Data, which Apple describes as files that don't fit the other categories and whose contents you can't manage there. Build folders inside your projects count wherever the projects are.
That's why a Mac used for Flutter work can show a large System Data number with nothing obvious to explain it. The route to Storage is the same in macOS 27 Golden Gate and macOS 26 Tahoe.
How do you open hidden folders like .pub-cache?
Folders whose names start with a period are hidden in Finder. Two ways to reach them:
- In Finder, choose Go › Go to Folder, type
~/and press Return..pub-cache - Or open your home folder and press Command-Shift-Period to show hidden items. Press it again to hide them.
To see a folder's size, select it and choose File › Get Info. A large folder can take a moment to add up.
The Flutter pub cache on a Mac: what's inside
Dart's glossary calls it the system cache: a single folder where pub stores the remote packages it downloads. On macOS it defaults to ~/. A given package version is downloaded once and reused by every project that asks for it, Flutter apps and plain Dart packages alike.
What are the folders inside it?
Folder in ~/.pub-cache | What it holds |
|---|---|
hosted | Packages from pub.dev or another package server, one folder per package version |
git | A checkout for each commit of each git dependency |
git/cache | A full mirror of each git repository you depend on |
global_packages | Records of tools you activated globally |
bin | Small launchers for those global tools |
When a project gets its dependencies, pub writes a package configuration file into the project's .dart_tool folder. It points each package name at its copy in the cache, which is why projects can share packages instead of keeping their own.
Why do git dependencies take so much room?
A pubspec can name a package by its git address instead of a version on pub.dev. Pub's source code describes how it stores them: a mirror of the whole repository under ~/, plus a separate checkout for every commit any of your projects has used.
So a git dependency on a large repository keeps that repository's full history once, and another full copy of its files for each commit you've pinned over time. Projects that track a branch and update often leave a trail of checkouts behind.
Why does the pub cache keep growing?
Because nothing removes old versions. Each time you upgrade a project's dependencies, the new versions are added and the old ones stay, in case another project still uses them. Dart's documentation doesn't describe any automatic cleanup.
A Mac that has seen several Flutter projects, and a few years of upgrades, can hold many versions of the same packages.
Is it safe to delete the pub cache?
Mostly. The catalog rates the pub cache Usually safe. Packages download again the next time each project gets its dependencies, or the next time you run it, so nothing in your projects is lost.
The catch is the global tools. Anything you activated globally through pub, such as a code generator or a project helper, lives inside the cache and stops working until you activate it again. If you installed FVM through pub, that includes FVM itself.
How do you clear it?
Dart has its own cache command for this. It's a command-line tool, so there's no app or menu for it. Its clean option empties the whole system cache, which Dart's documentation says is for reclaiming disk space or removing problem packages. Flutter's pub command passes the same options through.
The Finder route works too: quit your editor and any running builds, then move ~/ to the Trash. Finder's Move to Trash can be undone with File › Put Back until you empty the Trash. Before you do, make a note of the global tools you use, so you can activate them again.
What does the repair option do?
Dart's cache command also has a repair option, which reinstalls every package in the cache from scratch. Dart's documentation suggests it when cached packages have been changed or broken, for example when someone accidentally edited a cached file in their editor. It fixes problems; it doesn't free space.
Can you move the pub cache to another drive?
Dart reads an environment variable, PUB_CACHE, that points pub at a different folder. There's no setting for it in Flutter, Android Studio or VS Code; it's set in your shell's configuration. If you move it, keep the drive connected whenever you build, or pub downloads everything again into the new place.
The Flutter SDK folder and its downloaded engine
Flutter isn't installed like an app. You download the SDK and put it in a folder of your choice, and everything Flutter needs to run lives inside that folder.
Where is the Flutter SDK on a Mac?
Wherever you put it. Flutter's install guide suggests a folder named develop in your home folder, which gives ~/. Older guides and many tutorials used other folders, so check yours.
If you installed with Homebrew, its Flutter cask keeps the SDK at / on an Apple silicon Mac, with links to the flutter and dart commands. Flutter's setup check reports the SDK's location in its verbose output, and VS Code's and Android Studio's Flutter settings show the path they use.
What's in the bin/cache folder?
The SDK downloads its heavy parts the first time you run it. Flutter's scripts put the Dart SDK in the SDK's bin/ folder, and the flutter tool keeps the engine's binary artifacts, the compiled pieces each platform needs, in bin/.
By default it fetches artifacts only for the platforms you build for. The first time you build for Android, iPhone, the web or the Mac, it downloads that platform's files and keeps them. Flutter's command-line reference describes its precache command as one that fills this cache of binary artifacts ahead of time.
Does the SDK grow over time?
Yes, in two ways. Every new platform you build for adds its artifacts, and every upgrade brings a new engine version to download. Flutter's upgrade guide also assumes the SDK is a git checkout, so the folder includes the repository's history, which grows with each update you pull.
Is it safe to delete bin/cache?
Nothing of yours lives there, but you rarely need to touch it. Flutter checks the cache when it runs and downloads whatever is missing or out of date, so moving bin/ to the Trash means a long download the next time you run Flutter, with nothing gained in the meantime.
It's worth it only for an SDK you're keeping but not using for a while, or as a last-resort fix for a corrupted download. To remove Flutter for good, remove the whole SDK folder instead.
Is there a Flutter app to manage all this?
No. Flutter is a command-line toolkit with editor plugins. Its own commands upgrade the SDK, switch channels and fill the cache, and none of them has a window. Removing an SDK is a Finder job: move its folder to the Trash.
More than one Flutter version: FVM and channels
Projects that pin different Flutter versions push people towards keeping several SDKs. Each one is a complete SDK with its own bin/cache, so each extra version costs as much space as the first.
How does FVM store Flutter versions?
FVM, the Flutter Version Management tool, is an open-source project, not part of Flutter itself. Its source code keeps everything in a folder named fvm in your home folder: each SDK in ~/, a shared git cache of the Flutter repository in ~/, and a link for the global version at ~/.
Each project that uses FVM gets a hidden .fvm folder at its root. FVM's configuration page describes its flutter_sdk item as a link to the cached version, not a copy, so it takes no space of its own.
How do you remove Flutter versions you no longer use?
With FVM's own commands. FVM is command-line only; it has no app or menu. Its list command shows the versions it has installed, its remove command deletes one or all of them, and its cleanup command shows versions no project pins and offers to remove them.
You can move a folder inside ~/ to the Trash in Finder, but FVM's commands keep its records straight, and its cleanup knows which versions your projects still use. FVM also has a command that removes its entire cache, every version included.
What about channels and old SDK downloads?
Switching between Flutter's stable, beta and main channels changes the SDK in place; it doesn't add a second copy. What does add copies is downloading the SDK again into a new folder, for example to try a beta, and forgetting the old one.
If Flutter commands, your editor and FVM all point at one SDK, any other flutter folder on the Mac is probably a leftover. Check which one your editor's Flutter settings name before you move another to the Trash.
Which versions should you keep?
| SDK copy | Keep it if | Otherwise |
|---|---|---|
| The SDK on your PATH | You build Flutter apps at all | Remove it with the rest of Flutter |
| FVM versions a project pins | You still work on that project | FVM's remove or cleanup command |
| FVM versions nothing pins | Never needed | FVM's cleanup command lists them |
| A second SDK folder you downloaded | Your editor uses it | Move it to the Trash |
| Homebrew's Flutter | You installed Flutter that way | Remove it with Homebrew |
Inside each project: build, .dart_tool and the generated folders
Every Flutter project carries its own generated files next to your code. They're small for a fresh project and large for one you've built for several platforms, in debug and release.
What's in a Flutter project's build folder?
The catalog's entry for Flutter build folders explains that Flutter writes the output of every build into a build folder at the project's root, for each platform you build for. It rates the folder Usually safe, because some of that output you may want to keep.
Android builds land in build/, where Flutter's release guide says the app bundle and APK files go. An iPhone release build puts an Xcode archive in build/ and the App Store bundle in build/.
Why does the iOS archive matter?
The catalog's entry notes that the Xcode archive of a release holds the debug symbols you need to read crash reports from that release. If you upload builds from Xcode or another tool, the archive may already be safe elsewhere. If the build folder is the only place it exists, copy it out before you remove the folder.
What is the .dart_tool folder?
Dart's documentation describes it as a folder of files used by various Dart tools, and lists it among the things not to commit. The .dart_tool folders entry adds that it holds the project's package configuration and build caches, and rates it Safe.
It's created again when the project's dependencies are fetched, which Flutter does by itself when you run or build the app. Code generators that use Dart's build system keep their caches here too, which is often why it grows.
What does flutter clean remove?
Flutter's command-line reference describes its clean command as deleting a project's build and .dart_tool folders. Its source code shows it also removes the generated, temporary folders Flutter keeps inside the ios, android, macos, linux and windows folders, a few generated Xcode settings files and the plugin dependency list.
With an extra option, it also asks Xcode to clean the iOS workspace. It doesn't touch your code, the Pods folder, the pub cache, Gradle's caches or the SDK.
Is it safe to delete these folders in Finder?
Yes, with the project closed in your editor. Moving build and .dart_tool to the Trash does nearly what Flutter's clean command does, and the next run rebuilds them. The generated folders inside each platform folder are small, so there's little reason to hunt for them by hand.
| Project item | What it is | Safe to remove? |
|---|---|---|
build | Output for every platform, release builds included | Yes, after saving releases |
.dart_tool | Package configuration, build caches | Yes |
ios/Pods, macos/Pods | CocoaPods' copies of native plugin code | Yes, if nobody edited them |
android/.gradle | Gradle's caches for this project | Yes |
pubspec.lock | The exact package versions resolved | No; it's part of the project |
.fvm | A link to the project's Flutter version | Leave it; it's tiny |
iOS Pods and Android Gradle output from Flutter builds
Flutter hands the last steps of a build to each platform's own tools. Those tools keep their own caches, outside the project, and a Flutter developer often has both sets.
The ios/Pods and macos/Pods folders
Flutter plugins with native code for Apple platforms have long been installed with CocoaPods, which copies them into a Pods folder in the project's ios or macos folder. The catalog rates Pods folders Usually safe: CocoaPods can recreate them, but the app doesn't build until it does, and edits made inside Pods are lost.
Since Flutter 3.44, Flutter's documentation says Swift Package Manager support is on by default, and Flutter falls back to CocoaPods only for plugins that don't support it yet. It also notes that the CocoaPods registry becomes read-only on 2 December 2026. Projects that have moved fully off CocoaPods can delete their Podfile and Pods folder, as that page describes.
CocoaPods' and Swift Package Manager's shared caches
CocoaPods also keeps a download cache in your Library, shared by every project, and Swift Package Manager keeps its own. They grow with each plugin version you install. The post on the CocoaPods and Swift Package Manager caches covers where they are and how to clear them.
Xcode's DerivedData and simulators
Every iPhone build runs through Xcode, which keeps intermediate files in DerivedData, one folder per project. Flutter projects are no exception, and a release build adds another. The post on Xcode's DerivedData folder explains why it's safe to remove and how big it gets.
Flutter's iOS setup also asks you to download iOS platform support and simulator runtimes, which are among the largest things a developer's Mac holds. Remove old ones through Xcode's own settings, not Finder.
Gradle's folder and the project's .gradle
Android builds run through Gradle. Gradle keeps downloaded dependencies and Gradle versions in ~/, shared by every Android and Flutter project, and the catalog rates Gradle's caches Safe. Each Flutter project's android folder also gets a hidden .gradle folder of project caches.
Gradle cleans its shared caches by itself, removing what goes unused for a week or a month. The post on Gradle's caches and what's safe to clear explains those rules.
The Android SDK, emulators and Java
Flutter's Android setup asks for Android Studio, an SDK platform, build tools, command-line tools, the emulator, platform tools, CMake and the NDK, all installed through Android Studio's SDK Manager. Emulator images and virtual devices come on top. They're where most of a Flutter developer's Android space goes.
The post on the SDK, emulators and caches Android Studio keeps goes through each one. If you've stopped Android work altogether, removing Android Studio with its SDK takes it all out.
Java versions you installed for Gradle go separately, as the post on uninstalling Java and old JDKs explains.
What's safe to remove: a decision table
Everything Flutter and its tools keep falls into three groups: what comes back by itself, what you can download again, and what holds your work or your setup.
| Item | Comes back? | What removing it costs |
|---|---|---|
.dart_tool folders | Yes, on the next run | A dependency fetch, a slower first build |
Project build folders | Yes, on the next build | A full build; release outputs you didn't copy |
~/.pub-cache | Packages yes, tools no | Downloads; activating global tools again |
The SDK's bin/cache | Yes, on the next run | A large download |
| FVM versions | Only if installed again | The download, for projects that pin them |
| Pods folders | When pods are installed again | A slower first build; edits inside Pods |
| Gradle's caches | Yes, on the next build | Downloads; a slower build |
What should you never delete?
- Your upload keystore and key.properties. Flutter's Android release guide creates the keystore in your home folder by default, as
~/, and keeps its passwords inupload-keystore.jks android/. Back both up somewhere safe: the keystore can't be recreated, and its passwords can't be recovered if you forget them.key.properties - pubspec.yaml and pubspec.lock. Dart recommends committing the lock file for apps, because it records the exact versions you tested.
- Release builds you haven't copied elsewhere, for their debug symbols and their store uploads.
- Edits inside Pods or the pub cache. Changes there aren't kept anywhere else. Move them into your own code first.
Mistakes to avoid
- Moving the whole SDK folder to clear its cache. Only bin/cache downloads again; the rest of the SDK has to be installed again from scratch.
- Clearing the pub cache in the middle of a build. Running builds can fail. Close your editor and stop running apps first.
- Removing an FVM version a project pins. The project can't build until FVM installs that version again.
- Pasting removal commands from a web page. Commands that delete files bypass the Trash, so there's no Put Back.
Does clearing all this make Flutter faster?
No. It frees space, and that's all. The next dependency fetch downloads packages again, the next build compiles from scratch, and Xcode and Gradle rebuild their caches. Clearing build output can fix strange build errors, which is why Flutter offers a clean command, but it's a repair, not a speed-up.
A worked example: tidying up after a few years of Flutter
Say you've built Flutter apps for three years: two active projects, a few old ones, FVM for the projects that pin older versions, and builds for iPhone and Android. Here's an order that frees the most for the least risk.
Start with the projects you've finished
For each old project, copy anything you shipped out of its build folder: the iOS archive and the Android app bundle. Then move build and .dart_tool to the Trash. If you won't open the project again soon, its ios/Pods and android/.gradle can go too.
Don't remove the projects themselves unless they're safely in source control. Their code and their keystore settings are the parts nobody can rebuild.
Then the Flutter versions nothing uses
FVM's cleanup command lists the versions no known project pins and offers to remove them. Each one is a whole SDK with its own engine files, so this is often the largest single gain on a Mac that has used FVM for a while.
Then the shared caches
If your pub cache is large and full of old versions, note your global tools, then move it to the Trash in Finder; Dart's own cache command does the same from the command line. Your active projects download what they need the next time you run them, and the old versions don't come back.
Gradle cleans itself, and CocoaPods' and Swift Package Manager's caches can wait unless they're large.
Last, the platform tools
Open Xcode's settings and remove simulator runtimes for iOS versions you no longer test. Open Android Studio's SDK Manager and Device Manager and remove old system images and devices. These take longer to download again than anything else here, so remove only what you're sure about.
What if you also build games?
Game engines are a different world, with their own launchers, editors and caches that dwarf Flutter's. The post on Unity and Unreal Engine caches covers which of their folders rebuild and which hold your work.
Removing Flutter from a Mac completely
If you've stopped Flutter work, Flutter's own uninstall page describes the steps. They're all about folders, so Finder does the job.
Remove the SDK
- Find the folder you installed Flutter into, for example
~/.develop/ flutter - Quit your editor and stop any running Flutter apps or emulators.
- Move the whole flutter folder to the Trash.
If you used FVM, its versions go with FVM's own commands, and FVM itself with whatever installed it: Homebrew, pub or its install script. All of these are command-line steps, with no app or menu. If you installed Flutter with Homebrew, remove it with Homebrew, which is command-line only; its cask also lists ~/ as a leftover.
Remove the configuration folders
Flutter calls this optional. In your home folder, with hidden items showing, move these to the Trash if you don't want to keep your tool settings:
~/,.flutter ~/and.flutter-devtools ~/, Flutter's tool settings.flutter_settings ~/,.dart ~/and.dart-tool ~/, Dart's tool settings.dartServer ~/, the package cache, unless you still use Dart on its own.pub-cache
Flutter's documentation notes that a later reinstall recreates these with default settings.
Remove Flutter from your PATH
Flutter's install guide has you add the SDK's bin folder to your PATH, usually with a line in a shell configuration file such as .zshrc in your home folder. Open that file in TextEdit, delete the line that mentions Flutter's bin folder, and save. FVM and pub's global tools may have added similar lines.
Keep what belongs to your projects
Uninstalling Flutter doesn't touch your projects, and it shouldn't touch your upload keystore. Keep the projects you might return to, and keep the keystore and its passwords backed up even if you don't, because an app you published can only be updated with the key it was signed with.
Keeping Flutter's footprint in check
A few habits keep a Flutter Mac from filling up again.
Clean finished projects, not active ones
The build and .dart_tool folders of the project you work on every day save you time. Clean projects when you finish with them, after copying their release builds out.
Let FVM tell you what's unused
FVM marks versions that no known project pins and that aren't your global version, and its cleanup command offers to remove them. After you upgrade a project, that's the moment the old version becomes unused.
Leave caches out of Time Machine
The pub cache, the SDK's bin/cache and build folders can all be downloaded or rebuilt, so backing them up mostly fills your backup disk. In System Settings › General › Time Machine, click Options and add them to the excluded items.
The post on excluding developer folders from Time Machine lists others worth leaving out.
Look at the whole developer picture
Flutter's own folders are often smaller than what Xcode, simulators and Android keep for it. For everything developer tools leave around, see the guide to freeing up disk space on a developer's Mac.
How the app does it
Wombit explains Flutter's and Dart's folders like everything else on the disk. Select one in the map or the list, and you see what it is, how safe it is to remove and what removing it costs, from the catalog's entry. It reads only names, sizes and dates, and file names and paths never leave your Mac.
Cleanup lists them by level:
- .dart_tool folders and Gradle's build folders and caches are Safe. They count toward the safe total, start checked and go to the Trash, where you can put them back.
- Flutter build folders and Pods folders are Usually safe, so they wait for you to check them. A build folder can hold a release's Xcode archive.
- The pub cache is Usually safe too, because it holds your global tools. When you check it, the app runs Dart's own command after the review sheet, instead of deleting files. What a command removes can't be put back, and the sheet says so.
What the app runs, after you review itPRO
- dart pub cache clean --force
- pub's system cache: downloaded packages and globally activated tools
~/
.pub-cache Dart and Flutter packages that pub has downloaded for your projects, plus command-line tools you activated globally.
Usually safe · Runs dart pub cache clean --force
~/
**/ .dart_tool Files that Dart and Flutter tools generate in each project, such as its package configuration and build caches.
Safe · Moves it to the Trash
~/
**/ build Build output that Flutter creates in each app project, for every platform you build for, including release builds.
Usually safe · Moves it to the Trash
~/
**/ Pods The pods a project installed with CocoaPods, kept in a Pods folder next to its Podfile.
Usually safe · Moves it to the Trash
~/
.gradle/ caches Dependencies, build cache entries and other files that Gradle keeps for all the Java, Kotlin and Android projects you build.
Safe · Moves it to the Trash
Seeing all of this is free. Cleanup is PRO, one payment of $4.99 with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.
Frequently asked questions
Where is the Flutter pub cache on a Mac?
In a hidden folder in your home folder, ~/.pub-cache. Dart's documentation gives that as the default on macOS and Linux, and both Dart and Flutter projects share it. It moves only if the PUB_CACHE environment variable points somewhere else.
Is it safe to delete the .pub-cache folder?
Mostly. Packages download again the next time each project gets its dependencies, so nothing in your projects is lost. Tools you activated globally through pub live there too, and they stop working until you activate them again. Dart's own cache command does the same job from the command line.
What does flutter clean delete?
It removes the project's build and .dart_tool folders, plus the generated, temporary folders Flutter keeps inside the ios, android, macos, linux and windows folders, and a few generated settings files. It doesn't touch your code, the pub cache, the Pods folder, Gradle's caches or the Flutter SDK.
Why is my Flutter SDK folder so big?
Besides Flutter's own source, the SDK keeps a cache of binary artifacts in its bin/cache folder: the Dart SDK and the engine files for each platform you build for. The SDK is also a git checkout with its history. Each extra copy of the SDK, from FVM or a second download, has all of this again.
Can I delete a Flutter project's build folder?
Yes, in Finder, as long as you keep anything you shipped. Flutter recreates the folder on the next build, which takes longer. Release outputs live there too, including the Xcode archive of an iOS release and Android app bundles, so copy those elsewhere first.
Where does FVM store Flutter versions on a Mac?
By default in a folder named fvm in your home folder, with each version in its versions folder and a shared git cache beside it. Each project gets a hidden .fvm folder that links to the version it uses. FVM is a command-line tool, and its own commands list and remove versions.
Does clearing Flutter caches make builds faster?
No. Clearing caches frees space, but the next build or dependency fetch is slower while everything downloads and compiles again. Clearing build output is a troubleshooting step for odd build errors, not a way to speed anything up.
How do I uninstall Flutter completely from a Mac?
Flutter's documentation says to delete the folder you installed the SDK into. Optionally remove its configuration folders, .flutter, .flutter-devtools and .flutter_settings, Dart's .dart, .dart-tool and .dartServer, and the pub cache, all hidden in your home folder. Then take the SDK's bin folder out of your shell's PATH setting.
Sources
- Change Storage settings on Mac · Apple
- dart pub cache · Dart
- Glossary · Dart
- flutter: The Flutter command-line tool · Flutter
- Uninstall Flutter · Flutter
- Swift Package Manager for app developers · Flutter