Update (6/13/2019): The original version of this post featured the wrong colors in the ColorCompatibility enum at the end of the post. This has now been fixed.

Update (9/21/2019): The original version of this post included systemBrown, a color which was removed in the Xcode 11 GM. It also contained unnecessary availability checks in the code at the bottom (system colors like red, blue etc have been available since iOS 7). The code has been updated, and the tables in this post still list all system and element colors - even those which have been available for a while, since they're different in dark mode vs light mode. I also updated a reference to Mac Catalyst.

Update (10/5/2019): A previous version of this post included the wrong default colors in the ColorCompatibility code at the bottom of the post. These have been updated - the defaults are now the light mode colors which are being used in production in Trestle and CIFilter.io.

Update (10/5/2019): In order to better support bug reporting on ColorCompatibility, I've released it as a library. The code now lives in this GitHub repo. You can read more about it here.

Update (10/17/2019): A previous version of this post included the wrong color values in one of the example code blocks. This has now been fixed, but I'd recommend looking at the ColorCompatibility library if you're interested in using it in your own projects.

At WWDC 2019, Apple announced that Dark Mode would be supported on iOS 13. There are some significant changes to UIKit in order to support this - many of them are detailed in the talk Implementing Dark Mode on iOS which I'd highly recommend watching.

One of the changes that makes adopting Dark Mode so easy is the new system colors API from UIColor. On iOS 12 and older, you might have a label you want to make black, and it would work just fine - in fact, black was the default color for UILabels.

label.textColor = UIColor.black

But in Dark Mode, the background will also be black, which means the text won't be visible. In iOS 13+, it's better to use the new system color which will respect the user's color scheme preference:

label.textColor = UIColor.label

label is only one example: there are 24 new color scheme agnostic UIColors available in iOS 13+.

Colors are organized into two groups:

1. Element Colors (e.g. label)
2. Standard Colors (systemIndigo, systemGray3, etc).

iOS 13 has 23 new element colors (label etc) and one new standard color (systemIndigo). However, even system colors that have been around for a while (like systemRed) have become dynamic in iOS 13 - they might actually be different colors in dark mode vs light mode.

(Skip to the bottom if you'd like to see a list of the new colors.)

Compatibility

These new colors are all well and good, but most of us with existing apps will still be supporting devices with iOS 12 or lower, at least for a while. This means we'll probably be doing a lot of things like this, using Swift's #available syntax:

if #available(iOS 13, *) {
    label.textColor = .label
} else {
    label.textColor = .black
}

It's a workable solution, but it necessitates changing a lot of code - an if statement for every custom label or background color! For CIFilter.io, I wondered if there was a better way. What if, instead of the if #available, there was a way to abstract the color choice down one level, so we could do something like this?

label.textColor = ColorCompatibility.label

Generating system colors

I wrote a small app (with SwiftUI, no less!) which displays all the system colors in the current color scheme.

This app collects all the UIColor objects - once we have those, we can use their red/green/blue/alpha components to generate the implementation of ColorCompatibility that we want:

enum ColorCompatibility {
    static var label: UIColor {
        if #available(iOS 13, *) {
            return .label
        }
        return UIColor(red: 0.0, green: 0.0, blue: 0.0, alpha: 1.0)
    }
    static var secondaryLabel: UIColor {
        if #available(iOS 13, *) {
            return .secondaryLabel
        }
        return UIColor(red: 0.23529411764705882, green: 0.23529411764705882, blue: 0.2627450980392157, alpha: 0.6)
    }

    // ... 21 more definitions: full code in the link at the bottom
}

We can then use ColorCompatibility it to set any colors we need.

Note: we can't use @available for these checks, since it doesn't provide a way to check if the current environment is less than a specific app version.

Conclusion

This approach has some great advantages:

1. This code will compile on iOS 13+, iOS 12 and earlier, and Catalyst ✅
2. Since everything is a computed var, we never pre-store colors, which means that when the user switches color scheme, our app will automatically adapt as the trait collection changes 👍
3. When we drop iOS 12 support, cleaning this up will be as simple as replacing every instance of ColorCompatibility with UIColor 🎉

Hopefully this makes your app's transition to dark mode easier!

If you're interested in dark mode and new UIColor apis, you can follow me on Twitter as I continue to play around with these new iOS technologies.

Table of system colors

For those interested in iOS 13+ system colors but not wanting (or not able) to compile the sample app, here's a list of the system colors in light and dark mode, with their hex codes and RGBA values:

ColorCompatibility full code

The full, generated implementation of ColorCompatibility, which is used by Trestle and CIFilter.io, is available here.