6 ms·

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 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/ https://www.gingerbeardman.com/apps/papertrail/

sandoze 5mo ago
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.
- itsthecourier 5mo ago
  [flagged]
satvikpendem 5mo ago
[flagged]
virgil_disgr4ce 5mo ago
> 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 5mo ago
  I stand by the claim. But what do I know? ;)
KerrAvon 5mo ago
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.
dive 5mo ago
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 5mo ago
  > 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=36473 https://devblogs.microsoft.com/oldnewthing/20050211-00/?p=36...
hombre_fatal 5mo ago
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.
dataflow 5mo ago
> 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 5mo ago
  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 5mo ago
    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 5mo ago
      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 5mo ago
      Did you look at the app? It's a todo list. The idea of a multi gigabyte todo list makes me uneasy.
dwroberts 5mo ago
> 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 5mo ago
  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 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 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 5mo ago
  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.

sandoze 5mo ago

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.

itsthecourier 5mo ago
[flagged]

satvikpendem 5mo ago

[flagged]

virgil_disgr4ce 5mo ago

> 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 5mo ago
I stand by the claim. But what do I know? ;)

KerrAvon 5mo ago

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.

dive 5mo ago

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 5mo ago
> 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=36473 https://devblogs.microsoft.com/oldnewthing/20050211-00/?p=36...

hombre_fatal 5mo ago

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.

dataflow 5mo ago

> 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 5mo ago
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 5mo ago
  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 5mo ago
    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 5mo ago
    Did you look at the app? It's a todo list. The idea of a multi gigabyte todo list makes me uneasy.

dwroberts 5mo ago

> 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 5mo ago
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 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 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 5mo ago
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.