Native all the way, until you need text
Rendering rich, streaming Markdown in “native” desktop and mobile apps turns out to be far harder than many developers expect, especially on Apple’s modern SwiftUI stack. Commenters describe poor performance, awkward APIs, and brittle text components that push them toward embedding WebKit or going full Electron/Chromium, despite the memory overhead and non-native feel. The thread frames this as a trade-off between developer time and UX quality on one side, and resource efficiency and platform purity on the other, with many concluding that browser engines have simply received far more investment than native text toolkits.
Native rich text and Markdown are hard
- Many commenters report that “just” rendering and editing rich text/Markdown natively is far from trivial, especially with streaming updates (LLM chats, logs, long documents).
- Problems cited: slow layout, UI jank when text streams in, broken selection (e.g., selecting a whole chat message), and poor behavior with large documents or long histories.
- Several people stress that text layout with rich formatting, bidi languages, glyph shaping, and inline images is one of the hardest UI problems.
SwiftUI, AppKit, TextKit debates
- Some say AppKit / NSTextView / TextKit 1 are solid and performant, but integrating them cleanly into a modern SwiftUI app is awkward.
- TextKit 2 is described as powerful but “kinda broken” and hard to use correctly; others claim good results but acknowledge complexity.
- A recurring theme: SwiftUI is convenient but often slower and less flexible, especially on macOS; non-trivial or non-standard UIs frequently hit limits.
Electron, WebKit, and “native vs web”
- Many argue that embedding WebKit to render Markdown/HTML is the most pragmatic option on Apple platforms; WebKit is considered “native enough.”
- Others push back, saying that relying on a browser engine just to get rich text is perverse and undermines the point of native toolkits.
- Electron is framed as “the worst option except all the others”: heavy, memory‑hungry, but with a huge, battle‑tested text/layout stack and ecosystem, which explains its popularity.
Performance and memory trade‑offs
- Disagreement over priorities:
- One side: RAM is abundant; UX smoothness and developer time matter more than saving hundreds of MB.
- Other side: Electron/Web engines cause unnecessary hardware churn, paging on 8–16GB machines, and are still slower than well‑engineered native UIs.
- Some benchmarks and anecdotes show SwiftUI lagging vs AppKit or Qt; others claim modern SwiftUI can be fast if carefully optimized.
Tooling gaps and ecosystem alternatives
- Suggestions include Qt, JUCE, Slint, WebKit, litehtml, Rust and C++ renderers, and custom engines (e.g., block editors, VMPrint‑style layout).
- Several note that browsers/Chromium have had vastly more investment than native UI stacks, which explains their maturity in text rendering.
Meta: skill vs framework
- A strong “skill issue” chorus claims native APIs can do this if used well.
- Others counter that for many product teams, spending months building a custom editor instead of features is unrealistic, so web‑centric solutions win.