How to clear the Gradle cache on Mac (and keep builds fast)

Part of: Mac disk cleanup for developers: every cache, what it costs to rebuild (Developers)

You can clear identified Gradle cache data by quitting anything that uses Gradle and selecting caches, unused wrapper/dists entries or daemon logs inside ~/.gradle. Keep gradle.properties, init.gradle(.kts), init.d and any other user configuration. Cleared caches make the next build slower and may require downloads.

Gradle is the build tool behind most Android projects and many Java and Kotlin ones. It keeps a lot in one hidden folder in your home directory.

See what is there first

Run this in Terminal to see the size of each part:

du -sh ~/.gradle/*

On the Mac used to check this article, the biggest parts were caches, jdks and wrapper, and the daemon logs were smaller. Yours will differ with the number of projects and Gradle versions you use. If you want to look around, open ~/.gradle shows the folder in Finder.

What each part is

• caches: downloaded libraries and the results of earlier builds. It is usually the largest part.
• wrapper/dists: a full copy of each Gradle version your projects ask for. The wrapper is a small script in a project that downloads the right Gradle version for it.
• daemon: logs from the background Gradle process, called the daemon, that keeps builds quick between runs.
• jdks: Java runtimes that Gradle downloaded for your builds.

Safe, risky, never

• Safe: daemon logs, and wrapper/dists entries for Gradle versions you no longer use. Cost: a project that needs an old version downloads it again.
• Risky: caches. Cost: every dependency of every project downloads again. That can be many gigabytes and a long first build. If you work offline or on a metered connection, wait until you are online.
• Never: gradle.properties, init.gradle(.kts), init.d or any other user configuration. These can contain your settings and build scripts, not disposable cache data. Keep them.

See Gradle-managed directories and caches for the documented layout and automatic cache maintenance.

How to clear it

1. Quit Android Studio, IntelliJ and any terminal running a build, so no Gradle process holds the files. A Gradle daemon can keep running after the IDE closes, so check Activity Monitor for java processes if you are unsure.
2. Select only identified cache data from the list above. Start with unused wrapper/dists entries and daemon logs. Preserve all settings and init scripts; do not remove the entire ~/.gradle folder.
3. Move those folders to the Trash in Finder, then empty the Trash. The space comes back only when you empty it, as the Trash article explains.
4. Open a project and build it. Gradle recreates what it needs.

Removing a single project’s .gradle folder, the one that sits next to its build files, is a smaller and safer step. It holds build state for that project only.

Keep builds fast after clearing

A cold cache makes the first build slow. You can soften it:

• Clear the parts one at a time instead of everything, and rebuild your main project first.
• Leave caches alone for the projects you work on every day, and remove only ones you have finished with. A single large cache shared by active projects is the point of the cache.
• Do not clear it right before a deadline or a train ride.

Does it overlap with Android Studio and Maven?

A little. Android Studio keeps its own emulator images and SDK files outside .gradle, so clearing Gradle does not touch them. See Android Studio taking up too much space for those. Maven, another Java build tool, has its own cache in ~/.m2. See where the .m2 folder is. The two do not share files, so clearing one does not shrink the other.

The full list of developer folders and what each costs to rebuild is in the developer cleanup guide.

Worked example: which Gradle versions do you keep?

The wrapper/dists folder has one subfolder per Gradle version. List them with a read-only command:

ls ~/.gradle/wrapper/dists

It lists one folder per Gradle version your projects have used. Each version is a full copy of Gradle. If your projects use only the newest, the others are what you can remove first. To learn which version a project wants, open its gradle/wrapper/gradle-wrapper.properties file. The version is in the distributionUrl line.

Check all your active projects before you remove one. A project you forgot will download the version again, which is a small cost.

The home folder is one place, projects are another

~/.gradle is shared by every project. Each project can also have a .gradle folder of its own, next to its build files, and a build folder with output. Removing a build folder is the usual way to get a fresh build. It is separate from the shared cache, and cheaper to rebuild.

On the same Mac, the ~/.gradle folder also had jdks, native and workers. If you see folders not in the list above, leave them. They come from Gradle or its plugins.

If something goes wrong

• A build says it cannot find a dependency. You may be offline, or the library is no longer at its source. Reconnect and try again.
• A project downloads a Gradle version again. You removed it from wrapper/dists. That is expected.
• The build says a Java version is missing. Gradle downloaded it into jdks and you removed it. The next build can fetch it again if your project allows that.
• Builds are slow for days. You may have cleared caches for projects you use often. Rebuild the main ones first.

When not to clean

Do not clear caches if you will be on a plane or a slow network soon. Do not touch gradle.properties in any cleanup. It holds your settings.

Check the size with DiskJoy

DiskJoy is our product. Its scan reads your disk and shows how large ~/.gradle and other developer folders are, without changing anything. Cleanup is not built yet, so DiskJoy does not delete these folders for you today.

Quick checklist

1. Run du -sh ~/.gradle/* and see which part is large.
2. Quit your IDE and builds.
3. Remove daemon logs and old wrapper/dists first.
4. Remove caches only if you can afford a full re-download.
5. Empty the Trash and run a build.