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.
Over the years, I gained some level of expertise in TextKit 2 and macOS/iOS text processing, which resulted in STTextView - a re-implementation of TextView for macOS (AppKit) and iOS (UIKit) using TextKit 2 framework as a text layout engine, as well as public speaking praising the new, better engine we've just got to solve all the problems.
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)
The architecture & implementation
The TextKit2 architecture is good. The abstraction and the components make a lot of sense and deliver on the premise of progressive complexity. BUT the implementation is less so on par with the architecture. On the one side, NSTextContentManager provides an abstract interface for the layout engine. In practice, using anything other than NSTextContentStorage is impossible. NSTextContentStorage is one (and the only) provided implementation of the storage that works. That itself is backed by NSTextStorage, which is an abstract interface for the content storage itself - meaning all the problems I may have with NSTextStorage apply to TextKit 2 as well. In short, the UITextView/NSTextView won't work with anything other than NSTextContentStorage.
Text content manager operates on a series of NSTextElement blocks, but again, the only working implementation must inherit from NSTextParagraph, or you're in trouble (runtime assertions).
The implementation is inconsistent, and it seems intentional. TextKit2 is implemented to be used by UITextView, and that is quickly obvious. What a waste of a great idea that could have been otherwise.
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.
Viewport is a struggle
Real struggle, though, is around the newly introduced idea of the viewport and how it works. Viewport is a tool that optimizes text layout engine work and minimizes memory footprint by focusing on the visible area, rather than the entire document, all the time. Viewport is a small portion of the visible area that "moves" as the user interacts with different parts of the document (eg, scrolling moves the viewport frame)
... continue reading