Delve is built around a short sequence: see the storage, understand the files, and decide what to keep. Its architecture connects a filesystem scan to an interactive map and then to a removal you can review.
A directory listing is precise, but it asks you to compare numbers across rows and open folders one at a time. A treemap gives those values a visual relationship. Large files occupy more area, and files from the same folder form a recognizable group.
Delve uses a squarified layout to keep rectangles practical to inspect. The underlying technique comes from Bruls, Huizing, and van Wijk's Squarified Treemaps. Cushion shading adds depth cues that help distinguish nested groups.
The sunburst offers another view of that hierarchy. Rings emphasize the path through nested folders, while the treemap emphasizes relative area. Compare the two layouts to see how each supports a different inspection task.
02 Let the renderer serve the interaction
The native app uses Metal for its visual map. A rectangle can be represented as shared geometry plus per-item position, size, and color, so the renderer can draw many tiles without treating each one as a separate interface control.
That matters when you zoom, pan, or inspect a dense directory. The map needs to remain connected to the selection and inspector, so the item you point to is the item whose path and metadata you see.
The design goal is responsive exploration across real workloads. Performance depends on file count, directory structure, storage hardware, access permissions, and the state of the machine. Disk capacity alone is not a meaningful benchmark.
03 Read the metadata needed for the map
A disk scan needs names, hierarchy, identifiers, and size information. It does not need to read every file's contents to draw the folder structure. macOS provides bulk metadata APIs such as getattrlistbulk, which can return attributes for several entries in one call.
Bulk enumeration reduces repeated per-entry requests, but still requires careful handling of returned records, errors, and inaccessible paths. Apple's API documentation describes that interface.
Coverage also belongs in the user experience. A scan of accessible paths should not imply that every protected location or snapshot has been measured. The useful result is a map with understandable boundaries.
04 Keep the measurement separate from the promise
The map's rectangles are only as useful as the numbers behind them. Logical size describes file contents; on-disk size describes reported allocation. APFS clones, hard links, cloud files, and snapshots affect how those values relate to the volume.
A disk tool should preserve that distinction through the inspector and cleanup workflow. In particular, a folder total cannot guarantee the exact space that deletion will recover. Our APFS accounting note covers the limits and explains why clone sharing differs from hard-link identity.
05 Keep inspection close to the decision
Quick Look: preview a selected file before deciding whether it belongs in the cleanup.
Folder navigation: follow a region into its contents and keep the file path in view.
Two visual layouts: change perspective when a different representation makes the hierarchy clearer.
The Collector: gather selected candidates, review them together, and move the chosen items to the Trash.
The Collector separates finding a candidate from acting on it. That small pause gives the file's context a place in the decision. The purpose of the map is a better choice, not simply a more dramatic picture.