From its launch in January 1984 until Apple released macOS Mojave five years ago, one of the Mac’s most distinctive features was its black-on-white display. During the desktop publishing revolution, the Mac led the way in showing documents on screen just as they’d appear when printed. When the Mac gained colour in 1987, the convention remained unbroken: when laying out your documents, text was rendered in black on a white background.

The world had changed a great deal in the 34 years that passed before Mojave came to grace our Macs. Designing for print was in steep decline, and many Macs weren’t even connected to printers. Photographers, digital artists and movie makers had all been using apps that reversed the Mac’s tradition and had dark interfaces, and those had become a preference for many. Those coding for the Web or software development were also discovering how text editors with dark interfaces enhanced the appearance of syntactic colouring in their source code. Over the same period, displays had also changed: the original Mac’s 512 x 342 pixel monochrome display had been replaced with 5K Retina models boasting 5120 x 2880 pixels with a P3 colour gamut.

Microsoft had added a dark theme to Windows 10 in 2016, and Apple introduced Dark mode in Mojave two years later, on 24 September 2018.

Dark and Light modes are built into macOS as Appearances. Although it took some time for them to be widely supported, five years later those who prefer to work in Dark mode are seldom frustrated by poor support. As Apple explains, “Dark Mode uses a dark colour scheme that works system-wide, including with the apps that come with your Mac.”

It expands on that in its instructions to developers: “Avoid offering an app-specific appearance setting. An app-specific appearance mode option creates more work for people because they have to adjust more than one setting to get the appearance they want. Worse, they may think your app is broken because it doesn’t respond to their systemwide appearance choice.”

In my experience of working much of those five years in Dark mode, the only apps that still present problems are Apple’s: TextEdit, for example, has had a long battle to move away from black-on-white text. Apple even admits its current compromise, saying “TextEdit can use a light background for documents while Dark Mode is turned on: Turn on Dark Mode, then click View in the menu bar in TextEdit and deselect Use Dark Background for Windows.” Neither do any of Apple’s iWork productivity apps support a complete Dark mode yet, and their dark templates don’t reverse when used in Light mode. Other major apps like Xcode do, though, make excellent use of Dark mode and have full support for both Appearances.

This comes to a head for developers when they’re trying to ensure that they follow Apple’s instructions. A good example is embedding text in a scrolling text view, in an AppKit window for macOS. If they paste rich text from TextEdit into that text view, it’s fixed in whatever combination of colours TextEdit was using, typically using black text. Apple tells developers to avoid using fixed colour for text used in the interface, and to use NSColor.textColor instead, described as “The color to use for text.” Only TextEdit doesn’t, it uses fixed NSColor.black instead.

At their introduction in WWDC 2018, Apple was careful to explain the difference between Appearance modes and fixed colour settings. Dark Mode isn’t a simple reversal of black and white on the display, but results in more general adjustment of colours to ensure they look right. This involves the use of colours that specify a context rather than a set hue, including one intended for standard text to be rendered as white in Dark Mode, and in black in Light Mode, making it bi-modal.

Apple has also incorporated the use of NSColor.textColor as a bi-modal colour for text in an idiom that macOS builds into rich text. This involves adding an expanded colour table, such as
{\*\expandedcolortbl;;\cssrgb\c0\c0\c0\cname textColor;}
to the code at the start of the rich text, then using that for all text to be rendered bi-modally in NSColor.textColor by the app. This can even be expanded to render other colours bi-modally, as in
{\*\expandedcolortbl;;\cssrgb\c0\c0\c0\cname textColor;\cssrgb\c15686\c80392\c25490\cname systemGreenColor;\cssrgb\c0\c47843\c100000\cname systemBlueColor;\cssrgb\c100000\c23137\c18824\cname systemRedColor;}

This is exactly what my little rich text editor DelightEd does, and as a result it works perfectly with both Appearance modes, and for the preparation of text to be pasted into text views in Xcode. As this uses AppKit and macOS to do all the heavy lifting, my code doesn’t have to worry about rendering text in NSColor.black in Dark mode, and will convert text from fixed colour to bi-modal NSColor.textColor to prepare it for use in Xcode.

macOS has had this simple solution to implementing Dark mode since the release of Mojave five years ago, so I can’t understand why TextEdit and the iWork apps still can’t comply with Apple’s instructions to developers and support Dark mode properly.