Native and Electron apps can both be excellent, but they make different tradeoffs. A native Mac app is built directly on Apple’s frameworks and conventions. An Electron app ships a web application with Chromium and Node.js so one codebase can run across desktop platforms. For ZenMail, native Swift was the right choice because email depends on deep Mac integration, precise keyboard behavior, secure local storage, and fast access to synchronized data.
What is a native Mac app?
A native Mac app is written for macOS using technologies such as Swift, SwiftUI, and AppKit. Its windows, menus, controls, text input, accessibility tree, notifications, and system services connect directly to the platform.
Native does not mean every pixel must come from one framework. Many excellent Mac apps combine SwiftUI and AppKit, and an email client may use WebKit to display complex HTML messages safely. The defining question is whether the application itself is designed around macOS.
What is an Electron app?
Electron packages Chromium, Node.js, and a web application into a desktop app. It gives product teams one familiar stack across macOS, Windows, and Linux, with access to a large web-development ecosystem.
That tradeoff can be valuable. Cross-platform teams can ship features consistently, reuse code, and reach more users with one product organization. Popular applications prove that Electron can support sophisticated, polished software.
Where users notice the difference
Windows, menus, and keyboard focus
Mac users expect menu-bar commands, standard shortcuts, predictable focus, undo, drag and drop, and windows that behave like other Mac windows. Native frameworks provide those conventions directly. Electron apps can recreate them, but the quality depends on careful platform-specific work.
Memory and background processes
Electron includes a browser engine and typically runs several processes. Native apps can start from a smaller platform-specific foundation. That does not guarantee lower memory use: a poorly designed native app can consume more resources than a disciplined Electron app. Activity Monitor and real workloads are more useful than assumptions.
Accessibility and text input
Email is full of lists, rich text, keyboard navigation, selection, and focus changes. Native controls begin with macOS accessibility and input behavior. Web-based interfaces can also be accessible, but they need deliberate testing across the browser layer and desktop shell.
Operating-system integration
Keychain, notifications, share services, background scheduling, file access, menus, and system settings are central to a mail client. Native code reaches those capabilities through Apple’s APIs without translating the main interface through a web runtime.
Why ZenMail is native
ZenMail is built with SwiftUI and AppKit, backed by a native Swift mail engine. The architecture supports the product’s most important behaviors:
- Immediate keyboard routing for triage, compose, reply, snooze, and navigation.
- OAuth credentials stored in macOS Keychain.
- Local Gmail caching and persistence for fast, offline-capable access.
- Native windows, menus, notifications, and account settings.
- Optimistic actions that update the interface before network synchronization finishes.
- One protected WebKit surface for sanitized email HTML.
The result is not “native” as a marketing sticker. The architecture follows from the job ZenMail is designed to do on the Mac.
Why email HTML still uses WebKit
Real email contains HTML, inline images, tables, quoted replies, newsletters, and unpredictable formatting. WebKit is the right rendering engine for that content. ZenMail sanitizes message HTML, then displays it inside a constrained web view while keeping the surrounding application native.
This separation gives each technology a focused job: native Swift for the product and WebKit for web content.
When Electron is the better choice
Electron can be the rational choice when a product must reach macOS, Windows, and Linux quickly; when the team is strongest in web technologies; or when cross-platform visual consistency matters more than deep platform conventions.
Architecture should serve the product. A collaborative app with identical workflows on every operating system may choose differently from a Mac-only email client.
How to judge a desktop app
- Does it open and respond quickly on your Mac?
- Do keyboard focus, menus, drag and drop, and text editing behave predictably?
- Does it remain stable with your real account and data volume?
- Can you understand where sensitive data and credentials are stored?
- Does it work well with notifications, accessibility tools, and system settings?
- What does Activity Monitor show during the work you actually do?
Those questions reveal more than a framework label alone.
The choice behind ZenMail
ZenMail is a Mac-only Gmail client, so we chose the architecture that lets us go deepest on the Mac. Native Swift gives the keyboard, local state, security, and system integration a common foundation. Read why we built ZenMail for the product philosophy that sits on top of that foundation.
