Why We Keep Building Native, Local-First Mac Apps in an AI-Cloud World

Three of our eight products are native macOS apps — Crisp (a menu-bar file compressor), Vitals (a system monitor), and Porter (a local network file transfer tool) — and all three share a property that's gone almost unfashionable: they don't talk to a server. No account, no sync, no API call on the critical path. Everything happens on the machine you're sitting at.

I want to make the case for this, because 2026 is the year every product pitch defaults to "and then it calls an LLM in the cloud," and I think that default is frequently wrong for the category of tool these three apps are in, and worth being loud about while the industry's attention is pointed the other way.

The privacy argument isn't marketing, it's the whole design

Vitals reads your CPU, memory, disk, and network activity continuously — that's the product. A cloud-first version of Vitals would mean streaming system telemetry off a user's machine to a server they don't control, for a feature (a menu-bar graph) that has no actual need to leave the device. We didn't choose local processing because "privacy" tests well in surveys, though it does. We chose it because sending that data anywhere would be a worse engineering solution, not just a worse trust posture — it adds latency, adds a failure mode (no internet, no monitor), and adds an entire backend for a problem that IOKit and sysctl already solve on-device, synchronously, for free.

Crisp compresses files locally with native codecs. The alternative — upload to a server, compress, download — is strictly worse on every axis that matters to the user: slower (network round trip vs. instant), less private (their files transit a server), and more fragile (works only with internet). The only reason to build it the cloud way is if we wanted the telemetry or the recurring revenue hook of a subscription tied to server-side processing. Users don't want that trade. We didn't build it.

The zero-infra economics, in real numbers

Here's the part that's underrated: local-first isn't just a UX and trust win, it's a cost structure that scales in the direction you want.

Crisp, Vitals, and Porter have a combined install base in the low tens of thousands, and our hosting bill attributable to the three of them is effectively zero — a static download page and a JSON manifest for update checks, both served off Vercel's free tier alongside our other static assets. Compare that to Wryte or envpilot.dev, where user count and Convex bill move together, which is the correct and expected shape for a backend-heavy product, but it's a shape you're stuck with. A local-first Mac app has no such curve. Ten thousand users or a hundred thousand, the marginal server cost is the same: zero. The app is the infrastructure.

This matters more to a five-person team than it would to a funded company with an infra budget line. Every product on our roster that doesn't need a backend is a product that doesn't compete for our Convex quota, doesn't need an on-call rotation, doesn't have a "what if traffic spikes" conversation. We've had exactly one infrastructure incident across three Mac apps in two years, and it was a code-signing certificate expiring, not a server falling over, because there was no server to fall over.

SwiftUI is finally the tool it was pitched as

I'll say the part that would've been a lie in 2021: SwiftUI is genuinely good now. Cross-window state management, the newer navigation APIs, Swift's actor model for the concurrency Vitals needs to poll system stats without blocking the UI thread — this stack does what the marketing said it would do, several OS versions later than promised, which is the normal timeline for a UI framework to mature and not a knock specifically on Apple.

The practical effect: Porter, our newest of the three, took a fraction of the calendar time Vitals took two years earlier for a comparable amount of native surface area. Not because the engineer was more senior — same person, mostly — but because the framework stopped fighting back. @Observable replaced a genuinely painful amount of ObservableObject boilerplate. The menu-bar extra APIs stopped requiring AppKit escape hatches for basic things. This is the unglamorous, compounding kind of platform improvement that doesn't make headlines but shows up directly in how many products a small team can maintain at once.

Distribution without the App Store

None of the three ships through the Mac App Store. This is the contrarian-but-defensible take of this whole post: for a certain shape of utility app, the App Store is worse distribution than the alternative, not just worse economics.

The alternative, which we use for all three:

Homebrew casks, for the audience that already lives in a terminal and trusts brew install more than a storefront. This is a meaningful fraction of Vitals' and Porter's install base — both are developer-adjacent tools, and developers install things this way by default now.

GitHub Releases with self-updating built in. Each app checks its own release feed and prompts the user when a new signed build is up — no 30% cut to Apple, no waiting on App Review for a bug fix that's already written and tested. A fix can be in users' hands within an hour of the build finishing; the same fix through the App Store would be a multi-day review cycle. We run three channels — stable, nightly, and dev — so people who want yesterday's fixes can have them without destabilizing everyone else.

Open source as distribution, not just ideology. Porter is open source, and its GitHub stars are a meaningfully larger acquisition channel for it than any paid marketing we've run for it. This isn't altruism dressed up as a growth hack — it's a real recognition that for a category of tool where trust is the entire pitch ("let this app read your system stats," "let this app move your files"), a public, auditable source tree is the single most credible thing we can offer, more credible than any privacy policy page.

The App Store still makes sense for products where discovery through search is the growth strategy, or where the audience isn't comfortable with brew install or a downloaded .dmg. For utility tools aimed at people who are already power users, we've found direct distribution converts as well and costs a third the friction.

The takeaway

The industry default in 2026 is "ship a backend, add an LLM, sell a subscription." That's the right shape for plenty of what we build — Wryte and envpilot.dev both need real backends, and I'd never argue otherwise. But for a specific, valuable category — tools whose entire job is doing something to the machine you're on — local-first isn't a nostalgia choice. It's the version with less latency, less attack surface, lower cost, and a distribution story that doesn't route through anyone's app review queue. We keep building this way not because we're romantic about it, but because for these three products, it's the version that's actually better, and being aware that it's unfashionable hasn't been a reason to stop.

---

Crisp, Vitals, and Porter are native macOS apps built by the Syntax Lab Technology team, distributed via Homebrew, GitHub Releases, and self-updating outside the App Store.