[msephton]

I recently launched a text editor for iOS that uses TextKit 2 and is highly performant with files of 5,000 lines (I tested with Moby Dick from Project Gutenberg). I made it between Aug 2025 and Apr 2026, development is ongoing.

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.

https://www.gingerbeardman.com/apps/papertrail/

[dive]

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.

[mananaysiempre]

> just to render Markdown

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”.)

[1] https://devblogs.microsoft.com/oldnewthing/20050211-00/?p=36...

[mananaysiempre]

> a different one whose results embarrass a typographer

whose results won’t embarrass (of course; sorry)

[msephton]

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.

[Klonoar]

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.

[msephton]

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.

[Klonoar]

> So now it's personal and I'm the bad guy

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.

[msephton]

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.

[bensyverson]

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.

[msephton]

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

[sandoze]

Having worked on an interactive novel in 2012 (NSString and attributes), low level glyphs (API deprecated) on a rogue-like, two chat apps (with markdown support for formatting) in SwiftUI, and an idle game using a mix of iOS tricks but all wrapped in SwiftUI.. I’m going to agree with how I summarized this response: skill issue.

[dataflow]

> I recently launched a text editor for iOS that uses TextKit 2 and is highly performant with files of 5,000 lines (I tested with Moby Dick from Project Gutenberg)

I'm so confused by this comment. 5,000 lines is an absolutely minuscule size. Even the file you tested with is longer than that -- I'm seeing > 22,000 lines in [1]. Even Window's built-in Notepad doesn't flinch when opening something that small.

Text viewers need to handle files that are two orders of magnitude larger, at least. I easily have JSON files that are hundreds of thousands of lines long, and CSV & log files that are even longer.

[msephton]

I'm going from memory here, time marches on never-ending, so please forgive me. I conflated two things: my performance test results are from the first 5,000 lines of Moby Dick. Why 5,000? One user has a 5,000 line taskpaper note file. But the whole 22,000 line book loaded and scrolled and edited just fine (after I fixed some bad assumptions that resulted in bad code). On iOS, I think if you're working on a file of 5,000 lines then something might be wrong, and if you're working on a file of 22,000 lines well I don't know what to say.

[dataflow]

I definitely need to edit files that are hundreds of thousands of lines once in a while. Nothing wrong with it, I think you're just assuming it's source code or such when it isn't. It's often data manipulation (CSV, JSON, etc.) and it feels like torture when the editor can't handle it. I've even opened multi-gigabyte text files in my editor and needed to edit them sometimes.

[msephton]

That's cool, understood. Whilst I don't think you would be using my app to edit those files, it could do it. Though I haven't tested the multi gigabyte size on iOS.

[basch]

Did you look at the app? It's a todo list. The idea of a multi gigabyte todo list makes me uneasy.

[msephton]

Good point! It's a plain text outliner, but i use it as for tasks/todo. Most features were added for people other than me!

[tnorthcutt]

> On iOS, I think if you're working on a file of 5,000 lines then something might be wrong, and if you're working on a file of 22,000 lines well I don't know what to say.

Some people use an iPad as their main at-a-desk/stationary computing device, so that might not be as much of an edge case as you'd think. But maybe it still is; maybe those people aren't prone to editing large text files.

[virgil_disgr4ce]

> If I can do it on iOS then it's must be 10x easier on macOS.

I strongly doubt this. I suspect it's the exact opposite situation. But I'd like to hear from someone who knows.

[msephton]

I stand by the claim. But what do I know? ;)

[KerrAvon]

It's likely the SwiftUI Mac implementation is subpar. SwiftUI-on-Catalyst might be a better choice for these applications, but it probably has other problems.

[dwroberts]

> 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.

Not trying to be unpleasant but these times are slow, right? 8ms is an entire frame at 120Hz, that’s an eternity

[msephton]

Are you basing this opinion on feeling or science?

This feels instant on iOS, and scientifically it's faster than almost all keyboards, which have latency between 15ms and 60ms: https://news.ycombinator.com/item?id=33817626 and the best computer latency was the Apple IIe at 30ms https://news.ycombinator.com/item?id=16001407 a network packet takes 190ms to go round the world, that's certainly longer but still not quite an eternity.

Also, you are of course free to do better :)

[dormento]

Congrats on shipping, OP!

> 8ms is an entire frame at 120Hz, that’s an eternity

While I agree in principle, do mind that this in on a mobile device. It may seem slow indeed, but I think this is somewhat mitigated by the fact that the performance of current Electron-based software lowered the bar a little bit, therefore it feels faster. If you spend your day using web-based stuff instead of native, it may certainly feel so.

[hombre_fatal]

Apple’s Journal app on macOS is a good example of falling standards for software over the years. There’s lag on every keystroke that grows the more you write. Eventually I will save the entry and start a new one because even cmd-a to select all will lag so much it seems like the app will crash soon. And nobody cares.