It looked as if it would be so simple when Mojave introduced Dark Mode, didn’t it? After all, it’s just a control in a System Preferences pane. Sure, everyone anticipated there’d be issues with document formats which were pernickety about colours, like web pages and PDF. But ordinary, common or garden Rich Text?

Eighteen months later, Rich Text remains a real mess in Catalina’s Dark Mode. Apps that work with what macOS terms Attributed Strings handle their non-coloured text one way, and those like TextEdit do something completely different. Some QuickLook thumbnails don’t work properly, while others do. In short, Apple hasn’t tidied up the loose ends even in macOS 10.15.3.

You can catch a glimpse of these problems in QuickLook thumbnails, as shown in the Finder, and in previews. Apps which handle Attributed Strings and then write them out directly to RTF files generate their uncoloured (black/white) text in bimodal form. In QuickLook thumbnails viewed in Light Mode, these look fine.

But switch to Dark Mode and QuickLook can’t cope with that bimodal text, so displays it in white on white, making the thumbnail useless.

What’s weird about this in Catalina is that its new stacked thumbnails do recognise the bimodal text, and render it correctly even in Dark Mode.

To understand what is going wrong here you have to go into Attributed String and how they’re written out as RTF.

For apps to display Attributed Strings correctly in both modes, the colour of that text has to be set correctly. According to Apple’s documentation, the preferred colour for all text in the user interface is NSColor.textColor. There are also standard system colours which adapt properly to changes in mode and vibrancy, such as NSColor.systemBlue, but there’s no other black/white; if you use NSColor.black it stays black regardless of the mode, which is disastrous if Dark Mode changes its background to near-black.

When an app makes the macOS call to save Attributed Strings to a Rich Text file, text in NSColor.textColor is written out in a special bimodal form. The colour of that text is defined in the RTF using an expanded colour table. In source this is defined as
{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
{\*\expandedcolortbl;;\cssrgb\c0\c0\c0\cname textColor;}
and used as
\cf2 This is bimodal

When that RTF is read into an app, including TextEdit, it is rendered as black on white in Light Mode, and white on black in Dark Mode: it’s bimodal.

It also isn’t handled properly in QuickLook thumbnails or previews, which even in Dark Mode don’t change the background according to the appearance, but do change the colour of the bimodal text. The result is white text on a white background, which is surely the worst outcome possible. Although this has been corrected in the new stacked thumbnails which are shown when multiple documents are selected in Catalina, all they do is keep the background and text in Light Mode. This contrasts with plain text thumbnails, which are shown in black on white in Light Mode and change to white on black in Dark Mode.

TextEdit itself still hasn’t been fully converted to work properly in Dark Mode using bimodal text, which implies that Apple doesn’t use NSColor.textColor for its Attributed Strings, despite its own documentation. By default, even when you manually switch TextEdit to using a dark background in Dark Mode, it displays text in unimodal colour. Copy and paste it into an app like my DelightEd, or into an NSTextView in Xcode’s Interface Builder, and you end up with unimodal black text against Dark Mode’s near-black background.

Since Apple introduced Dark Mode in Mojave, developers have been unable to use TextEdit to create styled text to insert in their apps when working in Xcode, because TextEdit and Attributed Strings don’t work together any more.

It’s time for Apple to finish off Dark Mode properly, to restore consistency to the macOS interface, and to make QuickLook thumbnails and previews work properly in both modes. Before we rush into macOS 10.16, please.