Every keystroke is restyled in under 8ms: no debouncing, no delayed rendering. 20 rapid keystrokes are processed in 150ms with full restyling after each one.
Tag and boolean searches complete in under 20ms. Visible-range rendering is 25x faster than full-document styling. 120Hz screen refresh supported.
App file size was 722 KB for 1.0, and 1.1 with more features is looking like ~950 KB.
If I can do it on iOS then it's must be 10x easier on macOS.
Browser rendering engines are pretty mature at this point, with significant GPU acceleration, and over a decade stress-testing by bloated web apps.
Meanwhile SwiftUI doesn't feel particularly fast. Apple's latest and greatest rewrite of System Preferences has dumbed down the UI to mostly rows of checkboxes, and yet switching between sections can lag worse than loading web pages from us-east-1.
[1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20...
The article you cited is from 2022 and so is irrelevant, since SwiftUI's performance profile completely changed as of xOS 26.
Claims like "It's hard to build a performant SwiftUI app" get into skill-issue territory, but more importantly, the reality is there are only "SwiftUI-first apps". All non-trivial SwiftUI-first apps will also use UIKit/AppKit as needed, typically for capabilties that aren't yet available via SwiftUI.
Their point is more that SwiftUI has generally poor performance. Lots of native Windows frameworks have poor performance as well.
Native UI development is a minefield. If you want to build an app today that will still run in 20 years without a complete rewrite in the UI layer you should probably use wxWidgets if you are committed to native - even if only targeting one OS. But that model is really only appropriate for building traditional desktop apps. I don’t think the market would accept a Slack or Notion built that way today.
Even so, there is a stark difference, even more so on low-powered devices, between native apps and even the lightest of browser apps. I'm traditionally a web developer, but started developing native cross-platform applications the last 6-12 months, and the performance gap is pretty big even for simple stuff, strangely enough.
They suck on older hardware. Old Chromebooks are a dime a dozen and are decently spec'd light use or purpose-use machines. Browsers run like crap on them.
Electron ultimiately sits on native APIs, and has its own performance costs on top of them.
That’s because SwiftUI isn’t particularly good, not because web rendering is as good as native. AppKit still runs circles around both, in performance and resource consumption.
Then the V8 team at Google just asked "well, what if we just made Javascript crazy fast instead?", and here we are. There's still room for native code in environments that don't map nicely to scalar scripting languages, but not a lot of room. Basically everyone is best served by ignoring that the problem ever existed.
It took the rendering side a little longer, but we're here nonetheless. There's still room for specialty apps with real need to exploit the hardware in ways not abstracted by the DOM (not 100% of it is games, but it's close to that). But for general "I need a GUI" problems? Yeah, just use Electron.
Now, if you're rendering everything with WebKit, that's ridiculous, in the same way rendering everything with PDFKit would be ridiculous. But for a Markdown view, WebKit seems like a logical choice. There's no need to subsequently flip the table and replace everything with a Chromium web app.
Also, OS X rendered its UI with DisplayPDF/Quartz for the longest time.
It doesn't? Needs an explanation.
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".
But, like, of course they are. This is what HTML was built for. The other major standard would probably be RTF, but it's a bit less structured, and so less close to Markdown. HTML is the better pick.
If you subsequently want to style that HTML, so that every second-level heading uses a specific font, and every third-level heading uses some other font, and so on, CSS is the best way to do that.
So, yes, we're saying the same thing, but to me it's a bit like saying "If you want to find the answer to 2 + 2, addition is the only viable option." Well, yes!
I think the reason this feels kind of wrong is because that same HTML and CSS renderer you're using for Markdown also comes with an entire 3D graphics pipeline and audio synthesizer. Obviously, we should be able to answer 2 + 2 without opening Mathematica.
I guess the important technical question is whether simply creating a WKWebView also loads in all that other stuff. I would hope and expect the OS is smarter than that, and you can call WebKit for simple HTML without everything else coming along.
But I think my opinionated point from the article still stands: if you need rich text & good typography without fighting the platform, then web technologies quickly become the pragmatic choice.
For my app, I will probably continue with WebKit. It is the most reasonable middle ground for now. But in this situation, it is tempting to jump to something with a stronger rendering engine, like Chromium instead of WebKit, and start using the huge ecosystem of tools that already work. For example, https://diffs.com is one of the most tempting parts for me. The awkward thing is that embedding WebKit & calling it a day does not feel like a clean native solution either. You lose many of the native things you get when rendering through SwiftUI primitives, but you also do not get the full power & ecosystem of a proper web stack. And that makes it much easier to understand why so many companies (good & bad) choose Electron.
From an engineering perspective, even the fact that you can avoid this controversial middle ground entirely & build the app around web technologies from the start makes sense. It is not just laziness or ignorance of native platforms. Sometimes it is simply the more consistent & logical architecture.
I don't understand how you go from "rendering text is completely appropriate" but then "rendering everything is ridiculous".
But WebKit is the native UI for HTML, and Markdown is intended to be transpiled to HTML.
Because rendering rich text correctly and consistently is one of the hardest problems in software. Bidirectional text, a million glyph shaping complexities, mixed content such as inline images and different text sizes, reflow that should take milliseconds, natural-feeling selection, etc etc.
No implementation comes even close to browser rendering engines in covering all of these.
It'd be very silly to render a shader pipeline in WebKit. You could, but with Metal sitting right there, it would be silly.
WebKit is cheating I guess? Because it exists on other platforms?
Might as well use Java
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.
- 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.
Old versions of macOS / AppKit used to use WebKit to render rich text inside their native NSTextFields. Turns out text is hard :)
And besides, the native WebView is super fast and lightweight, and its not unreasonable to use it as a text layout engine. You could use separate webviews for every row in a table and you'd still get fantastic performance.
iMessage for mac used to use a webview too. Adium as well. HTML is absolutely the right tool for the job if you're rendering rich/marked-up text.
1. Discover complex native text rendering is hard
2. Render text in a low-level way, complain about having to (re)implement native interactions
3. Try WebKit and it works great!
4. Throw WebKit away??
5. Have to re-implement native interactions??
Well yeah. If people don't invest sufficient effort in a thing why would there be an expectation for that thing to become mature? People are locked into web tech because that's where the greater majority of the effort has been going. Quite literally people look at native, say it isn't developed enough, and go develop for the web even more. Cycle repeats. Hardly anyone wants to put in the effort to improve native when things already "just work" for the browser.
I think SwiftUI etc al don't work on Linux and Windoes and Android, right? While HTML works?
I'm using what I learned to create a native LLM client with a streaming Markdown parser[2].
You can still use native controls for the rest of the UI and have 0 Javascript running. I'm not sure I understand what the problem with NSTextView was though. It's pretty performant as far as I can tell?
Not exactly sure what “streaming” text is, but serial terminal software has been handling incremental text rendering and updating for decades, without performance struggles.
By "streaming" text, I mean a formatted text stream that has to be parsed, formatted, and appended on the fly - basically how every model/AI chat works now. And this is where `NSTextView` becomes tricky. It forces an interesting architectural choice: either go deeper into AppKit with `NSCollectionView`, custom cells, manual layout, etc., or fight the whole SwiftUI model by embedding something like `NSTextView` inside `LazyVStack` / SwiftUI views & then dealing with all the integration problems.
So I am not saying Cocoa / AppKit was always bad, or that `NSTextView` is useless. I am saying that for modern chat-style UI with incrementally rendered formatted text, it does not compose well with the rest of the modern Apple stack.
Or well... since we now have Claude I might have a jab at this someday in my free time.
Both are actually lightweight HTML rendering libraries, so you need to compile markdown to HTML to use them. But there are many libraries for that.
litehtml appears to have no built-in text input support so far as I can see.
Not sure if my Sciter qualifies as a native solution.
Check this chat alike virtual list with MD items: https://sciter.com/wp-content/uploads/2026/05/virtual-list-m...
Yes, MD gets translated to DOM tree. But virtual list implementation in Sciter is a native thing. Load whole chat is not an option usually. Yes, JS is used in process but mostly as a configuration option: take output of one native function -> transform it -> pass as an input to other native function.
Essentially there is no so significant difference with any other SwiftUI/TextKit solution. It is just a difference in terms - SwiftUI uses tree of Views that is conceptually the same as DOM tree in terms of Sciter.
So I think the text view is pretty low level so that it can support this.
There’s really nothing else out there that competes with a similar performance and productivity.
This old article by the Missive team (the email client) convinced me.
https://medium.com/missive-app/our-dirty-little-secret-cross...
Agreed. In Chromium all the content from HTML is rendered inside a single object from the point of view of the host UI; much like a game engine’s UI rendering. Chromium draws everything itself. Host events like mouse and keyboard events are sent to that top level object (although there are some shenanigans involved to make it look more native to accessibility tools).
Skill issue, I guess. I even tried your SSTextView (which is a very nice piece of software, by the way), though it does fit here, but I tried to understand how wrong my TextKit2 implementation is. In my tests, the SSTextView performed a bit worse with p95 on the static markdown scroll test (70.20 ms vs 16.7 ms for per frame rendering). But it is clear from the traces that SSTextView just does too many things I do not need. At least, I had my confirmation that I am not completely wrong about TextKit.
Wayland is another product of this hardships, going wayland native seems only feasible when all stars align around it. But then you are stuck in that place.
That being said, without deeper knowledge about SwiftUI, I find it a bit odd to expect so much from a novel concept. Native desktop dev is already kind of niche, considering the dominance of web dev. Chrome (and it's artifacts) is probably the best funded software in the world and google's incentive to improve it is above all. It's not a miracle that it just works. It's effort and tons of cash.
This is a common misconception among programmers, and is actually the opposite of the truth. Drawing arbitrary geometric shapes is easy, rendering text correctly is insanely difficult because ... humans.
Like the OP mentioned, it's still surprisingly difficult to build what feels like a trivial interface using SwiftUI. Once you get into rich text, selection, streaming updates, syntax highlighting, diffing, or just smooth scrolling, you very quickly end up fighting the framework instead of building the app
Basic text styles are ok, but things like authored pagination, page header/footer, mirrored margins, margin notes, footnotes and references are basically unsupported or need to be hacked together.
But then, what’s the point in using an inherently laggy technique to save memory?
This is my pet project, a desktop app for working with xAI models & capabilities, so by "performance" I mostly mean "pleasant to use" (as it goes, simple & opinionated). Technically speaking, something like: stable FPS, no visible lags, and the ability to scroll smoothly while the model is streaming.
Regarding the parent comment: yes, memory is important, and I absolutely get the point. There should be a red line, for sure. But I will not sacrifice UX, productivity, and simple pleasure from using software just to save a few hundred megabytes of RAM (or even a few gigabytes) especially for an app I spend hours with behind the screen.
Memory consumption can & should be optimised with proper engineering for sure. As lags & inadequate performance in basic SDK-level primitives are much harder (impossible?) to fix from the outside.
What's the point of having 64-128GB of RAM if we're using apps that eat 10GB to do the same things we were doing 20 years ago using a few MB?
a fast performant incomplete solution will lose to a slow correct complete one
On most platforms it's quite easy to embed a browser in a frame (show a changelog, an email, or a page of interactive charts). With a few tweaks this can feel completely seamless.
It becomes really painful (or impossible) though, if you need those complex text rendering on multiple places scattered over the native UI. Or if the native UI should interact with the HTML somehow (drop-downs, edit text, add native controls inside html).
Thats why everyone is building Electron/etc apps.
I basically don't take SwiftUI too seriously for shipping apps. It's great for test harnesses and admin dashboards, but the apps I make for general end-users are [usually -There's one exception] done with UIKit (I don't do much Mac programming, these days, but AppKit works great, as long as you are willing to roll up your sleeves).
You can do a couple days to a week of reading to understand the fundamentals once and then you will actually know what you are doing.
It is not proper to choose things on “battle tested” or other meaningless words
And yes WPF is a framework native to the Windows platform ecosystem.
Fancy text rendering/editing is hard to implement when you leave the luxury of webviews.
I think this may be a misundertstanding of what SwiftUI is. SwiftUI makes it convenient to create apps that look and behave in a way that align with Apple's HIG using controls like `List`, `Form`, etc., but nothing makes you use any of those. For example, it's straightfoward to build a game engine on SwiftUI. https://blog.jacobstechtavern.com/p/swiftui-game-engine
And your users hate you and look for alternatives.
it’s disappointing to find out things have not improved with SwiftUI
Where is the profile? Where is the bottleneck?
Just complaining with nothing to contribute.
that's it, for everything else native UIs are complete garbage compared to HTML/CSS/reactive frameworks.
I remember spending 4 hours to make a scrollable element that wasn't jumpy or buggy. There were several stackoverflow answers full of gotchas explaining all you had to do. I finished and published the app but never again. Native stuff has terrible developer experience.
There are even parts of both Windows and MacOS rendered through HTML. If I remember correctly, at least in Windows 10, File Explorer was rendered through Internet Explorer.
Web rendering doesn't need to be only through Electron/Node. There are other libraries much more performant and lean (Dioxus, etc).
Not in the world of macOS and iOS at least. Here native apps still rule, as there's literally no performant alternative (the OP's complaints about Markdown are misplaced - there's been no interest in MD and SwiftUI and that's why there's no good option. But in ObjC/Swift there is).
In fact, most of the apps I am using on a day to day is native. The Electron apps I use are okay (e.g. Slack) but they absolutely fail the native Turing test.
the browser never chokes on html.
HTML/CSS/JavaScript looks fine for things where there's more style than substance but once we're talking about the desktop apps that engineers (no matter the discipline) are using, suddenly it's not so much HTML+CSS anymore or is it?
The browser is faster because they went native, in particular, GPU.
Every issue described is text rendering related. Everyone.
And I would bet most of the SwiftUI issues could be solved with a text render cache.
Something like Casey Murati's refterm toy that showed what that can do with no other optimizations, or the work for GPU accelerated terminal emulators like alacritty or ghostty.
