Friday, August 15, 2025

TextKit 2: The Promised Land

Marcin Krzyżanowski (Mastodon):

TextKit 2 (NSTextLayoutManager) API was announced publicly during WWDC21, which is over 4 years ago. Before that, it was in private development for a few years and gained widespread adoption in the macOS and iOS frameworks. Promised an easier, faster, overall better API and text layout engine that replaces the aged TextKit 1 (NSLayoutManager) engine.

[…]

Based on my 4 years of experience working with it, I feel like I fell into a trap. It’s not a silver bullet. It is arguably an improvement over TextKit 1. I want to discuss certain issues that make the TextKit 2 annoying to use (at best) and not the right tool for the job (at the worst).

[…]

Bugs in software are expected, and for TextKit 2, it’s no exception. I reported many bugs myself. Some issues are fixed, while others remain unresolved. Many users received no response. Additionally, bugs occur in specific versions, and regressions are common. It is annoying to maintain compatibility, of course. From my perspective, probably the most annoying bugs are around the “extra line fragment” (the rectangle for the extra line fragment at the end of a document) and its broken layout.

[…]

When ensuring layout only in the viewport (visible area), all other parts of the document are estimated. Specifically, the total height of the document is estimated. The estimation changes frequently as I lay out more/different parts of the document. […] The jiggery is super annoying and hard to accept. […] For a long time, I thought that I “hold it wrong” and there must be a way (maybe a private API) that addresses these problems, then I realized I’m not wrong. TextEdit app from macOS suffers from the very same issues I do in my implementations.

The API is designed for subclassing different pieces but doesn’t actually work if you try to do that.

Simon B. Støvring:

Marcin is way further down the rabbit hole than I am, but I can certainly relate to his frustrations.

In fact, this is part of the reason I haven’t gotten further with Runestone for Mac. I hope to get further one day, but building a great text editor is incredibly time-consuming because you either add workaround upon workaround or you drop down to Core Text, which I did with Runestone for iOS/iPadOS.

Peter Steinberger:

Building stuff on closed source broken API is so incredibly frustrating.

Dominik Wagner:

It used to be worth it to provide the best native experience you can bring. But with the latest best of breed quality of first party apps not even knowing what that should mean it becomes futile.

I know if I would start now I would prioritize both cross platform and open source.

Previously:

4 Comments RSS · Twitter · Mastodon



I've lost weeks of life dealing with TextKit 1 bugs. I've been following devs like Marcin because I didn't have the heart to jump into TextKit 2 and get more burned.

I haven't found anyone who likes it.

Another data point, the dev of CotEditor reports similar "there are still high barriers that prevent CotEditor from migrating to TextKit 2". Unrelated, thanks Léo for ObjCSyntax.

TextEdit is the proxy I use to tell if TextKit 2 is "there yet". It's not (it's worse than when it was on TextKit 1). Apple's TextKit 2 example code is also broken. We're 4 years in.

What is Xcode using? What is Pages using? What's the TextKit 2 posterchild? When do the bugs get fixed? If the best thing is to drop to CoreText and write your own LayoutManager and TextView, what's the point of TextKit 2?

Text-heavy projects staying within Apple's stack face the choice:
Stay in the burning house of TextKit 1 (Apple has signaled we need to move to 2).
Jump into the lava pool of TextKit 2.

I think Apple's entire dev stack is a Promised Land.


@Hammer Haha, cheers.

I used to love digging into these semi private impls, figuring out their bugs and fixing them with swizzles. These days, that approach has become very hostile by using shitty runtimes such as Swift and SwiftUI, and even when possible, I just don’t have the patience or desire to do so, given the broader ecosystem and environment. When was the last time there was some amazing software? Everything these day, especially new software, is a subscription service with a terrible custom UI. At least we had Apple’s software to look forward to, provided good UI and UX. That is gone too. When Electron apps are more coherent than your dripping manure of a redesign, it’s just not worth the effort anymore.

If I remember correctly, Pages has its own completely bespoke layout system, that was unified years ago between macOS and iOS. If you have SIP disabled, you can attach with Xcode and take a look.


I have spent quite a few months working with TextKit 2 for editing rich text on Mac, although nothing in production yet, because it’s not up to scratch.

It didn’t support any kind of printing until macOS 15, which means no PDFs and no thumbnail generation. Now that it does, it’s not clear you can have control over pagination, as you can with TextKit 1. It doesn’t handle tables, which Writing Tools will generate, even though they recommend using TextKit 2 to get the animation when it rewrites text, ironically.

NSTextView will fall back to TextKit 1 if it encounters anything unsupported, and when it does you’ll instantly lose your view-based attachments. You never know what might trigger that. For example, a bug in macOS 14 and earlier meant showing a Quick Look preview of an attachment would force a fallback when it tried to generate the transition image. Some things (like that) you can work around, but the cases are not documented, and will vary from release to release. Unless what you’re doing is dead simple, it’ll probably trip you up one way or another.

TextKit 2 seems to be another of those things that doesn’t quite deliver what was promised, and while Apple made it clear it wasn’t complete back when it was announced, their progress in filling in the gaps has been glacial. It makes me worry, because I know there are great apps (much better than mine!) that perform wonders with TextKit 1. Clearly they want people to transition at some point, but right now they can’t. I can only hope they grapple it eventually, as they did with WKWebView.

Leave a Comment