why your mac fills up faster than you expect
apple sells 256 gb and 512 gb ssds as the baseline for most macbook lines. those numbers felt generous a few years ago. they fill up faster than expected for a few compounding reasons: apps install silently into ~/library/application support; xcode simulator runtimes each run 4–8 gb and accumulate across ios versions; creative work brings raw footage, psd stacks, and logic projects that compound quickly; and macos itself keeps local time machine snapshots in system data that aren't always obvious in the storage view.
the result is that a machine that felt spacious a year ago suddenly has 8 gb left and you can't figure out why. the 'about this mac → storage' view categorises roughly but doesn't let you drill in — you see 'documents: 45 gb' with no way to know whether that's a single archive or ten thousand tiny files. a treemap shows you the actual shape of the problem.
map your disk before you delete anything
open grove and click scan. it walks your ssd — usually under 30 seconds on a 512 gb drive — and renders the result as a squarified treemap. each rectangle is a folder or file; its area is proportional to its size. the biggest thing on your disk is, literally, the biggest thing on screen. hover to see names and sizes; click any folder to zoom into it and see its contents as a fresh treemap.
this step alone is usually enough to find the culprit. common discoveries: a ~/movies folder full of 4k footage from a project you wrapped two years ago; a ~/.docker/volumes path that's grown to 20 gb of image layers; ~/library/developer/xcode/deriveddata at 35 gb from dozens of past builds; a video editing app's auto-save directory that nobody cleared. none of these show up in the vague 'documents' category — they only appear when you can see the actual shape of your disk.
the files worth targeting first
once the treemap reveals the biggest consumers, a rough priority order applies. developer caches are the safest targets: xcode's derived data and simulator runtimes are entirely safe to delete (xcode rebuilds them on the next build). docker images and volumes can be pruned with `docker system prune` if you no longer need them. npm and node_modules directories inside old project folders are safe to delete; reinstall with `npm install` when you need them again.
media files deserve a decision, not an automatic delete: check that they're backed up before removing them. similarly, app support folders in ~/library vary — some are safe to clear, others hold settings you'd regret losing. grove's 'reveal in finder' button opens the folder in question directly, so you can inspect before you act. grove itself never deletes anything; every removal stays in your hands.
frequently asked
what is 'system data' in the mac storage view and can i delete it?
system data is apple's catch-all for caches, logs, local time machine snapshots, temp files, and some app support directories. most of it is safe to reclaim but you can't delete it directly through the storage view. clearing specific caches (~/library/caches), deleting old time machine snapshots via `tmutil deletelocalsnapshots /`, and removing simulator runtimes via xcode's settings are the common safe approaches. grove shows you exactly which directories are large inside the system folders so you know what to target.
is it safe to delete files grove shows me?
grove shows you every file on your disk — some safe to delete, some not. it never deletes anything itself; it only points you at files and opens them in finder. before removing anything: verify it's not the only copy, check whether an app relies on it, and for anything in ~/library or /library, do a quick search to confirm what it's for. developer caches and old project node_modules are generally the safest starting point.
why does my mac say 'disk almost full' when i only have a few large apps?
because apps often have data footprints far larger than the app bundle itself. xcode (2.5 gb app) generates 20–40 gb of derived data. final cut pro (3 gb app) accumulates render files and motion content libraries. creative cloud applications cache assets in ~/library/application support. the app size in the applications folder is rarely the whole story — the treemap shows you the complete picture including all those hidden support directories.
how long does a grove scan take?
typically under 30 seconds on a 512 gb ssd. grove reads file sizes using native macos apis without reading file contents, so scan time scales with the number of files and folders rather than total data size. a very fragmented disk with millions of small files may take longer than a disk with fewer but larger files.
Last updated June 22, 2026