A 20-year macOS/iOS veteran finds SwiftUI, AppKit, NSTextView, and TextKit 2 all break down for streaming Markdown chat UI, leaving WebKit or Electron as the practical path.
Key Takeaways
SwiftUI blocks cross-component text selection by design; NSTextView fixes selection but breaks SwiftUI performance and testing infrastructure.
Streaming token output into NSTextView or TextKit 2 causes CPU spikes and blink artifacts in NSCollectionView cells, both by design.
WebKit renders Markdown with good performance and typography and is already available as a native macOS framework.
Electron delivers text selection, Markdown rendering, Git diff views, and macOS integrations out of the box, outperforming a custom TextKit 2 implementation.
The author concludes SwiftUI is viable for simple screens but becomes a constraint, not an advantage, for long-form rich-text chat.
Hacker News Comment Review
Sharp disagreement exists on whether the problem is real: commenters point to swift-markdown-ui and its successor Textual as working SwiftUI Markdown renderers, though the author benchmarked Textual and reported p95 scroll latency of 59 ms against a 16.7 ms budget.
The Wowfunhappy/InsideOutSanta thread splits on scope: using WebKit for a Markdown view is considered reasonable, but using that as justification to replace the entire native stack with Electron is seen as a separate, much larger leap.
Qt/C++ and QML are cited as a counter-example where native outperforms web apps in RAM and speed, suggesting SwiftUI specifically, not native development in general, is the bottleneck.
Notable Comments
@simonw: asks the single sharpest qualifying question about all proposed SwiftUI alternatives: “Can those handle streaming in new text without flickering?”
@iamcalledrob: notes Apple itself historically used WebKit inside native NSTextFields to render rich text, framing the author’s conclusion as rediscovering Apple’s own prior solution.
