Developer guide

Mac developer storage: review caches without losing work

By learnhubplay · Practical checks and clearly labelled Tend features

Build tools can use more storage than your source code. The useful question is whether you can recreate a particular artifact when you need it, with the credentials, network access, toolchain, and time you actually have.

Measure the project before choosing a cleanup

Start with a project folder you recognize. Separate source and assets from dependencies, generated output, package-manager stores, simulator data, and container storage. Large totals may include logical or shared sizes, so avoid adding overlapping folder and whole-disk measurements.

In the direct edition, Tend's node_modules finder shows size and package/lockfile evidence. Folder modification dates are useful context, but do not prove when a project was last used or whether it is safe to remove.

Check whether dependencies are reproducible

A lockfile records dependency choices; it does not guarantee future access to a private registry, a deleted package, or a local dependency. Check for local edits, linked packages, install scripts, credentials you can still obtain, and any resources you need without internet access.

Review the package manager's documentation before reinstalling. For example, npm ci expects a suitable lockfile and removes an existing node_modules directory before installing. It is an installation command, not a read-only diagnostic or an Undo operation.

Keep project identity and Git state separate

A clean Git status only describes what Git knows how to report. Ignored assets, local databases, environment files, generated deliverables and untracked work can still matter. Linked worktrees may depend on shared repository metadata. Use Git's own worktree inventory and respect locks; do not treat an old folder as abandoned because its name looks temporary.

Review Docker through Docker

Docker images, containers, volumes and build caches are different categories. Start with the read-only docker system df -v report to inspect active use, shared data and unique sizes. Docker's reported reclaimable total is not a guarantee that the same amount immediately appears as free space in Finder.

Pruning is permanent and can remove resources you intended to keep for offline work. Named volumes may contain databases or other user data. Do not delete Docker's disk image directly to “clear its cache,” and read the command's exact scope before approving a prune.

Review Xcode and other toolchains narrowly

Build output, downloaded SDKs, simulator runtimes, archives and signing resources have different recovery costs. An archive or locally modified environment should not be treated like an ordinary cache. Prefer supported controls in Xcode or the relevant tool, and check whether you can download the same required version later.

Use a repeatable review checklist

1. Identify the owner and purpose of the data.
2. Save current work and review repository/worktree state.
3. Confirm how recreation would work, including offline and private-package needs.
4. Choose a small, explicit action and read its consequences.
5. Build or run the project again and compare the result.

Repeated cleaning that immediately regrows may cost more time than it returns in useful space. Keep the active project usable first; review older environments only when the evidence supports it.

Subscribe to new guides with RSS · No signup or tracking