I built a zip viewer nobody asked for

I double-clicked a 4 GB zip and went to make coffee.

It was a backup — a year of build artifacts, and I needed exactly one file out of it. My Mac didn’t open the archive. It extracted it: thirty seconds of spinning fans, four gigabytes copied into a temp folder I never asked for, all so I could read one small file inside. Then I deleted the four gigabytes.

I’d done this a hundred times without thinking about it. That day it annoyed me enough to build something.

Open is the wrong word

Opening archives was never the problem. The problem is that open isn’t what happens.

When you double-click a zip, your computer doesn’t open it — it extracts it. It copies the whole thing to a temp folder, hands you the result, and trusts you not to look behind the curtain. For a small download, that’s invisible. For a 4 GB archive, it’s the coffee break above: a wait, some fan noise, and a disk you didn’t agree to fill. Usually to read one file.

What I wanted was Finder, but for archives. Open it instantly. See the shape of it. Peek at one file. Pull out the three things I need and leave the rest packed exactly where they were. For browsing, a zip can behave as if it’s already on disk — so it should.

Why build it when it already exists

I looked first. The tools that did this were ugly, or paid, or bundled with six features I’d never touch. None of them did the one thing the way I wanted it done.

That’s half the answer. The other half is that I wanted to build it. There’s a real, slightly embarrassing pleasure in a tool that does exactly one thing exactly your way, with no settings menu apologizing for the parts you didn’t decide. And the scope was small enough to finish — which is the most underrated thing a side project can be.

“Already exists” and “exists the way I want” are different sentences. Most of my favorite projects live in the gap between them.

The trick: you don’t have to read a zip to open it

Here’s the part that made it worth building. You don’t have to read a zip to open it.

Every archive keeps an index at the very end — the central directory. It lists every file inside, how big each one is, and where its bytes start. It’s a table of contents, and it’s tiny next to the actual contents. Grizzly reads only that index, folds the flat list of slash-separated paths into a real folder tree, and shows it to you.

So a 4 GB archive opens about as fast as a 4 KB one. In both cases I’ve read a few kilobytes and stopped. The file data stays on disk, untouched, until you preview or extract something — and then I stream only that one file, never the whole archive.

That’s the thing the OS hides inside “open,” turned into the entire point of the app.

Why I made it native

I could have built this as an Electron app in a weekend. I didn’t, on purpose.

The whole appeal is that the tool feels lighter than the job it’s doing. It launches instantly, weighs a few megabytes, previews a file the second you hit spacebar, and opens the moment you drop a zip on it. A utility that feels heavier than its task is one I’d uninstall — and I wasn’t going to ship something I’d uninstall.

SwiftUI got me there fast, and the result feels like it belongs on the machine instead of visiting from a browser. For a small tool that lives or dies on feel, that wasn’t a detail. It was most of the work.

What I got out of it

Users, a little. It’s open source, CI cuts a DMG on every tag, and people download it. That’s genuinely nice. It was never the point.

The point is that I shipped a thing end to end — the idea, the one good decision at the center of it, the icon, the release pipeline, the README nobody reads. I use it almost every day. Every time I drop a giant archive on it and it opens now instead of eventually, I get a small, specific hit of making the thing behave the way I wanted the world to behave.

That’s the case for building what already exists. Not that the world needed another one. That you did — and now it works your way.