Why We Built Brow in Swift, Not Electron

Your favorite Mac apps are secretly web browsers

Open Activity Monitor on your Mac and look at the memory column. Chances are some of your most-used apps are each consuming 300 to 500 megabytes of RAM. Slack, Discord, Notion, VS Code, 1Password, Figma — they all share a secret. They aren't really native Mac apps. They're web pages wrapped in a framework called Electron, and each one bundles its own copy of the Chromium browser engine to render what is essentially a website on your desktop.

Even some tools that market themselves as fast and native use web technology under the hood. Raycast, one of the most popular Mac launchers, renders its UI with web views. It feels fast, and credit to their team for that, but the underlying technology is still HTML, CSS, and JavaScript running inside a browser engine. We wrote a detailed comparison of Brow and Raycast if you want the full breakdown.

When we started building Brow, we made a decision on day one that would shape everything: zero web technology. Pure Swift. Native SwiftUI. No Chromium. No JavaScript. No compromise.

The real cost of Electron

Electron is popular for a good reason. It lets developers write one codebase in JavaScript and ship it to macOS, Windows, and Linux simultaneously. That's a massive advantage for cross-platform apps. But it comes with costs that users pay every single day.

Memory. Each Electron app ships with its own copy of Chromium. That means each app starts at roughly 150 to 200 megabytes of RAM just to display its first screen. Run Slack, Discord, Notion, and VS Code at the same time and you've got four separate Chromium instances consuming well over a gigabyte of memory before you even do anything. On a MacBook with 8 or 16 gigabytes of RAM, that's a significant chunk gone to overhead.

Startup time. Chromium isn't a small engine to initialize. Electron apps typically take one to three seconds to become usable. For a chat app, that might be acceptable. For a launcher or clipboard manager you invoke dozens of times a day, that delay adds up fast.

Battery. Chromium was designed for rendering complex web pages, not lightweight desktop UIs. Its rendering pipeline, JavaScript engine, and process model all consume significantly more energy than native frameworks. If you've ever wondered why your MacBook battery drains faster than expected, check how many Electron apps you're running.

It doesn't feel like a Mac app. Electron apps look close to native, but they never feel quite right. Scrolling physics are slightly off. Text rendering is different from the rest of the OS. Standard macOS keyboard shortcuts sometimes don't work. Drag and drop behaves oddly. Context menus look foreign. The details are small, but they accumulate into an experience that always feels just a little bit wrong.

What native Swift gives us

We built Brow with Swift, SwiftUI, and The Composable Architecture. Here's what that means in practice.

Performance that you can feel. Brow launches in under 100 milliseconds. Not one second. Not two seconds. Under 100 milliseconds. It uses approximately 50 megabytes of RAM at idle. Compare that to the 300 to 500 megabytes an Electron app needs just to show its main window. When you invoke Brow's launcher with a keyboard shortcut, it appears instantly. There's no loading spinner, no white flash, no moment where you wonder if the shortcut actually worked. It's just there.

A genuinely native experience. Because Brow uses SwiftUI, every animation is hardware-accelerated through Core Animation and Metal. Scrolling matches the rest of macOS exactly. Keyboard shortcuts follow Apple's Human Interface Guidelines. Drag and drop works the way you expect. Window management and clipboard history respect the system conventions. On macOS Tahoe, Brow supports Liquid Glass effects natively because it uses the same UI framework Apple provides. You can't get Liquid Glass in Electron.

Deep system access. This is the big one. Brow's notch integration — the feature that turns the dead space around your MacBook's camera cutout into a functional dashboard — is only possible because we're native. The notch area isn't accessible to Electron apps. Apple doesn't expose that screen region to web views. The same goes for menu bar management at the system level, the low-level system monitoring APIs that let us read CPU temperature and fan speed, battery health data from the SMC controller, display control through DDC/CI protocols, and XPC services for privileged operations like adjusting charge limits. None of these are available through a web browser engine. Going native wasn't just a performance choice. It was a capability choice.

Battery life. Native apps use Apple's own power management frameworks. When Brow is idle, it consumes nearly zero energy because the system knows exactly how to suspend and resume native processes efficiently. There's no Chromium process sitting in the background burning through your battery. On a MacBook Air, this difference alone can translate to an extra hour or more of battery life compared to running several Electron-based productivity tools.

Security. Brow processes everything locally. There's no web rendering engine interpreting remote code, which eliminates an entire class of attack vectors. No cross-site scripting. No remote code execution through browser exploits. The attack surface is dramatically smaller than any Electron app, and all of Brow's data stays on your machine.

The trade-offs we accepted

We believe in being honest about trade-offs, so here they are.

Development is slower. Building in Swift and SwiftUI is genuinely slower than building with web technologies. The web ecosystem has decades of libraries, patterns, and tooling. React can get a complex UI on screen in hours. SwiftUI sometimes takes days for the same result, especially when working around its rough edges. We accept this because the end result is better for users, but it means Brow's development pace is measured and deliberate rather than breakneck.

macOS only. Brow will never run on Windows or Linux. If we'd chosen Electron, we could port to other platforms relatively quickly. But that's a trade-off we make by design, not by accident. Brow is built to be the best possible experience on macOS. Trying to be cross-platform would mean giving up the deep system integrations that make Brow special. We'd rather be exceptional on one platform than mediocre on three.

Smaller ecosystem. The npm registry has over two million packages. The Swift package ecosystem is a fraction of that size. Sometimes we have to build from scratch what a JavaScript developer could install with a single command. This adds time, but it also means we control every dependency and understand exactly what code is running in our app.

SwiftUI is still maturing. Apple improves SwiftUI significantly every year, but it still has gaps and unexpected behaviors. Some layouts that are trivial in CSS require creative workarounds in SwiftUI. We occasionally hit framework bugs that force us to drop down to AppKit. That's the reality of building on a framework that Apple itself is still actively developing.

You can feel the difference

Trade-offs and all, choosing native Swift was the right call. You don't need to read a blog post to understand why. You just need to use Brow for five minutes.

Open the launcher. Notice how it appears the instant you press the shortcut. Scroll through your clipboard history. Feel how the animations track your finger perfectly. Check your system stats in the notch. See how the CPU graph updates smoothly without any jank. Tile two windows side by side. Watch them snap into place with a native spring animation, not a CSS transition pretending to be one.

Brow feels like it belongs on macOS because it is macOS. It's built with the same frameworks, the same rendering engine, and the same design language as the operating system itself. There's no translation layer. No abstraction. No web engine pretending to be something it's not.

655 Swift files. Zero JavaScript. Zero Chromium. That's Brow.