Apple text layout architecture evolution: TextKit reboot

No matter what kind of fancy fonts you have, they look bad with poor typography.

Tomihisa Uchida, former lead font engineer of Shaken, FontWorks, Iwata

As I wrap my typography related writing, it’s fitting to post about Apple’s text layout architecture evolution one last time. There have been a few changes over the decades. Actually it has been nothing but changes, going forward, pulling back, going forward again in bits and pieces instead of one united comprehensive vision.

Part of my current job includes dealing with lots of vertical text Japanese documents with lots of traditional Kanji characters that juggle different Japanese encoding standards depending on when the documents were created. For that reason I’m keen on robust vertical text layout and easy to access, easy to use high end Japanese font typography features. InDesign is there but its high end page layout features are overkill and time consuming when a good word processor will do.

Unfortunately there are very few choices outside of the Creative Suite world. Japanese high end features in Word are clunky and confusingly scattered around the UI, Pages vertical text and advanced font feature UI is a joke. The best Japanese word processor on macOS is egword Universal 2, egword has a long history and has used every single macOS text engine at some point. It’s a miracle that it survived. Why it is so hard to get international savvy, insanely great typography and layout features that should be standard and universal?

QuickDraw GX is the start point for built-in high end typography on personal computers. Thought it was short-lived, GX parts and concepts live on in Apple OS platforms to this day such as the SF variable system fonts. It’s hard to explain how revolutionary GX was in the Asian markets and how much exciting development was going on at that time, utterly impossible to comprehend from the western biased wikipedia entry. Suffice to say GX was the first multilingual internationally savvy text layout architecture where all writing systems, languages, various font technologies, scripts and layout models were equally and very well supported, right to left, vertical, contextual and so on.

After Copland OS was cancelled in August 1996, GX text technology morphed into Apple Type Services for Unicode Imaging aka ATSUI. ATSUI along with Apple Advanced Typography (AAT) font tables were some of the technology that made the Hiragino Apple Publishing Glyph Set feature, aka Hiragino Shock, possible in OS X 10.1. The better performing Cocoa based 64-bit Core Text replaced 32-bit Carbon ATSUI in OS X Leopard. macOS Lion AppKit finally gained some vertical text support but it wasn’t very robust as was demonstrated later when TextKit functions migrated to UIKit in iOS 7. The lead font engineer of Iwata Corporation had this to say:

UIKit (TextKit) doesn’t support real vertical text layout, the Japanese punctuation and glyph spacing are all wrong. The easiest thing for an app developer to do is bundle a display only Japanese vertical font just for displaying vertical text in the app. Go ask the programmers at Monokakido, I’m sure that’s what they have to do for their iOS Japanese dictionary apps.

‘Real’ vertical text layout remains a low level Core Text coding exercise which Apple really doesn’t encourage unless, “you must do text layout and font handling at a low level, such as developers of layout engines. You should develop your app using a higher-level framework if possible.” In other words, use TextKit.

I suspect one reason for Apple’s recommendation to use TextKit instead of Core Text whenever possible, is the parade of Core Text rendering bugs and security leaks that started cropping up in 2013 and continue to trickle. Therefore high level TextKit in iOS UIKit and macOS AppKit is the preferred text layout method as it abstracts away Core Text grunt work and exposing potential Core Text rendering and security bugs.

There’s a trade off however: TextKit is 30 years old, far older than Core Text, older than GX even, and shows its age. It’s the last NextStep holdout that never got an upgrade, its text layout features and performance are good enough, but not very good. Apple recognizes this and is finally doing something about it: TextKit 2, Apple’s next-generation text engine.

The best place to start for all things TextKit 2 is the WWDC21 video: Meet TextKit 2. The big new takeaway points are:

Non-linear viewport-based layout: TextKit 2 only lays out the appropriate text area that needs to be displayed • edited unlike linear layout which does the whole text document sequentially. You are probably familiar when scrolling long text documents and it takes forever for the text to render down to your current location, like standing on the beach waiting for the last tip of a wave to creep up and reach your feet. That wait is gone in TextKit 2.

TextKit 2 does this using viewport-based layout and rendering. When I saw the WWDC video my first reaction was ‘this reminds me of that shitty new WordPress block editor.’ Other developers had the same reaction. The thing is, once you get used to the shitty WordPress block editor, you don’t want to go back. It’s way more convenient even if the performance isn’t great.

The new TextKit 2 block editor approach promises to deliver convenience and high performance along with, “a robust set of customization points, making it simple to extend the layout system and add your own behaviors” that “also lends itself well to mixing non-text elements into your text layout.” Great, just what I wanted, more emoji + text + whatever-you-want-to-insert-here mishmash.

Glyph Abstraction: aka correct rendering for complex scripts because Apple does the grunt work (in Core Text) so you don’t have to. It removes the drudge. On a practical level text selection will work correctly no matter the script or language. With UIKit•TextKit 1, text selection is never reliable even for Japanese.

Safety aka more abstraction: there’s a huge middle section that discusses the bulk of the new TextKit 2 calls and how they work, the goal being using layout ‘elements’ instead of glyphs, strings, paragraphs, etc. Like glyph abstraction, it’s another kind of abstraction and illustrates the TextKit 2 mantra of using higher level objects to control layout. Eliminating the many TextKit 1 layout details developers have to juggle is a good thing.

Inclusive layout yes, but is it high quality layout?
TextKit 2 is the start of a long term migration. When it is done I think we’ll just have TextKit 2 that is simply called TextKit. For now, most of TextKit 2 is ‘opt in’ for compatibility. macOS 12 has all TextKit 2 functions, on the iOS side, UITextField (single-line editable text) has been updated to use TextKit 2 but UITextView (multiline text) has not.

The migration is going to take a while. I don’t think we’ll get the full TextKit 2 story until WWDC22. Once the transition is complete I suspect Core Text 2 is next. We’ll see. Japanese developer reactions have been muted along the lines of, “Apple wants to be inclusive, which is nice, but it doesn’t look like a high end solution.” After all, Japanese developers have been down this road many times before.

And so we circle back to my original question, does TextKit 2 finally deliver international savvy, insanely great typography and layout as standard universal features all developers can implement easily in apps? Definitely maybe…for apps, but never for the web. That’s a whole other story.