Know Where the Seam Is

The assumption underneath the reaction is that choosing Electron means you didn't try. That you reached for the easy thing instead of doing the work.

Artem Loenko is a macOS and iOS developer with twenty years on the platform. He had the reaction too. And then he spent weeks trying to build a simple chat interface with Markdown support in pure Swift — and discovered something important about where ideology ends and material reality begins.

i · the work itself tells you

He started in SwiftUI. Reasonable performance, acceptable for simple screens. But you can't select a whole Markdown document built from SwiftUI primitives. By design.

So he moved to NSTextView. Lost the SwiftUI performance work — they don't play well together. Then tried to stream text into it, because it's 2026 and everything streams now, and hit CPU spikes. Moved to NSCollectionView — mature, battle-tested. Cells blinked no matter what. By design.

He dropped to pure TextKit 2. Performance was okay. Streaming was still terrible. He removed SwiftUI completely. Fought expanding text chunks manually. Hit the wall of feature parity: context menus, dictionary lookup, accessibility, all the small things users expect without thinking about them — months of work just to reach baseline macOS behavior.

WebKit worked pretty well. Then Electron worked amazingly well.

Text selection, Markdown rendering, good typography, streaming — all out of the box. The performance he couldn't extract from his native TextKit implementation came free.

This is not a story about a shortcut. This is a story about a craftsperson who knew his material well enough to find the seam.

ii · what a seam is

In woodworking, a seam is where two pieces meet — where grain runs differently, where the material's behavior changes. An inexperienced builder pretends seams don't exist, or tries to muscle through them. An experienced one maps the seam first and designs around it.

Every tool has seams. Places where it stops serving you. Places where its design assumptions diverge from your problem's requirements. You don't find these by reading documentation or watching conference talks. You find them by pushing.

The native-vs-web debate is usually conducted as an ideological argument: quality versus compromise, craft versus convenience. But it's not really about ideology. It's about terrain. The question isn't "which philosophy is correct?" It's: where, specifically, does this tool's design start fighting my problem?

Loenko found out. Apple's native text stack is well-designed for a lot of things. Rich text, Markdown rendering, streaming, complex selection — that's where the seam is. Web rendering handles this better, and it's been doing it longer. That's not a philosophical failure. It's a material fact.

iii · the cost of not finding it

The dangerous version of "native all the way" is the version where you never hit the wall. Where you ship things that work on simple screens and conclude you understand the platform. Where the seam exists but you haven't found it yet, so you defend the territory confidently.

This is how dogma forms. Not through laziness — through incomplete exploration.

Expertise has a seam too. Twenty years of native development gave Loenko the skills to push the platform hard enough to find the limit. That same expertise, in someone who had never gone that far, would look like the same confidence while actually being unexamined received wisdom. The difference between expertise and dogma is whether you've been to the edge.

The "Oh, it's Electron again" reaction often comes from people who haven't hit Loenko's walls. They're defending a principle they haven't tested at the exact scale where it breaks. That's not wrong — you can't test everything. But it means the reflex is borrowed confidence, not earned knowledge.

iv · alignment over force

When you're fighting your tools — spending days on blinking cells, weeks on text selection, months approaching feature parity with baseline behavior — that friction is information. Not about your skill level. About the terrain.

When effort stops converting to results, that's not a signal to work harder. It's a signal that the approach needs to change. Alignment over force: position so reality carries the work forward. The friction is the material telling you where the seam is.

Loenko didn't compromise his principles by going to Electron. He demonstrated them. He had enough experience to recognize when effort had stopped converting to results, and enough integrity to let that recognition matter. He moved when moving was the aligned thing to do.

That's harder than it sounds. Identity is sticky. He's a native developer. The community reaction to Electron is something he'd shared. Changing course meant admitting the seam was real — not just for this project, but for anyone building this kind of interface on this platform.

The move wasn't capitulation. It was precision.

v · build once, use forever

Once you've found a seam, you know it. Forever. It becomes part of your map.

Loenko now knows that Apple's native text stack is the constraint, not the solution, for rich text chat interfaces. Every future architecture decision involving this problem starts from that knowledge. He doesn't re-litigate it. He designs around it.

The weeks he spent hitting native walls weren't wasted — they were the price of a durable, reliable understanding of the terrain. The dead-end was the education. This is what "build once, use forever" means in the context of hard-won knowledge. Not just code — insight. Permanent capability, carried forward.

The inverse is also true: if you never push your preferred tools to failure, you're working with an incomplete map. You'll defend the wrong thing at the wrong time. You'll spend the months yourself, eventually — or worse, you'll avoid the problem and ship something that quietly doesn't work, forever.

vi · find your seam before you need it

The practical takeaway is this: run your tools to failure before the project depends on it.

Not as a formal exercise. As a practice. When you're evaluating a new platform, a new stack, a new architectural pattern — push it toward its edge. Build the hard thing. Stream text. Handle complex selection. Try the interaction pattern that lives at the frontier of what the tool was designed for.

You're not trying to disqualify every tool. Most tools do most things fine. You're trying to know, specifically and reliably, where the seam is — so that when the hard problem appears, you're navigating with a real map instead of ideology.

Loenko's article ends with a clear observation: most new chat-heavy apps are web-based, and there's no real native alternative. That's not a trend story. It's a material fact that twenty years of native experience helped him see clearly.

He went to the edge. He found the seam. Now he knows where it is.

That's the work.