If HTML engines are better than native UI libraries at rendering rich text, possibly the hardest thing UIs need to render, why would I not also use it to render easier things like buttons or text fields?

Also, OS X rendered its UI with DisplayPDF/Quartz for the longest time.

OP thinks "native" = only using Swift/ObjC primitives

WebKit is cheating I guess? Because it exists on other platforms?

Might as well use Java

> Using WebKit to render Markdown seems completely appropriate.

It doesn't? Needs an explanation.

But why would you expect to use WebKit to render rich text? If using an HTML/CSS/JS renderer to render text is "completely appropriate", what isn't appropriate for it? Why would you not render everything with it?

I don't understand how you go from "rendering text is completely appropriate" but then "rendering everything is ridiculous".

Yeah, this is actually my current in-progress solution: render the final Markdown & the streaming through WebKit.

And yes, I agree: on macOS, WebKit is a native OS framework. In that sense, it is "native". But I think it also supports the broader point I was making: if you want to work with rich text, Markdown, selection, typography, and long-form formatted content properly, web technologies quickly become the only viable option. I am not saying that using WebKit for a Markdown view is wrong. Quite the opposite, it is probably the most reasonable option available. The problem is that the "native" solution here is still effectively a web-rendering solution. There is a cost. Each `WKWebView` brings a WebKit engine with its own performance & memory overhead. So you cannot just sprinkle `WKWebView` everywhere & pretend it is free native macOS component as any other. My frustration is mostly that this is the answer. For this kind of UI, SwiftUI / AppKit / TextKit still do not give you a clean, modern, composable path that feels better than "just use WebKit".