Radix: a fast macOS disk space analyzer that explains itself

Two ways to look at the same tree

The headline feature is the visualisation, and the readme puts it first.

You can switch between a sunburst view and a treemap view to understand how space is distributed. Hovering over an item inspects it, and double-clicking a folder drills deeper. The two views answer different questions. A sunburst is a radial hierarchy, so you can read the shape of a directory tree at a glance and see which branch dominates, while a treemap is better at comparing sibling sizes, because area is directly comparable between rectangles.

The framing of the project is worth reading, because it explains the audience. Storage fills up quietly, and Radix makes it obvious where it went, with no Terminal commands and no waiting through scans that crawl forever. You point it at a folder, and it gives you a clean visual breakdown of directories and files.

So the target user is someone who has a Mac, has run out of room, and does not want to learn a command line tool. The readme says the app is built with Swift and SwiftUI and designed to feel like a natural part of macOS, which is the claim you would expect for a native application and which the presence of a native file browser, Quick Look previews and Finder integration all support.

The other thing the readme emphasises is speed, but the way it says it is careful. It says fast, iterative file-system scanning with live progress, and faster follow-up scans by reusing previous results when possible. The second of those is the more interesting claim, and the architecture section explains how it works.

A browser, a search and a filter

The visualisation is the entry point, but the readme spends a paragraph on the other half of the tool, and that half is where you will spend your time.

There is a sortable file browser to inspect items, a search that covers either the current focus or the entire scan, and a filter by item kind or by allocated size. Files can be previewed with Quick Look, and you can move around with breadcrumbs and with back and forward navigation.

The distinction between the current focus and the entire scan is a small design decision with a big effect on how the tool feels. A search scoped to what you are looking at is fast and predictable, and a search across the whole scan is what you want when you are hunting for one large file somewhere on the disk. Supporting both means you can start narrow and widen.

The filter by allocated size is the other useful one, and it is worth understanding what it means. On a modern filesystem a file occupies space in blocks, so a small file still occupies a whole block on disk. Filtering by allocated size shows you what is actually consuming the drive, and combined with the automatic summarization of directories containing thousands of tiny files, it turns a list of forty thousand entries into a list of the hundred that matter.

The inspector gives the detail view for one or several items, with sizes, access information, the parent directory and the largest children, and the actions include revealing in Finder, copying the path and moving to the Trash.

Comparing two scans, and the discard pile

The comparison feature is the one that makes Radix more than a viewer of the present.

You can compare two scans to see which files and folders grew, shrank, appeared or disappeared. That turns the tool from a snapshot into a history, and it is the feature that answers the question people actually have about their disk, which is what is eating it, and when did that start.

The design is that a scan is a snapshot you can reopen. Completed scans can be exported as compact, losslessly compressed snapshot files with a specific extension, and reopened later as read-only results. The readme describes those as read-only, which is the right choice: a snapshot is a record of what was true at a moment, and letting you delete files from a snapshot would be meaningless.

The cleanup workflow is built around a discard pile. You add items from the disk map, from the file browser or from the inspector to a pile, review everything together, and only then decide whether to move anything to the Trash. The staging step is what makes bulk cleanup safe, because a single action on a tree visualisation is easy to misread as a single item when it is a whole directory. The sidebar holds the smart locations, the recent scans and the discard pile, so the pile stays visible while you explore.

And the safety model is part of the data model rather than a UI convention. The project structure lists a models directory that includes safety models alongside scan targets, node records and snapshots, which suggests the guard against deleting the wrong thing is enforced in code rather than in a confirmation dialog.

APFS clones and the permission caveat

Two details separate Radix from a naive size calculator, and both are about honesty in the numbers.

The first is APFS-aware storage accounting that avoids double-counting full clones and detects partial clones. On APFS, a file can be cloned so that two paths share the same physical blocks, and a tool that adds up the logical sizes of every file will report far more space than the drive has. Radix counts the shared blocks once and identifies the partial clone case, where a file shares some blocks with another. If you have ever seen a disk usage tool claim your drive is fuller than it is, this is the reason, and this is the fix.

The second is permissions. Radix works out of the box on any folder you can already access, but for some folders the app may require Full Disk Access, and it detects when files are skipped due to permissions and guides you through enabling them in System Settings. That is the right behaviour, because the alternative is a scan that silently under-reports and a user who believes the total.

The readme also lists optional free-space display in the disk maps, custom scan exclusions for paths you do not want included, and smart locations for mounted volumes and the standard home directory folders. The exclusions matter for the same reason the APFS accounting does: a scan that includes your package cache or your virtual machine images tells you about your tools rather than about your data.

The scanner, the actor and the snapshot format

The developer documentation is where the interesting engineering is, and it is unusually specific.

The scan engine is an actor-based asynchronous scanner that uses iterative file-system traversal. Iterative rather than recursive is the important word, because a recursive walk over a filesystem with deep symlink structures or a pathological directory will blow the stack, and a disk analyser is exactly the kind of program that meets pathological directories. The actor means the scan runs on its own executor and can be cancelled.

A scan coordinator owns the scan state, and an incremental scan service reuses prior results when it can safely reconcile filesystem changes. That is the follow-up scan speed claim from the highlights, and it is the hardest part of the tool, because reusing a previous result means proving that the directory has not changed, and filesystem timestamps lie often enough that the reconciliation has to be conservative.

The application model is the central main-actor state and coordination layer, and the results are represented with flat tree storage and indexed lookups, which is the right choice for a structure that has to be serialised, diffed and rendered. The archive and comparison services stream, validate and compare snapshots, and the current format version losslessly compresses the large node and topology sections with LZFSE while retaining import compatibility with the two previous versions.

That combination of a streaming reader, a validation pass and a compressed format with a compatibility window is what you would expect from a file format intended to be shared, and it is more thought than most applications give to their save file. The core package has no external Swift package dependencies, and the application itself uses Sparkle for updates.

Building it, and what the requirements tell you

The installation is a Homebrew cask or a drag to the Applications folder, and the system requirement is macOS Sonoma 14 or later.

brew install --cask radix

Building from source needs Xcode 26 or later with a Swift 6.2 toolchain, and the test suite is a Swift package, so the quickest check is to clone and run the tests:

git clone https://github.com/colinvkim/Radix.git
cd Radix
swift test

The full application is an Xcode project, and the readme gives the command line build as well:

xcodebuild \
  -project Radix.xcodeproj \
  -scheme Radix \
  -configuration Debug \
  -destination 'platform=macOS' \
  build

The project structure is worth noting because it shows the separation the developer is making. The application and the core live in a directory with an app entry point, models, services, view models, a set of feature directories for each part of the interface, and a shared directory for reusable SwiftUI components. Alongside it there is a test directory described as containing unit, integration and benchmark-style tests, a package manifest for the core, and the Xcode project for the whole application.

So the core is a separate Swift package with its own test suite, the shared Xcode scheme runs the same core tests, and the command line build can be swapped from building to testing.

The release cadence matches that of a polished Mac utility. Version 1.6.0 came in July 2026, 1.7.0 later the same month, and 1.8.0 in September, with the last push on 2026-10-20, the repository not archived, the licence MIT and automatic updates delivered through Sparkle. The app ships in seven languages, and the release channel is the project's own website as well as the GitHub releases page.

Editorial conclusion

Radix suits a Mac user who wants to understand where a crowded drive went without writing a find command, and the comparison feature makes it useful for tracking what changed between two points in time rather than only describing the present. It is a poor fit if you need to scan a remote or network volume, if you are on a macOS release older than Sonoma, or if you want to script the analysis, since the snapshots are read-only results in an app rather than a queryable interface. Before you point it at a disk, check the permissions situation, because the app will skip files it cannot read and the totals will then be incomplete, and read the exclusion settings so your own large but irrelevant directories do not dominate the picture.

Frequently asked questions

Official sources

1. colinvkim/Radix on GitHub
2. License: MIT
3. Project website
4. README
5. Releases