The ‘Native’ Trap: Why macOS Developers are Quietly Returning to Electron
Table of Contents
The Performance Paradox of Modern Apple Development
For years, the prevailing narrative in the Apple developer community has been a strict dichotomy: go ‘native’ for performance and polish, or use frameworks like Electron and React Native for speed of development. The latter has long been dismissed by purists as ‘bloatware’—apps that consume excessive RAM and feel detached from the macOS ecosystem.
However, a growing sentiment among veteran engineers suggests that Apple’s modern native toolkits, specifically SwiftUI, may be creating a new kind of bottleneck. It is no longer just a question of memory usage, but a struggle with basic interface patterns that have existed in computing for decades.
The friction becomes most apparent when developers move beyond simple forms and static screens. In a recent candid account from a developer with two decades of experience in the macOS and iOS ecosystems, the attempt to build a relatively simple chat interface with Markdown support became a descent into technical frustration. The goal was straightforward: a performant chat window where users could select and interact with rich text.
The SwiftUI Ceiling
SwiftUI was marketed as the future of declarative UI on Apple platforms. For most apps, it is an efficient, elegant way to build interfaces. But as the developer noted, when a project requires complex text manipulation—such as selecting a whole Markdown document built from SwiftUI primitives—the framework hits a wall. By design, these primitives do not always support the granular text selection behaviors that power users expect from a desktop operating system.
The natural response for a seasoned developer is to drop down into AppKit or TextKit 2. But this transition is rarely seamless. Mixing the modern declarative world of SwiftUI with the imperative, legacy world of AppKit often results in a fragmented codebase where performance gains in one area are offset by instability in another.
The developer’s experience highlighted a specific modern pain point: streaming text. In an era of LLMs and real-time AI responses, apps need to stream text into the UI without causing CPU spikes or visual flickering. While TextKit 2 offers a theoretical path forward, the practical implementation often requires fighting the framework to manage expanding text chunks manually—a task that should be trivial in 2026.
The Pragmatism of the ‘Dark Side’
After exhausting native options—from NSCollectionView to pure TextKit prototypes—the developer found that the most reliable solution was to move toward WebKit and eventually Electron. The irony is that the very tool often mocked for being ‘non-native’ provided out-of-the-box support for the exact features that Apple’s native SDKs made difficult: flawless typography, robust Markdown rendering, and intuitive text selection.
This shift highlights a critical reality for the current generation of software. We are in an era of ‘chat-heavy’ interfaces. Whether it is a coding assistant, a customer support portal, or a messaging app, the primary interface pattern is long-form rich text. When the native SDKs of a platform become a constraint rather than an advantage, the business logic dictates a shift toward the web stack.
A Shift in the Native Debate
This is not an argument that Swift or SwiftUI are ‘bad.’ For performance-critical logic and simple UI layouts, they remain industry-leading. However, the gap between what Apple provides as a ‘primitive’ and what a professional-grade text editor requires has widened.
As more startups and established companies lean into AI-driven interfaces, the reliance on Electron may not be due to developer laziness, but rather a calculated response to the limitations of current native rendering models. Until Apple bridges the gap between the ease of SwiftUI and the power of legacy text systems, the ‘dark side’ of web-based desktop apps will likely remain the most pragmatic path for developers who actually need their text to work.
