Most developer data on a Mac is a cache. A cache is a copy the tool made to save time, so the tool can recreate it. The real question for each folder is not “is it safe?” but “what does it cost me to get it back?” This article is the map. Each folder links to a longer guide.
Quit the tool that uses a folder before you remove anything from it. Then check the size first, so you spend your time on the folders that matter.
Check the sizes first
You can ask Terminal how large a folder is. du -sh prints a size in a readable unit. For example:
du -sh ~/Library/Developer/Xcode/DerivedData ~/.gradle ~/.m2 ~/.npm ~/.cargo
A folder that does not exist on your Mac prints an error. That is fine. It means you never used that tool.
The map
| Folder | What it is | Cost to get it back |
|---|---|---|
~/Library/Developer/Xcode/DerivedData |
Xcode build output and indexes | A full rebuild of each project |
~/Library/Developer/CoreSimulator and /Library/Developer/CoreSimulator |
Simulated devices and the simulated iOS versions they run | Re-download of a runtime; apps and test data inside a device are lost |
~/.gradle |
Gradle downloads, wrapper copies and daemon logs | Re-download of dependencies on the next build |
~/.m2 |
The Maven local repository | Re-download of dependencies |
~/.android and ~/Library/Android/sdk |
Android emulator devices and SDK parts | Emulator data is lost; SDK parts are re-downloaded |
~/.npm, the pnpm store, the Yarn cache |
Downloaded JavaScript packages | Re-download on the next install |
~/.cargo, target folders |
Rust crate downloads and build output | Re-download and a full rebuild |
~/Library/Caches/Homebrew |
Downloaded Homebrew installers | Re-download if you reinstall |
~/Library/Caches/pip |
Downloaded Python packages | Re-download |
~/go/pkg/mod |
Downloaded Go modules | Re-download |
node_modules in each project |
Installed JavaScript dependencies | npm install again |
The paths are the usual defaults. Tools let you move them, so ask the tool where its cache is if a folder looks empty. Several of those commands appear in the guides below.
Safe, risky, never
- Safe: DerivedData, package download caches (npm, pip, Go, Homebrew),
node_modulesandtargetfolders of projects you are not working on, Gradle daemon logs and old wrapper copies. You lose rebuild or download time. - Risky: the Gradle and Maven dependency caches if you work offline, simulator devices that hold test data, Android emulator devices you configured, simulator runtimes you still need.
- Never: Xcode Archives you may need to read old crash reports, anything in a project you have not committed, signing keys and credentials that sit in dot folders such as
~/.ssh.
Where to start
Look at the biggest folders first. On many Macs that means Xcode and simulators, then the Android emulator, then the Gradle cache. The small caches rarely repay the effort.
- Xcode. Start with Cleaning up Xcode. DerivedData is the easiest win.
- Simulators. Old runtimes are large. See the CoreSimulator guide.
- Gradle and Android. Read how to clear the Gradle cache and Android Studio disk use.
- Homebrew. The cache is small, and there is a dry run that shows what cleanup would remove.
- Project folders.
node_modulesandtargetadd up across many projects. See finding every node_modules folder.
What not to do
Do not delete a whole hidden folder because it is large and unfamiliar. ~/Library/Developer holds disposable caches next to Archives, and a dot folder can hold credentials next to caches. Pick the subfolder, and know what it is. The article on whether it is safe to delete ~/Library/Developer goes through that folder piece by piece.
Moving a folder to the Trash does not free the space until you empty the Trash. See why the Trash does not free space.
Check how much room you have
Before you start, see how full the disk is:
df -h /
The Avail column is the space left. On the Mac used to check this article, the disk was 460 GB with about 62 GB available. Run it again after each step, so you can see what a step really gave you. If the number does not move, the folder was smaller than you thought, or the Trash is still full.
Worked example: one pass
Say you want a few gigabytes back, and you are not sure where they went. Here is a calm order of work:
- Run
df -h /and write downAvail. - Run the
du -shcommand from the first section, so you see which folder is largest. - Open the guide for that folder and read its Safe, Risky, Never box.
- Quit the tool that owns the folder.
- Remove the safe part only, empty the Trash, and run
df -h /again. - Open the tool and confirm it still works.
Stop when you have enough room. You do not need to clear every folder in the table.
When it goes wrong
- A build is slow after cleanup. That is the cost of a cold cache. The next build fills it again.
- A project cannot find a library. The cache held the only copy, or you are offline. Reconnect and build again. If the library came from a private server, check your credentials.
- A tool shows an empty device list or a missing runtime. You removed something by hand that the tool keeps a record of. Use the tool’s own settings to fix its list.
duprints “Permission denied” for some folders. Some folders are protected. Skip them. Do not change permissions to force it.
When not to clean at all
Do not clean right before a release, a demo or a long trip. A cold cache and a slow connection are a bad pair. If you have more than enough room, leave the caches alone. They exist to save you time, and an unused disk is not a problem to solve.
See the sizes in one place
DiskJoy is our product, so weigh this as the maker’s view. Its scan reads your disk and shows how much space each kind of file takes, including developer data, without changing anything. Cleanup is not built yet, so DiskJoy does not remove any of these folders today. Use the scan to see where the space is, then use the guides here to decide.
What it comes down to
Every folder in this guide is a trade: disk space now against rebuild or download time later. Clear what you can afford to rebuild, keep what you cannot recreate, and measure before you start.
Frequently asked questions
What is taking up space on my Mac as a developer?
Usually a handful of folders: Xcode DerivedData and simulators, the Gradle and Maven caches, Android emulator images, package caches for npm, pip, Cargo and Go, the Homebrew cache, and node_modules or target folders inside your projects. Run du -sh on each location in this article to see which ones are large on your Mac.
Why is System Data so big on a developer Mac?
Many developer folders are counted as System Data or Other in macOS storage settings, because macOS does not label them as apps or documents. Simulators, build caches and package caches are common contributors.
Are developer caches safe to delete?
Most are caches that the tool rebuilds or downloads again, so removing them loses time, not data. A few are not caches: Xcode Archives, Android emulator devices you set up, and anything in a project folder you have not committed.
More in Developers
- DevCleaner for Xcode alternatives
- Final Cut Pro, Logic and Adobe caches: reclaim space from creative apps
- JetBrains IDE caches and old versions: what to delete
- Cursor and VS Code eating disk space: workspaceStorage and state.vscdb
- Go module cache: location, size and 'permission denied' when deleting
- Rust target folders and the Cargo cache: reclaim disk space
- pip and conda caches on Mac: find and clear them
- npm, Yarn and pnpm caches: where they live and how to clean them
- Where is the .m2 folder on Mac and how to clean the Maven repository
- CocoaPods and Carthage caches: location and cleanup
- Where is the Swift Package Manager cache, and can you delete it?
- Simulator runtimes and CoreSimulator caches: reclaim tens of GB
- Find and delete every node_modules folder on your Mac
- Homebrew cache: where it is and how much brew cleanup frees
- Is it safe to delete ~/Library/Developer?
- Android Studio taking up too much space: SDK, emulators and AVDs
- How to clear the Gradle cache on Mac (and keep builds fast)
- Cleaning up Xcode: DerivedData, device support and old simulators