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.
mpweiher 15 hours ago [-]
With NeXTstep it was exactly the opposite: you could usually rearrange, recompose, override the pieces any way you wanted, including from scratch, but the demos and pre-built parts were of such quality that you didn't really want to.
But if you wanted: knock yourself out.
With the first version of Mac OS X, I was stunned that the high-level "convenience" APIs had capabilities that you couldn't actually replicate using the lower level APIs. And this seems to be getting worse. Fortunately with Swift we now have a type-system to enforce the "Apply way or the highway" attitude.
andrekandre 20 hours ago [-]
> 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.
when making new apis its a good idea to have people try and use it like this to find and fix the rough edges and fix bugs... it definitely feels like apple didn't do that (at least enough) here...
zffr 19 hours ago [-]
Apple’s typical process for releasing public API involves dogfooding it internally first. Sometimes it will take years of internal use before Apple will release API publicly.
With something as large as TextKit, I would be extremely surprised if Apple did not get several of its apps to adopt the new API and use it for a few years before considering releasing it publicly.
wpm 19 hours ago [-]
I’m sure they did, but did they actually fix all of the bugs they found?
colbyn 23 hours ago [-]
Oh hey good to see some more literature on TextKit2. I remember diving into it when I wrote my proof of concept markdown renderer:
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).
colbyn 22 hours ago [-]
Oh also I’d like to add to the above, the TextKit2 API is way more freeform than people think. You could probably implement your own web browser upon it with optimized line by line text rendering (which isn’t that bad). One thing I always wanted to experiment with is rendering markdown content with horizontally scrollable text fragments for table rows and certain fenced code blocks. Super cool and practical idea for native markdown text rendering. Moreover, in some ways it seems pretty easy to do in TextKit2 since you get very fine grained control over text layout fragment rendering.
nicoburns 20 hours ago [-]
> You could probably implement your own web browser upon it with optimized line by line text rendering
I actually have an ambition to do this. I already have most of the layout engine. The use case is for a React Native like framework that can render spec-compliant web content.
krzyzanowskim 22 hours ago [-]
we could build a space rocket with it if we only knew how to use it, so it would not glitch
arthurofbabylon 24 hours ago [-]
> 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.
lapcat 24 hours 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.
rayiner 20 hours ago [-]
Is it incredible, or is it quite credible? It’s taken Microsoft years now for “New Outlook” to get feature priority with Outlook 98. This feels like the new normal.
layer8 1 hours ago [-]
feature parity
krzyzanowskim 24 hours 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.
Wowfunhappy 7 hours ago [-]
> In a scrollview, such frequent and significant changes to the height result in "juggery" of the scroller position and size
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.
eviks 18 hours ago [-]
> The jiggery is super annoying and hard to accept. This is also expected, given that the height is estimated. Works as-designedj
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.
rumori 5 hours ago [-]
When I was working with TextKit years ago I was constantly using the Hopper decompiler on iOS SDKs to understand the internal workings of these frameworks. Documentation is sparse and calling functions in the right order resulted in big differences in results.
It can take a lot of time and trial and errors to get it right.
whoisthemachine 19 hours ago [-]
This is an unavoidable result of lazy layouts. With the LazyList in Jetpack compose, it's comically difficult to produce a scrollbar, because the "LazyList" only ever lays out the visible items, so Compose can't really know (unless you actually already know) the full size of the list.
I find the iron triangle of project management reins supreme in a lot of domains: quality is sacrificed in the name of performance.
While difficult, there are surely ways to make the scroll bar move more smoothly. For instance, you could demand that it can only change direction when the scroll direction changes. You can also use past scroll bar positions as stronger estimates of document height than text content and whatever else is being used, which would lead to more consistent (if inaccurate) scrolling as well. But as long as we're estimating things we might as well make them enjoyable to use; it's not like the user will be able to discern that the scroll bar is off by 5% anyway.
wavemode 17 hours ago [-]
> "Good, fast, cheap. Choose two."
I think many software companies would happily choose good and fast if that were an option. In reality it rarely is (see: The Mythical Man Month).
In fact a lot of companies don't end up achieving any one of the three.
dgreensp 23 hours ago [-]
This semi-explains why I have started to notice (sadly) serious bugs in TextEdit, not just scrolling but editing/corruption.
unconed 7 hours ago [-]
It's bizarre that they prioritize parsimony over correctness. Laying out long documents can happen in the background, but shouldn't be deferred to when you actually scroll.
krzyzanowskim 6 hours ago [-]
annoyingly enough, the API has some sort of background layout support. I don't think it works well, though. I tried to use it, but it did not improve the "main thread" operations sigificantly to have an impact of fast scrolling scenario - I suspect it may not work actually
keyle 18 hours ago [-]
I tried to use it a year+ ago and that was a joke and a half. Half baked, buggy, and horribly documented.
With Apple apis, it's attend WWDC or good luck.
refulgentis 24 hours 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 23 hours 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
kmeisthax 19 hours ago [-]
If anyone had tried lazy-loading scrolling in TextEdit back in the day, Steve Jobs would have had a tantrum. This shit looks awful in motion.
valorzard 24 hours ago [-]
I was really excited by the title that this would be about beloved classic Minecraft mod pack Tekkit
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.
But if you wanted: knock yourself out.
With the first version of Mac OS X, I was stunned that the high-level "convenience" APIs had capabilities that you couldn't actually replicate using the lower level APIs. And this seems to be getting worse. Fortunately with Swift we now have a type-system to enforce the "Apply way or the highway" attitude.
With something as large as TextKit, I would be extremely surprised if Apple did not get several of its apps to adopt the new API and use it for a few years before considering releasing it publicly.
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).
I actually have an ambition to do this. I already have most of the layout engine. The use case is for a React Native like framework that can render spec-compliant web content.
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.
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.
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.
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.
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.
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
I think many software companies would happily choose good and fast if that were an option. In reality it rarely is (see: The Mythical Man Month).
In fact a lot of companies don't end up achieving any one of the three.
With Apple apis, it's attend WWDC or good luck.
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.