Why your screen recorder shouldn’t weigh a gigabyte

Before writing a line of Snapbak, I looked at how big the tools I already used actually were. I expected a few hundred megabytes. Some of them were over a gigabyte.

The numbers

These are installed .app sizes on Apple Silicon Macs, from Desktop Insights binary scans taken between August and October 2026:

If you use a recorder, a dictation app, and a screenshot tool from that list, you can easily be carrying two gigabytes of apps whose job is to sit in your menu bar and wait for a hotkey.

Where the weight comes from

The easy answer is “Electron,” and it’s part of the story. An Electron app ships a full copy of Chromium and Node.js inside every install. That alone costs a couple of hundred megabytes before the app does anything.

But the framework isn’t the whole answer. Cap is built on Tauri, which uses the system’s web view instead of bundling a browser, and it still installs at 421 MB. The bulk comes from what it packs alongside: video processing libraries, GPU rendering code, and machine‑learning models for captions.

That’s the real lesson. Bundled media and ML libraries matter more than the UI framework. A native app that ships FFmpeg, three speech models, and an analytics SDK will be big too.

Why is my screen recording laggy?

Lag has three usual causes, and weight is only one. First, the encoder: an app that compresses on the CPU competes with everything else you’re running — hardware encoding offloads it to a dedicated chip. Second, the disk: writing uncompressed frames to a slow drive stalls the capture loop, which is why Replay‑style buffers live in memory. Third, bloat: an Electron shell holding a browser in memory next to your workload. A recorder that targets well under 100 MB at idle and encodes in hardware removes all three — which is the design brief this post is about.

Why it matters

Every size in this post now lives in one table on the benchmarks page — ours measured, theirs scanned, with the conditions each number was taken under.

A big install isn’t just disk space. It usually means:

• More memory at idle. Competitors of Wispr Flow report it idling around 800 MB of RAM. That figure comes from rival vendors and I haven’t verified it, but it’s the complaint people repeat most.
• Slower launches and updates. Every update re‑downloads hundreds of megabytes.
• More things that can break. Loom’s own support docs recommend 16 GB of RAM and warn that recording may fail on older machines.

A capture tool is something you reach for in the middle of something else: a bug just happened, a teammate needs a quick walkthrough. It should be the lightest thing on your Mac, not the heaviest.

What we’re doing differently

Snapbak is a native macOS app, and the plan for keeping it small is simple:

1. Use what macOS already has. ScreenCaptureKit for capture, the hardware video encoder for export, Apple’s frameworks for OCR and on‑device speech where they’re good enough.
2. Download models on demand. If you never use dictation, you never download a speech model. The open‑source dictation app Handy does this and installs at 43 MB.
3. Unload what’s idle. A speech model shouldn’t sit in memory while you’re writing code.

Our target is a 15–20 MB installer and an idle footprint well under 100 MB of RAM. Those are targets, not measurements yet. When v1.0 ships, I’ll publish real numbers from real machines in the changelog.

One small app that records, screenshots, dictates, and catches bugs should still be smaller than any one of the tools it replaces. That’s the bar.

Get Snapbak free while early‑access spots last →