
Why I Built a Disk Analyzer
The most useful apps are the ones you build out of frustration.
My Mac was full. Not “a few gigabytes left” full. Truly full. The kind of full where Xcode refuses to build because there is nowhere to write a temp file, and you spend twenty minutes deleting screenshots of things you no longer remember caring about.
I needed to find where the space went.
Good disk analyzers already exist. DaisyDisk is polished and beautiful. GrandPerspective is free and reliable. I was not trying to replace them, and Renala is free anyway. This was never about competition.
I wanted to build one myself. That is all. I decided to build it, convinced it would take a few weekends.
It took considerably more than a few weekends. But it was usefully wrong.
A disk analyzer is a bounded scope. Clear input: a directory. Clear output: a visual map of what is eating your space. No user accounts, no network requests, no database schemas. The hard parts are well-defined: read the filesystem, compute a layout, render it.
It also has a satisfying algorithm at its core. A treemap turns every file into a rectangle whose area matches its size. Your 30 GB Docker folder is visually thirty times larger than the 1 GB Xcode cache next to it. Ben Shneiderman described the concept in the early 1990s; the squarified variant, which keeps rectangles closer to square, came later and is still the standard. When I read the original paper, I understood it immediately. That is the sign of a good algorithm: the idea is obvious in retrospect, even if the implementation requires care.
Most backend work is invisible. You write code, deploy a service, watch metrics move on a graph. A disk analyzer shows you something real in seconds. You scan a folder, rectangles appear, and that enormous purple block in the corner turns out to be Docker images you forgot about. For a learning project, fast visible results are worth a lot.
I am a backend and web developer. TypeScript, .NET, Java, databases, APIs, deployment pipelines. I had never written a line of Swift. I had never opened Xcode except to install the command-line tools. The macOS application model, with its bundles and entitlements and code signing and provisioning profiles, was entirely invisible to me. I knew it existed the way you know plumbing exists: it works, you do not think about it, and you are deeply unprepared for what you find when you open the wall.
I could have built this as an Electron app. I know JavaScript. Electron would have given me a working prototype in an afternoon, a distributable binary in a day, and 300 MB of Chromium bundled with a file browser. The whole point was to build something native. Not as a philosophical position about software quality, though that played a role. More practically: I had been working on macOS for years and had never understood how it actually worked. The signing, the sandbox, the App Store review process, the human interface guidelines. I wanted to understand the platform I use every day, not just use it.
Learning Electron would have taught me nothing I did not already know. Learning Swift and SwiftUI and the macOS SDK would teach me things I could not get anywhere else.
The honest account of why I built Renala is this: my disk was full, I was curious, and I wanted to build something I would actually use.
You do not ship a disk analyzer with a broken treemap layout. You do not publish to the App Store with a UI that embarrasses you. Nobody writes better code than a developer who has to use their own software.
I also set a few non-negotiable principles from the start. The app would follow Don’t Make Me Think: every interaction should be self-evident, no user should have to puzzle over what a button does. It would be accessible: VoiceOver support, keyboard navigation, no information conveyed by color alone. And it would be localized from day one, not retrofitted: eleven languages, including Arabic with right-to-left layout and correct plural forms. These are not features you list on a marketing page. They are the floor.
A few weeks in, it worked. I was using my own thing.
That is the moment when a side project becomes a product. Not when you submit it to the App Store. Not when someone else downloads it. When you start reaching for it yourself.
The disk was full. Now it is not. The rest is details.