Why I Built a Native Mac App Instead of a Web App — and What I'd Do Differently

#rust #tauri #webdev #programming

All tests run on an 8-year-old MacBook Air.

When I decided to build a PDF tool, the obvious choice was a web app.

I built a native Mac app instead. Here's the honest breakdown of that decision — including the parts I'd reconsider.

Why native won

Privacy is a feature, not a differentiator.

PDF tools that run in the browser send your files somewhere. Even "client-side" web apps have privacy gray areas — telemetry, crash reports, CDN-loaded libraries.

A native app with no network calls is the only architecture where "your files never leave your machine" is actually true. For the use case (contracts, medical records, tax documents), this matters to users.

Access to macOS APIs.

Apple Vision Framework for OCR. PDFKit for rendering. Core Image for filters. FSEvents for file watching. These aren't available in a browser — and the web equivalents are dramatically worse.

Performance on large files.

Processing a 500-page PDF in a browser means fighting the main thread. In a native app with Rust doing the heavy lifting, the UI stays responsive regardless.

What I'd reconsider

Distribution is painful.

Web apps ship instantly. Native apps need code signing, notarization, DMG packaging, and a manual update mechanism. I'm currently not code-signed (below the Apple Developer Program revenue threshold), which means users see a security warning on first launch.

No cross-platform.

Mac-only means I'm leaving Windows and Linux users behind. Tauri supports all three — but the macOS-specific APIs I rely on (PDFKit, Vision, FSEvents) don't.

Discovery is harder.

The App Store has an algorithm. Gumroad does not. Getting found requires active marketing, which takes time away from building.