This is the key insight that makes TextKit2 workable. I personally would not attempt to build an alternative to UITextView on TextKit (1 or 2). Instead, TextKit2 is all about very sensible intervention points for customizing UITextView (eg, Markdown-style parsing, typography, interactions, layout).

I recently rebuilt Minimal’s editor with TextKit2 (see minimal.app/#beta to experience it), and found Kryzanowskim’s deep dives very fruitful. He explores the edges of the API, so his writing helped me identify a nice bounds of safe-space to work in, and helped clarify what areas are too complex to safely build custom functionality within. (So thank you, author!)

I would not dismiss TextKit2; it is an incredible improvement over TextKit1. It remains a complicated and challenging field.

I have to wonder if the scrollbar problem is inescapable, given the shape of the problem.

Flutter has dealt with similar issues, perhaps by virtue of more eyeballs / being slightly older, there are solutions. SuperSliverList in particular completely erased the jumpy-jank that happened when estimates changed to concrete values.

https://github.com/SuperSwiftMarkup/SuperSwiftMarkdownProtot...

It’s a good example of what else you can do with TextKit2, beyond plain text rendering. Here, I can draw text layout fragments in a core graphics context and use typographic information to also render markdown specific graphics in the background or foreground such as markdown tables. One day I’d love to experiment with a markdown centric spread sheet app.

At the time there was so little online info that I had to figure out everything on my own (and no chatbots didn’t have a clue about TextKit2), but STTextView was a great reference. Overall his open source work was very much appreciated. (I should probably say as much in the read me.)

That experiment was also a ton of work that ultimately didn’t go anywhere. Most people would rather just use a relatively subpar embedded browser (i.e. web view).

  > Today, I believe that's not me. The TextKit 2 API and its implementation are lacking and unexpectedly difficult to use correctly. While the design is solid, it proved challenging to apply in real-world applications.

I find the iron triangle of project management reins supreme in a lot of domains: quality is sacrificed in the name of performance.

[0] https://en.wikipedia.org/wiki/Project_management_triangle

It works as poorly designed, but it's not expected. You don't need to show those tiny meaningless jumps to the user since no user action will be different based on this extra precision, the scrollbar indicator is just not that kind of tool.

With Apple apis, it's attend WWDC or good luck.

I spent decades in Java land using open-source libraries, where the quality was broad and deep. An enticing demo usually meant it was good all the way down.

With Apple, though, a nice demo means you can do exactly what they did, but be blocked if you step off the happy path. Worse, each developer needs to get bruised because there's no publicly available list of bugs for an API.

I'm grateful to those who publish critiques of API's. It's a life saver.

What on earth? How is that considered acceptable? And from Apple of all companies, the ones that put a speaker in the iPod just so it would improve the UX of scrolling.