It makes sense when the editor is a core feature of your paid product. I understand the sentiment.
But is not it strange that I would need 8 months & a "development is ongoing" mindset just to render Markdown (which is very secondary to the main app features, and mostly just a user convenience people expect in 2026) with a custom low-level solution, effectively playing hardcore engineer instead of building what I actually want to build?
Anyhow, my point is not that "it is impossible". My point in the article is that I understand why people choose web technologies over native for such things. They want to build products, not fight the system’s limitations.
Rendering text beyond ASCII is famously difficult to do; rendering formatted text is sometimes difficult to even make sense of (e.g. what should a style change in the middle of an Arabic word do? how about a selection boundary being moved with arrow keys?); rendering honest-to-goodness Markdown, which can technically include arbitrary HTML tags, is nowhere in the vicinity of a small project.
None of which is to say that you shouldn’t demand that a toolkit solve it for you, only that I understand why the RichEdit control reportedly had a separate team allocated to it in turn-of-the-millenium Microsoft. Working with a large amount of formatted text feels like it should be the most complicated feature of any UI toolkit and I shudder at the thought of even designing the API for it.
(A web browser is good at all this. It also has the API surface of a web browser.)
And some things will still be on you regardless. Did you know Android has two modes for text wrapping, one that won’t reflow the entire paragraph after a single-word change at the end and a different one whose results embarrass a typographer from half a millenium ago? That’s very much the correct way to do things, but if you’re streaming text in, it’s on you to decide whether you want subpar wrapping throughout or a layout jump whenever a paragraph break arrives. Most importantly, it’s on you to know the question exists; there are more, some more important than this one.
(Modern toolkits aren’t the only ones that can be bad at scaling to large amounts of data, either. Notably, Microsoft had to write an entire new “windowless” one to replace USER’s heavyweight window-based one so that Access wouldn’t collapse under its own weight. They then reused it for IE, for similar reasons. Raymond Chen’s response[1] to complaints about that toolkit staying private to Microsoft amounted to “fuck off”.)
You're assuming the text editor component alone took 8 months, but of course it did not! That would be crazy. There's a whole app built around the text component, which is what took my time, and the reason people are buying the app.
Development is ongoing for the features around the text component. I added folding lists which took a while, and because I offer outliner features I added focus/hoist which was also quite complicated.
Performance profiling and adjustments were measured and solved when I was almost done, because premature optimisation is a bad idea.
I don't consider what I did fighting any sort of limitations, so I guess it's a point-of-view thing. I wanted to use system components, and the only way to do that whilst maintaining performance is to do it with due care and attention. Nothing comes for free.
Nothing comes for free, but OP’s entire point is that the price to pay for even halfway decent native markdown rendering is too high - and thus a reason why people often give up and go to Electron.
They could not have made their point more clearly but people like you are up and down the thread wanting to call “skill issue”. The reality is that nobody gives a shit and they want to ship interesting things fast; if OS makers won’t get the hell in line and offer APIs to do it, then these developers are going to just pick Electron.
Life is way too short to sit down and write half a damn text editor when all you wanted to do was shit out a basic application with blobs of markdown.
So now it's personal and I'm the bad guy because I happened to have already done what the OP says is not possible? Deeply uncool.The price is not high at all, and it's not an opinion or theory because I've proven it by shipping an app. The OS makers already offer "APIs to do it" and, as with any type of component or framework, if you bend it the wrong way you'll get bad results. If you abuse Electron you'll also get bad performance there, it's no silver bullet. This is not ground-breaking information, just common sense.
It's not personal, but yes, you're being intentionally obtuse to OP's point.
> and it's not an opinion or theory because I've proven it by shipping an app
You are once again downplaying the level of effort difference that OP is describing, thus missing the point entirely.
> if you bend it the wrong way you'll get bad results
OP did not bend it the wrong way, they tried several different approaches because it wasn't working as intended off the bat (i.e, without bending).
OP's point was never that things were "not possible", it's that it's a stupid amount of effort for table-stakes functionality. If you don't get that point by now then I don't think you'll get it at all.
I'm not being obtuse, on the contrary I am bright and focussed enough that my experience building an app around TextKit 2 was opposite to the premise of the OP. It's a few lines of code to add a TextKit2 component to an app, and it just works. It is what the developer does with it afterwards that will make or break it. The same goes for Electron, it is not a panacea. That's just software development, the developer is responsible for the code they write.
So the reader is free to accept my story about my shipped app and my assurance that it didn't take unreasonable effort, or accept a blog post complaining how difficult things are that has no code or shipped app at the end of it.
Judging by the color of the text on your comment (currently downvoted gray), I think it's pretty clear how readers are taking it. I would encourage you to take a wider view of the problems in the UI ecosystem and why people make tradeoffs like they do.
The comment has one downvote. The wider view is that TextKit 2 works out of the box and its up to the developer to mess it up, or not. I made an app using it, quite easily, it's selling very well, thanks! No tradeoffs needed.
Not to turn this into an AI debate, but it will only take 8 months if you insist on coding manually.
I'm doing little video utility apps that I never would have attempted a year ago, because I know the challenges of AVFoundation all too well. But if I don't have to actually write that plumbing? Sure.
It took me "8 months" because I had another job for part of that time, so I wasn't working on my apps for all that time. At the start of this year, I decided to tidy up the app for release...along with 20 others. https://news.ycombinator.com/item?id=47809151
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.
totally. the there's a lot complexity that adds up to the overall performance issues. and TextKit 2 IS pretty bad at things. especially public API is pretty bad - that result in my case need to workaround things that I should've not. I agree with the general sentiment et all. I also still believe there is a place without bringing the whole browser machine to render text, and have text under control - but without relying on the "TextKit" level. That's the next thing I'm researching right now.
Do not know about "forever", at the moment it works okay, I guess. But for a long long time most of the iOS apps were using this https://github.com/TTTAttributedLabel/TTTAttributedLabel to have proper support for links & other basic attributes.
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.
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".
> 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.
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.
`NSTextView` is good. My point is not that `NSTextView` itself is bad. The problem is that once you are working with all the "modern" Apple stack (Swift, SwiftUI, and the direction Apple is clearly pushing developers towards) `NSTextView` does not fit as naturally anymore. Some newer APIs are not even available for AppKit now, so you quickly end up in an awkward middle ground.
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.
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.
This is me. I use Safari’s Reading Mode for almost everything, and for sites like Medium and similar platforms, it is enabled by default. There is something pleasant and calming about a consistent reading experience when consuming text content. Plus, Reading Mode supports basic customisations and follows the Light/Dark theme system, which some websites struggle with. It is not perfect, but it is familiar and easy to use. Recently, the Safari team improved it with an automatic Table of Contents, it preserves font, zoom, and theme selections across devices (works well for both macOS and iOS). The sepia theme is good enough to please my eyes. This is a fair assumption.
Many people I know use https://astro.build/ to create impressive landing pages for products or validation. It is fully static by default which is impressive.
Thanks for the app! I am curious about some of the design decisions on the iOS side. In your blog, you mention that “We truly believe a native Android & iOS experience stands out compared to non-native approaches, and we want to highlight that with HN,” but I noticed a few things:
- The app does not support Dynamic Type and instead uses steppers for font adjustments, which seem to stop at arbitrary values.
- It uses a custom web view for link previews.
- In many instances, it ignores safe areas.
When you say “native,” do you mean it is written in Swift, or is there more to it?
But is not it strange that I would need 8 months & a "development is ongoing" mindset just to render Markdown (which is very secondary to the main app features, and mostly just a user convenience people expect in 2026) with a custom low-level solution, effectively playing hardcore engineer instead of building what I actually want to build?
Anyhow, my point is not that "it is impossible". My point in the article is that I understand why people choose web technologies over native for such things. They want to build products, not fight the system’s limitations.