The picture is the product, the picture lives on the GPU, and the bookkeeping underneath has to be honest or none of it is worth shipping. Here's how Delve fits together: the layout, the renderer, the scanner, and the math that decides what a gigabyte even means on APFS.
Every rectangle is one file. Its area is its size. Its colour is its extension. Nested folders cushion-shade into gentle 3D so the hierarchy reads at a glance. Deep clusters look like a relief map; shallow ones look flat. Hover to learn what it is, click to delve in, space-bar for Quick Look. The whole product is "trust the picture," and the picture only works if the math underneath is honest. Which is where most disk apps stop.
The slow way to draw two million rectangles is to issue two million separate instructions. No computer can do that fast enough. The fast way is one instruction: "here's the shape of a rectangle, stamp it two million times, each with its own position, size, and colour." The GPU does the whole thing in a single pass. On Apple Silicon there's a second free win: the chip's memory is shared between CPU and GPU, so the scanner writes the tile list straight where the renderer reads it, no copy in between. That's most of why Delve only ships on Apple Silicon.
The 3D cushion shading on each rectangle is what makes a treemap feel like a treemap. Without it, you're staring at a quilt of flat blocks and the hierarchy disappears. We implemented the proper algorithm (Jarke van Wijk's Squarified Treemaps, 2000) instead of the cheap shortcut some tools use: a radial gradient faked onto each tile. The cheap version looks close from across the room, but the moment you try to read the picture it falls apart.
Hit-testing two million tiles sounds trivial until you try. The textbook answer is a separate CPU tree that tracks where every tile lives on screen, rebuilt on every pan and zoom: a second source of truth that has to stay in sync with the picture you're actually showing. We skip it. The GPU already knows which tile ended up at which pixel, so we draw the picture a second time into an off-screen buffer, with each tile coloured by its ID, and treat that buffer as the lookup. No index, no sync code, correct by construction.
APFS files can share storage. When you duplicate a 4 GB iOS DeviceSupport bundle, APFS clones it: the new file points at the same blocks. Both files report 4 GB logical size. Together they take ~4 GB on disk, not 8. Same for hardlinks (multiple directory entries to one inode); same for iCloud dataless stubs (3 KB placeholders that logically contain 4 GB).
A tool that ignores this will tell you you'll save 87 GB by deleting a folder, and APFS gives you back 12. Delve does the bookkeeping: every inode counted exactly once no matter how many directory entries point at it, logical and on-disk size side by side.
/Library/Developer/Xcode/iOS DeviceSupport
You'd save 12.1 GB deleting this, not 87. The rest are APFS clones sharing the same blocks.
~/Movies/IMG_4421.mov · 3 hardlinks
Each inode counted once, no matter how many directory entries point at it. No phantom storage.
~/iCloud Drive/Documents · dataless stubs
Cloud stubs detected and tagged with a cloud glyph. We never accidentally materialize a file just to read its size.
The bottleneck in a disk scanner isn't reading file contents. It's stat'ing every file. NSFileManager does this one entry at a time, a fresh syscall per file. On a million files, that's a million round trips through the kernel.
macOS has had getattrlistbulk for a decade: one syscall
that returns an entire directory's worth of metadata. Exactly what a
disk scanner wants, and almost nobody uses it: the API is
genuinely unpleasant and the docs assume you've read the source. We
took the time to wrap it carefully. The scanner runs
3–5× faster than the NSFileManager approach, and a
1 TB APFS volume with a few million files finishes in under
90 seconds on a base-model M2.
The Mac-specific things we wanted Delve to do because they're right for a Mac app.