Every storage tool can tell you that ~/Library/Developer/Xcode/DerivedData is 47GB. Far fewer can tell you what DerivedData actually is, why it grew to that size, and whether deleting it will cost you anything beyond a slightly slower next build. That gap — between measuring a folder and explaining it — is the real distinction behind the category of tool that markets itself around "insights" or "smart recognition."
Why size alone is an incomplete answer
A storage map answers "where" very well and "what" not at all. Once you've zoomed into the biggest rectangle on your disk and found it's a folder you don't recognise, the map has done its job and handed the harder question back to you: is this safe to remove, will removing it cost me anything, and will it just grow back tomorrow?
For a developer, a designer, or anyone running specialised software, the answer to that question often requires knowing quite specific things — that node_modules regenerates from a lockfile with one command, that Xcode's DerivedData is disposable build output rather than source, that Docker's Docker.raw file doesn't necessarily shrink when you delete images inside the containers it holds. None of this is visible from a folder name and a size number alone.
What "recognition" means in a well-built tool
A tool that recognises folder types does something more specific than pattern-matching on names. Done well, it identifies a folder by what it structurally is — the presence of specific marker files or directory layouts associated with a known cache or build system — and then supplies context: what generated it, whether it's safe to remove, and what regenerating it costs (time, a re-download, nothing at all).
The categories worth recognising span a wide range of tools, not just one ecosystem:
| Folder pattern | What it typically is |
|---|---|
node_modules |
JavaScript/TypeScript package dependencies, regenerable via npm install or equivalent |
~/Library/Developer/Xcode/DerivedData |
Xcode build intermediates, regenerated on next build |
~/Library/Developer/CoreSimulator/Devices |
iOS/watchOS/tvOS simulator disk images |
Docker.raw |
Docker Desktop's virtual machine disk |
~/.cargo/registry, ~/go/pkg/mod, ~/.gradle/caches, ~/.m2/repository |
Language-specific package/dependency caches (Rust, Go, Gradle, Maven) |
~/Library/Caches/Homebrew, ~/Library/Caches/CocoaPods |
Package manager download caches |
Each of these has a genuinely different safety profile. node_modules and most package caches are safe to delete and will simply be re-downloaded or rebuilt on demand — at the cost of time and bandwidth, not data. Xcode's DerivedData is similarly safe and disposable. iOS Simulator device data is a bit more nuanced: deleting a simulator device removes any app data and test state you had on it, which matters if you were mid-way through manual testing, even though the simulator itself will be recreated.
Why explanation matters more as the sink is less familiar
The value of automatic recognition scales with how unfamiliar the sink is to the person looking at it. An experienced Node.js developer doesn't need a tool to tell them what node_modules is. But the same developer, working across half a dozen ecosystems in a given month, may not know off the top of their head whether a particular ~/.cache/ subfolder from a tool they installed once is safe to remove, or whether a .gradle cache they haven't touched in a year is still actively used by something.
This is also where recognition matters most for non-developers who nonetheless end up with developer-adjacent tools installed — someone running a single Docker container for a hobby project, say, who has no particular reason to know that Docker.raw doesn't shrink on its own even after removing images.
Explanation versus instruction
There's a meaningful difference between a tool that tells you what a folder is and one that tells you what to do about it, and the better ones keep that distinction clear rather than blurring it into a single confident recommendation. "This is Xcode's DerivedData folder, which Xcode regenerates automatically on the next build" is a factual, checkable statement. "You should delete this" is a recommendation that depends on context the tool can't fully see — whether you're mid-way through a build, whether disk space is actually a problem right now, whether you have a reason (however unusual) to want to preserve a specific build's intermediates.
A tool that leads with explanation and leaves the decision to you is doing something more durable than one that leads with an instruction, because the explanation stays true regardless of your specific situation, while a blanket instruction might not fit it.
Why grouping similar caches together helps
Beyond identifying individual folders, a useful recognition layer can group related items — every package manager cache across every language you have installed, for instance — so you can see the collective size of "stuff I could clear and regenerate later" as a category, rather than hunting for each one separately across a scan. This is particularly useful on a Mac that's accumulated tooling across several years and several projects, where the number of distinct cache locations can be larger than anyone actively keeps track of.
The limits of automatic recognition
No recognition system can cover every possible cache or build artifact — new tools and package managers appear constantly, and a list of known patterns is inherently a snapshot that needs updating over time. A well-built tool should be honest about this limit: unrecognised folders should still show up in the scan with their size, just without the added explanation, rather than being hidden or downplayed because the tool doesn't have a label for them.
It's also worth being skeptical of a tool that claims to definitively know a folder is "safe to delete" with total certainty. The more honest framing is "this folder is of a known type that is typically safe to regenerate" — because context can always vary (a DerivedData folder mid-build, for instance, or a cache a specific workflow depends on more than usual).
Where VolumeLens fits
The paid Insights tier in VolumeLens is built specifically around this explanation layer: automatic recognition of node_modules, Xcode's DerivedData and simulator devices, Docker's VM disk, Homebrew and CocoaPods caches, and the caches for npm, pnpm, Yarn, pip, Cargo, Gradle, and several other common ecosystems — each labelled with what it is, not just its size. The free tier still gives you the scan, the map, and search, without the explanation layer, so you can decide for yourself whether recognising two dozen specific cache types is worth paying for before you commit. See the full list on the features page or check pricing if you want the specifics of what's included.