> TextKit2 is implemented to be used by UITextView
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.
krzyzanowskim · 46m ago
> I personally would not attempt to build an alternative to UITextView on TextKit (1 or 2)
sure. If only UITextView/NSTextView did not have bugs impossible to workaround otherwise. TextKit 2 support in UITextView/NSTextView was really bad. improved over time. and still remain buggy. The UITextView focus limits the use of TextKit 2 architecture significantly.
lapcat · 51m ago
> I would not dismiss TextKit2; it is an incredible improvement over TextKit1.
It's an absolute disaster on macOS. Even TextEdit app is now buggy as hell.
It's incredible how Apple broke plain text display on the Mac, which was a solved problem since forever.
dgreensp · 17m ago
This semi-explains why I have started to notice (sadly) serious bugs in TextEdit, not just scrolling but editing/corruption.
valorzard · 45m ago
I was really excited by the title that this would be about beloved classic Minecraft mod pack Tekkit
refulgentis · 56m ago
Interesting read.
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.
krzyzanowskim · 33m ago
as long as we deal with estimated values, it is inescapable. the best we can do is tune the estimate calculations and tweak heuristics. that's my understanding of the problem, but I'd love to hear from other experience
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.
sure. If only UITextView/NSTextView did not have bugs impossible to workaround otherwise. TextKit 2 support in UITextView/NSTextView was really bad. improved over time. and still remain buggy. The UITextView focus limits the use of TextKit 2 architecture significantly.
It's an absolute disaster on macOS. Even TextEdit app is now buggy as hell.
It's incredible how Apple broke plain text display on the Mac, which was a solved problem since forever.
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.