alt Hacker News> But I still cannot make a simple thing work properly: a chat with Markdown & the ability to select a whole message.
Sorry, sounds like bullsh_t. One can leverage mature markdown renderers in SwiftUI. See https://github.com/gonzalezreal/swift-markdown-ui and its next gen replacement https://github.com/gonzalezreal/textual .
Used these myself and had no issues. And I am a moron who doesn't like Swift or SwiftUI - preferred Objective-C, but still managed to do this, without any LLM help.
Replies
Can those handle streaming in new text without flickering?
The first one is the Claude iOS app uses and it seems to perform okay and has the ability to select text and stream stuff.
Either you render the markdown document just once (not streaming) or your document is simple and short.
I used to use swift-markdown-ui for my app but the performance is nowhere near using a wkwebview. When streaming large documents with tricky elements like large tables, code blocks, nested quotes, you may even get beached ball. It never happened when using a wkwebview.
> > But I still cannot make a simple thing work properly: a chat with Markdown & the ability to select a whole message.
> Sorry, sounds like bullsh_t.
No... As a user, one thing I notice is that older, non-HTML-based apps don't seem to follow "the rules." Text that I should be able to select and push "control/option C" just isn't selectable, or copy doesn't work.
Then I realized that browsers (and everything based on them) introduced some new paradigms to UI that native UI frameworks just haven't kept up with.
(And I say this as someone who prefers native apps over web-based apps.)
I tried Textual earlier today with some not-so-good results:
- Static completed Markdown scrolling fails the new focused probe. Result: p95 18.86 ms vs 16.7 ms budget, max 232.49 ms.
- Long live Markdown/code update path also fails. Result: p95 59.33 ms vs 16.7 ms, max 75.94 ms. This is a separate but related stress case around large rich text surfaces during updates.
- Long-history scaling technically passes, but the numbers are not smooth-frame healthy: - 120 turns: total p95 21.35 ms - 500 turns: total p95 23.11 ms - 1000 turns: total p95 36.77 ms
Technically, it is not bad. However, it is a bit slower than my own solution & has similar performance gaps, mostly related to SwiftUI rather than the Textual implementation.