A development machine accumulates several kinds of storage that look alike in a disk scan: generated output, downloaded dependencies, test data, and work that exists nowhere else. A useful cleanup begins by separating those categories.
Find the large directories before choosing commands. Scan your projects and user Library, or inspect them with Finder and read-only disk usage tools. Note which tool owns each large area and whether that tool is actively writing to it.
Category
Examples
Before removal
Generated data
Build intermediates, indexes, reproducible output
Confirm the inputs and build process are available.
Downloaded data
Packages, toolchains, simulator runtimes
Confirm you can retrieve the required version again.
Working data
Source changes, simulator fixtures, local databases
A directory called “cache” is worth inspecting. A directory called “data” needs a more specific explanation. Neither a large size nor an old modification date makes the decision for you.
02 Xcode: separate build output from releases
DerivedData is a common source of generated storage. Stop builds and remove only the project data you intend to regenerate. Manage unused simulator runtimes in Xcode's Components settings instead of deleting files inside the runtime installation. Apple documents the component controls.
Preserve release archives and their matching debug symbols. Simulator devices may also contain test cases you cannot recreate from a fresh install. Our Xcode cleanup guide covers these boundaries in detail.
03 Docker: inspect the engine before the disk image
Start with Docker's own storage report:
docker system df -v
The report separates images, containers, local volumes, and build cache, including shared image data. It gives better context than treating Docker's entire disk image as a single disposable file. Docker explains each field.
If you choose to run docker system prune, read its confirmation carefully. It removes stopped containers, unused networks, dangling images, and unused build cache. A stopped container may contain uncommitted work in its writable layer. The -a and --volumes options expand the scope; do not add them by habit. Review the prune reference.
04 JavaScript: inspect projects and the package cache separately
An inactive project's node_modules may be reproducible from its manifest and lockfile, provided the dependencies remain available. Check for local patches, linked packages, and generated artifacts before removing it. Keep source files, lockfiles, local configuration, and any data you need to restore the project.
For the npm cache, first locate and verify it:
npm config get cache
npm cache verify
npm describes its cache as self-healing. Verification checks integrity and garbage-collects unneeded data. Forcing the entire cache to clear is not a routine fix for every dependency problem and can require new downloads. Read npm's cache documentation.
05 Homebrew: preview the cleanup
Homebrew can report its planned cleanup before changing anything:
brew cleanup --dry-run
Review the output. If it matches your intention, brew cleanup removes the items selected by Homebrew's cleanup policy. Use that supported behavior instead of manually emptying broad installation directories. The Homebrew manual explains the options.
Apply the same approach to other ecosystems: locate the actual cache, check the tool's documentation, and distinguish downloaded artifacts from configuration or locally published packages.
06 Confirm the result and the next build
Recheck available space on the same volume after the cleanup. Open the affected project, restore the dependencies you need, and run the build or workflow that matters. A cleanup is complete when the workspace still works and you understand what was removed.
APFS shared blocks and snapshots can make the recovered space differ from directory totals. Docker's internal accounting can also differ from the host disk image's apparent size. Understand the measurements before chasing a mismatch.
07 Use a disk map to decide where to focus
Delve helps you compare project folders, build output, and tool storage in one visual view. Start with the largest relevant area, inspect its path, then return to the owning tool for data it manages itself.
Build intermediates, indexes, and downloaded dependencies are often regenerable when their original inputs and required versions remain available. Confirm the project configuration before removing them.
Is docker system prune safe for every project?
No. It can remove stopped containers and build cache you still need. Review its scope, preserve writable-layer data, and back up persistent data before pruning.
Should I force-clear the npm cache?
Start with npm cache verify. npm documents the cache as self-healing, so blanket clearing is usually unnecessary for troubleshooting.