alt Hacker NewsI 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.
Replies
> 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.
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.
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.
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.
> 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.
[flagged]
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.