The reflexive ‘Electron shame’ reaction needs a reality check
Ask a developer what they think of Electron, and the response usually comes before they even know what the app does. The framework carries a scarlet letter in technical circles — “bloated,” “un-Mac-like,” “lazy” — and native Swift or Objective-C development occupies the moral high ground almost by default. The argument rarely progresses past aesthetics and memory usage graphs.
That reflex deserves more scrutiny than it gets.
Artem Loenko, a macOS and iOS developer with nearly two decades of native development experience, is pushing back from inside the camp that would normally wave the native flag loudest. His critique isn’t the complaint of someone who reached for a web stack because it was familiar or convenient. He tried to do it the right way — pure Swift, pure SwiftUI — and documented exactly where Apple’s own frameworks stopped cooperating.
The task he set out to accomplish was not exotic. A chat interface with Markdown support. The kind of feature that ships in dozens of consumer apps and that users treat as completely unremarkable. What he found was that SwiftUI, Apple’s flagship modern UI framework, cannot perform basic text selection across a Markdown document built from its own primitives. Not “it’s difficult” or “there’s a workaround.” By design, it cannot do it.
That detail matters when evaluating the native-versus-Electron debate, because the debate almost always operates at the wrong level of abstraction. Critics of Electron are usually arguing about bundle sizes, RAM consumption, and scroll physics. Loenko’s argument shifts the question to something more fundamental: whether the native tools actually let developers build what users need. A native app that physically cannot select text across a document is not a win over an Electron app that can.
The critique lands differently because of where it originates. Dismissing Electron on principle is easy. Dismissing the same argument when it comes from someone with twenty years of professional investment in the native ecosystem requires actual engagement with the technical specifics — which is exactly what the reflexive reaction never bothers to provide.
SwiftUI’s dirty secret: it struggles with text
Artem Loenko has spent nearly twenty years building native macOS and iOS applications. When he tried to implement a chat interface with Markdown support in pure Swift and SwiftUI, he hit a wall that no amount of experience could help him climb over.
The problems started with the basics. SwiftUI delivers acceptable performance on simple screens, but introduce rich, dynamic text and the cracks appear fast. Jumpy scrolling. Layout inconsistencies. Lag that developers quietly rationalize as the cost of doing business. These aren’t edge cases — a chat interface with Markdown rendering is exactly the kind of feature users expect from any modern messaging app in 2024.
The deeper problem is structural. Build a Markdown document from SwiftUI primitives and users cannot select the whole thing. Not because of a bug waiting for a patch. By design. A framework Apple has been shipping and promoting for five years cannot support one of the most common interactions in text-heavy applications.
The obvious escape route is NSTextView, the older AppKit control that now supports TextKit 2. Experienced developers know this path. They take it. And then they discover they’ve traded one set of problems for another — most of the SwiftUI integration advantages disappear the moment you wrap an NSTextView inside a modern SwiftUI layout. You are no longer building a SwiftUI app with a text component. You are duct-taping two different UI paradigms together and hoping the seams don’t show.
This is the part of the native development story that rarely makes it into the “Electron is bloated” commentary. The criticism of web-based desktop apps is frequently valid. Electron apps do consume more memory, do ship a full Chromium runtime, and do feel disconnected from the platform. But the implicit argument — that native frameworks have solved the hard problems and Electron developers are simply making lazy choices — collapses when you try to build something as routine as a chat window with formatted text. Apple’s own tooling makes that surprisingly difficult.
Why this matters right now: AI chat interfaces have made rich text unavoidable
The timing of this problem could not be worse for Apple platform developers. AI chat interfaces have gone from novelty to ubiquitous in under two years, and they share one defining UI characteristic: streaming Markdown-rendered text. Every response from ChatGPT, Claude, Gemini, or Copilot arrives as a live stream of formatted content — headers, bold text, inline code, fenced code blocks — updating token by token in real time. That pattern is now one of the most common UI requirements any developer building in the AI space has to implement.
For web developers, this is annoying but solvable. For developers building native apps on Apple platforms, it exposes a structural gap that no amount of SwiftUI expertise papers over.
Artem Loenko, a macOS and iOS developer with nearly twenty years of experience, ran directly into this wall while building a Markdown chat interface in pure Swift and SwiftUI. His conclusion was blunt: the moment you step outside simple screens, Apple’s native frameworks are immature in ways that are almost funny. SwiftUI lets you render Markdown, but users cannot select across a document built from SwiftUI primitives — not because of a bug, but by design. The escape hatch is NSTextView, which supports TextKit 2, but switching to it means abandoning most of the SwiftUI layout model developers have built around.
This is not a hypothetical edge case. Any developer shipping an AI assistant app, a coding tool with streaming output, or a chat client that wraps an LLM API hits this problem in the first week of building. The entire product category depends on formatted, dynamically updating text as its primary interface. Apple’s frameworks, built in an era when the dominant text use case was displaying static content in a feed cell, were never designed for this.
The native-versus-Electron debate treats framework choice as a values question — performance and aesthetics versus developer convenience. The real situation is that developers building AI-adjacent apps on Apple platforms in 2024 and 2025 face a concrete capability gap inside the frameworks Apple actively promotes. The choice is not philosophical. It is practical.
What ‘native’ actually costs when the framework lets you down
Choosing native development carries a cost that rarely appears in the architectural decision meeting. That cost is workaround engineering — the hours spent compensating for gaps that Apple has not closed, sometimes after years of developer requests.
Artem Loenko, a native macOS and iOS developer with nearly two decades of experience, ran into this directly while building a simple Markdown chat in pure Swift and SwiftUI. The performance was acceptable. The platform integration was there. Then he tried to let users select an entire Markdown document built from SwiftUI primitives. The framework does not support it — not due to a bug, but by design. The feature is absent.
The logical next step is to drop down to NSTextView, which now supports TextKit 2. That move solves the selection problem and immediately creates new ones: most of the SwiftUI integration you built your interface around stops working. You are no longer writing a SwiftUI app with one tricky component. You are managing two separate paradigms inside a single product, with all the coordination overhead that creates.
This is the honest accounting that the native-versus-Electron debate skips. Native is not a single thing you choose once. It is a layered set of frameworks, and the quality of those layers varies enormously depending on what your app actually does. If your core feature — the reason users open the software — sits in a weak part of Apple’s stack, the performance wins and system integration benefits you chose native for get undermined entirely.
A cross-platform framework built on web technology ships its own text rendering engine. That engine has known costs: memory overhead, a larger binary, a runtime that doesn’t feel quite like the OS. It also has one specific advantage: it does not depend on Apple shipping a fix before your product works correctly. For teams building rich text, document editing, or anything that pushes past simple form inputs, that independence is not a consolation prize. It is a concrete engineering asset that belongs in the calculation.
What the debate gets wrong: it’s not native vs. Electron, it’s fit-for-purpose vs. dogma
The native-versus-Electron argument is a category error. It treats technology choice as a moral position rather than an engineering decision, and in doing so it lets the actual problem go unexamined.
The real question is whether a given framework can deliver the experience a specific application requires. For a simple settings panel or a menu bar utility, SwiftUI is fine. For a document editor, a chat client with Markdown rendering, or anything that asks users to select, copy, and manipulate rich text across mixed content, Apple’s own frameworks fall apart in ways that have no clean solution.
Artem Loenko, a macOS and iOS developer with nearly twenty years of experience, documented exactly this trap. He tried to build a straightforward chat interface with Markdown support using pure Swift and SwiftUI. SwiftUI could not support text selection across a document composed of its own primitives — not as a bug, but by design. Moving to NSTextView, the older AppKit control that does support TextKit 2, stripped away the SwiftUI layout and composition features he needed. Every path led to a dead end. That is not a developer skill problem. That is a platform gap.
When the industry’s response to that situation is to shame developers for reaching toward Electron or web-based rendering, it misdirects legitimate criticism. Developers who ship Obsidian, Slack, or Notion on Electron are not betraying some philosophical covenant. They are solving real problems that Apple has not solved. Blanket condemnation of non-native stacks gives Apple no pressure to close those gaps, because the conversation never clearly identifies that the gaps exist.
A more productive industry posture would hold Apple directly accountable. SwiftUI is six years old. TextKit 2 shipped in 2021. Rich text selection across mixed native content still does not work reliably. That is a specific, nameable failure with a specific, nameable owner. Developers routing around it are not the problem. The conversation that refuses to say so plainly is.
