Introducing Dark Mode

Hi everyone. Welcome to the Introduction to Dark Mode session. My name is Raymond Sepulveda, and I'm a macOS designer on the Human Interface Design team. For the first half of today's session, I'm going to be going over some of the design principles that went into the design of Dark Mode, as well as some of the design considerations that you should take into account when updating your own applications to take advantage of Dark Mode. Then, for the second half of the session, my engineering colleagues Rachel Goldeen and Taylor Kelly from the Cocoa Frameworks team are going to be going over how to adopt and support Dark Mode using an example application that they built together. The three of us are super excited to share all of these details with all of you, so let's jump right in. As we announced in yesterday's keynote, macOS 10.14 is going to be getting a new interface appearance, and we call it Dark Mode.

The new design is very attractive and engaging, while at the same time being very calm and understated. These are great qualities for an interface, and they make it great for creative professionals who are dealing with heavily detailed images and colorful assets such as images and video assets.

But, in actuality, it's actually great for just about any type of user who is looking to concentrate or focus on any given task at hand. So, whether you're trying to concentrate on writing the next great novel or you're trying to read one without disturbing your bedside partner, Dark Mode is really great for either type of situation.

The interface shares a lot of family resemblances between the light appearance and the dark appearance, and that is because we wanted to encourage users to switch between both appearances easily and find the one that really best suits their needs. And so it was very important that things like control metrics, window layout, and the distribution of translucent materials be the same as much as possible between both appearances. As such it's also equally important that all of your applications take full advantage of both appearances so that they update correctly between both appearances no matter what the system is running under. You really don't want to be that one light appearance that's stuck in dark appearance. All in all, we're super happy with how the design turned out, and we are really anxious to see what you guys are going to turn your apps into as soon as you get hands on the developer beta and start adopting the Dark Mode.

Aside from Dark Mode, another new interface feature that we added into macOS 10.14 are accent colors. Previous releases of macOS offered two accent colors, blue and graphite, but for macOS 10.14, we've expanded the color palette to include eight fun colors to really help you personalize your Mac. So, if you're like me and you love the color red, you're going to immediately switch over to the color red . If orange or yellow are more of your preference, you're going to switch over to those, and we make those available as well. I should note that the accent colors are not just a sub-feature of Dark Mode, but they're also available in Light Mode. So if you prefer Light Mode but want green accent color, you can do that as well.

So, now that we've covered a little bit of the basics of what Dark Mode is and what accent colors are also, let's dive a little bit deeper into some of the design principles that went into Dark Mode. At Apple, when we begin a new design project, we like to establish a set of design principles to help guide us throughout the entire design process. And, with Dark Mode, there were three in particular that we referred to quite often throughout the entire process. The first one is the most straightforward, so let's just jump right into that one, and that is that dark interfaces are cool, period, right? They are almost effortlessly cool in a way that light interfaces sometimes kind of struggle to be. But why is that, really? Part of it is because we all have these notions of what a dark interface is and what a dark interface looks like. And a lot of that is fed into us by what we've seen in pop cultures in things such as sci-fi movies and action movies. So much so that if I were to go around the audience and ask everyone to give me one-word association of what a dark interface is to them, I'd get responses such as cool, of course; slick; professional; futuristic; and even beautiful.

So going into the design for Dark Mode, we really wanted to acknowledge all of these aesthetic associations that we all have with dark interfaces, while at the same time embracing a lot of the real benefits that a dark design offers you, such as a higher contrast for typography. We realize that Dark Mode is really, really cool, and that a lot of you are going to want to adopt Dark Mode on your apps permanently. But, in actuality, only a small subset of apps really should be dark all the time, and those are things that are media-centric or content-creation apps. Those are the ones that are best suited to staying dark all the time, so if your app doesn't fall into one of those categories, it's better to let your app follow what the system appearance is, rather than to make it dark permanently. The second principle was that dark interfaces are not just inverted. And, really, what's at the core here is that when you look at a dark interface, it can sometimes be easy to think of just taking the light interface and inverting it to end up with your final result. But, in actuality, that can be very creatively limiting, and so it's better to take a look at your elements and your application on a case-by-case basis and try to determine what is the visual cue that they're trying to communicate and then figure out whether an opposite visual cue is necessary.

So, if you take something, for example, like, a standard Light push button in the light appearance, the buttons look like this in their active state. And, then, when you click on them, the buttons darken. And this is generally true of almost all of the controls in the light appearance in that their click state is a darker version of what their active state was.

In Dark Mode, however, the general active state looks like this, and when you click on them, they brighten, and that, again, is generally true of all of the controls. They will all generally brighten up. Another example are group boxes. In light appearance, the group boxes have a dark fill behind them and are shaded such along the edges to give them a recessed quality such that they look like they're carved into the window background that they're inside of.

In Dark Mode, however, the group boxes are treated almost as if they are self-illuminated. But, at the end of the day, the general purpose of the group box is the same between the two modes in that what they're really trying to communicate to the user is that the contents contained therein are all related somehow.

Why I said that it was important to go on a case-by-case basis and try and determine what the visual cue that your elements are trying to communicate-- It's important, is because, in some cases, the visual cue that's being communicated is already effective enough in the Light Mode and should be left as is in Dark Mode. An example of this are the window shadows.

As we all know, macOS is a layered window environment, and the window shadows really help to communicate the sense of depth, the Z-depth of the windows. So, if we were to have inverted the window shadows, for example, and started using a white shadow, for example, the entire UI would have become flat. You would have lost that sense of depth. Another thing to note is that the window shadows in macOS are constructed of two layers. We've got the diffused shadow and the rim shadow. So, if we look at this little portion of the screen and look at how the shadows were constructed and treated in Dark Mode, the first thing to note is that, in taking into consideration that users are going to be able to go back and forth between light and dark appearance quite often and that some apps are going to stay dark all the time, it was important for us to keep the diffused shadow exactly the same. So, we used the exact same shadow blur parameters for the shadows in Dark Mode.

Next, we took a look at the rim shadows and saw what changes we needed to do for those, and the changes that we did for Dark Mode where we adjusted the opacity to make them a little bit higher so that the contrast edge was more defined and that we made them a little bit crisper. To further the focus and the edge detail on the windows, we added an inner rim stroke to the windows to really help define the windows and pop them off. The end result is that the visual cue still looks very similar to the light appearance, but the end result has been finely tuned for dark appearance so that it works much better.

The second principle was that Dark Mode is content focused, and this was the one that we referred back to the most often throughout the entire process, actually.

When you look at a light interface screen, it can sometimes be a little difficult to tell what the content is, where to focus your attention to, especially when there are lots of windows on the screen.

And part of the reason for that is because a lot of the content that we all create is just bright in general. However, in a dark UI, the content stands out because of the background being pretty dark. All of the window chrome in the background generally just melts away, and the content becomes the primary focus of your attention.

Generally, we found that there were three methods for how to treat your content regions inside of your windows to optimize the content focus.

The first method was to just generally go completely dark. An app like Finder is a great example of where this is possible because of the way that the content is displayed. Finder's content are displayed as colorful file icons and so the dark background really helps the icons stand out as much as possible. The second method was to leave the content as is. Pages is a great example of what you see is what you get app, where the contents should be rendered and presented exactly as the user authored and created it.

Dark Mode is a great UI for what you see is what you get apps, because the content really becomes the primary focus, and the UI really becomes the secondary focus and almost melts away.

The third method was to make the content region appearance a user option. Mail is a good example of an app where the appearance of the content might be ambiguous as to whether the user would prefer it to be light or dark, and so the best thing to do is to make an application setting so that the user can determine whether they want it to be light or dark on their own, while their application's chrome area still respects the overall system appearance. One thing that all three of these windows had in common was that the chrome remained dark and became secondary to the content area. And Dark Mode kind of achieves this using a feature that we call desktop tinting, which causes the window's background colors to camouflage themselves with the desktop picture. We found that completely desaturated gray colors have a tendency to have a color temperature that was sometimes in conflict with what your desktop picture was, and this effect was magnified when you have a translucent sidebar area, for example, against a solid opaque area of your window, and so desktop tinting helps mitigate that. Once applied, the desktop tinting gives the whole window a harmonious color scheme, which helps it to blend in with the surrounding areas and really reduces that color temperature disparity.

So, how do we do the desktop tinting effect? The first thing that we do is, actually, we take a sample of the desktop portion that is behind the window, and then we derive a average color for that area, and then we blend that average color with a gray, which then becomes the window background color.

This background color is dynamic, so as the user moves the window around the screen, the color will update itself so that the window always stays in sync with the wallpaper portion that was behind it. So, if we look at the effect in action across a couple of different wallpapers, you can see that the window is adjusting itself on the right side to match the desktop picture that is behind it.

Not only does the window background color adjust itself to take advantage of the desktop color, but the controls also get a little bit of that going through them also due to the control's opacity.

For users that work in color-sensitive applications or have very color-sensitive content or just generally would prefer not to have the desktop tinting apply to their UI, we offer the Graphite Mode so that they can disable the color tinting altogether. If we take a look at the color swatches for the window background colors, along the top there, we can see the window background color in the Light Mode, which is the standard light gray that we're all accustomed to. And, in the middle there, we've got the under page background color, which is a mid-tone gray, and then we've got the content background, which is the white background color that we're all familiar with behind all of our content areas.

In the middle row, you can see how the desktop tinting affects these colors, and, then, along the bottom, you can see the effects of the graphite accent color disabling the desktop tinting effect.

So, now that we've gone over some of the design principles, let's go into a little bit of the design considerations that you should take into account when updating your apps. First, let's talk about colors.

For macOS 10.14, we added a lot of colors. We also removed a lot of colors, updated some, and, as you can see behind me, these are some of our system colors. Along the bottom, we've got the dark variance of the colors, and, as you can see, the dark versions are generally a little bit brighter and more saturated.

Rachel and Taylor are going to a little bit deeper into the color usage during their portion of today's session, but, for now, I just generally want to try and cover three colors in particular, which are the blues.

Going from left to right, we've got controlAccentColor, systemBlueColor, and linkColor. Linkcolor, as the name implies, is meant to be applied to links, text links in particular. So, things that are hyperlinks, taking of the user to a website, or a link within your application that navigates the user to another area of your application-- those should be treated with linkColor.

ControlAccentColor and systemBlueColor are really meant to be used on controls that have visible borders or button bezel backgrounds or for tinted glyphs.

ControlAccentColor, as the name implies, is going to respond to whatever the system accent color is set to, in this case, red. So, if you have a custom control that is trying to mimic the appearance of a standard system control, or you just have a control that you would like to follow suit with whatever the system appearance is set to, you should use controlAccentColor. If you have a control where it's important that the control stays blue because of informational purposes or for branding purposes, then systemBlueColor is a better choice for you to use.

Next, let's take a look at designing with vibrancy.

When we talk about vibrancy, what we're generally referring to is the package of a translucent material working in conjunction with the content that is displayed above it. So, in this case, the vibrancy is the vibrant Finder sidebar.

Generally, we have non-colored artwork that is meant to be treated vibrantly. An example of that is the glyphs and the text in the Finder sidebar here. The end result of the vibrancy is is that the colors become higher saturation, and the contrast is increased for things like the text.

Colored artwork, such as the finder tags in this example, should be treated as non-vibrant. Same thing with colored iconography. The vibrancy will destroy the original colors that you have in your image, and so you want to treat those as non-vibrant. So, taking a look at how you can construct vibrant content, it might seem almost obvious to just use opacities, in this case, opacities of white. But while it's true that some color contribution from the background is occurring through the materials here-- and that's happening because of the opacity-- the end result is actually not as highly saturated as we would desire. And, as you can see along the bottom with the Quaternary Label Color, the legibility is a little bit compromised.

Instead, what you want to do is construct these using opaque grayscale colors. One thing to note here is that the text color for the RGB label colors here are full black. What's going to happen once the Blend Mode is applied is that the text that is black is going to become completely transparent. So, if you have areas of your content that need to be treated as a knockout, use full opaque black, and if you have areas that need to be gradiate towards an opacity, use a gray that is ramping itself towards a full black. This is true in Dark Mode, and the opposite is true in Light Mode, in light, vibrant areas, I should say, where white full, opaque white is full transparent and gradiating towards that is going to give you a transparency.

So, once we apply the vibrancy, we can see that the gray colors become a lot more saturated, and the legibility of the Quaternary Color Label is a lot more improved. Putting them side by side, we can see just how much of a difference there is between the opacity construction, versus the grayscale construction. In some cases, over certain colors, the opacity construction will fly, but it's not exactly the best end result, aesthetically or legibility wise.

Next, let's take a look at artistically inverting glyphs, and, by artistically inverting, what I'm referring to is the process of creatively looking at your glyphs and determining what areas need to be adjusted to take advantage of the Dark Mode, for example. So, here we've got a set of our standard glyphs that we have in the light appearance. One thing to note is that the light appearances glyphs generally use a lot of edge strokes with hollow centers. And the reason for that is that we take advantage of the white backgrounds that these are generally placed on top of in order to denote form and shape.

But, if we were to take these exact same vector forms and place them over a dark background, all of that sense of form and volume is kind of lost, and so we had to artistically invert them to bring back some of that sense of form and volume.

Looking at how some of these are constructed, we've got a couple of simple examples, like this finder tag. On the left side, it's denoting a white tag with a dark eyelet cutout. On the right side, however, in Dark Mode, that sense of it being a white sheet of paper is lost. So, once we invert it, we get back that white sheet of paper with an eyelet knockout hole.

Looking at how this is constructed, generally, what you would do is expand the clipping paths, I should say, and then select your eyelet shape and then reverse the knockout on that. And then it's just a game of selecting any redundant vector paths and removing those. Taking a look at a slightly more complex shape, for example, the house. We've got a white house on the left side, and on the right side, the house isn't white anymore. So, inverting it returns us back to a white painted house.

Generally, the construction for this is about the same as the other process, but one important aspect of this glyph, in particular, was that we have to add a new shape into the vector form. In this case, we're mimicking the roof line, creating a shadow underneath the roof that we're going to knock out. And this is important, because if we were to have left the construction of the house without that shadow line, the roof would have no definition, and it would be really hard to see that at small size.

Moving on to a more complicated glyph, like this mail envelope, for example. On the left side, we can see a sense of volume and shape. We've got two layers, generally. We've got the back flap of the envelope, and we've got the front flap of the envelope with a letter contained in between. On the right side, a lot of that sense of volume is just missing because of the lack of fill colors.

And so, once we invert that, we return back to having a sense of volume.

Again, generally, the process of construction for this one is about the same as some of the other ones, but it's a little bit more detailed and time consuming just due to the number of paths that there are. But, generally, what you want to do is break it apart into two pieces, again, so that you have the front and the rear portion, and then you have your letter portion in between. One important detail that this glyph exemplifies is the dual opacities that we use in some of our glyphs. In this case, the letter is set to 80% opacity in order to make it secondary to the envelope, itself, being opened, which is what we're trying to communicate.

And the opposite is true in Light Mode also, where we do use 80% opacities, in some cases, also.

So, quickly wrapping up what we've covered so far.

Dark interfaces are cool, so cool that you're probably going to want to make your app potentially dark all the time, but unless your app is a creative or media-centric app, you should reconsider that, and, instead make your app follow what the system appearance is set to, instead. Don't limit your app design to just inverting your existing light appearance, and, instead, take a look at what elements are in your app on a case-by-case basis, and try and determine what are the visual cues that are trying to be communicated by the controls, and then determine whether an opposite visual cue is necessary or not. Then take a look at what type of content your app produces or displays, and then use that as a guidance to determine what type of method to use for how to treat your content area-- whether to go fully dark, whether to make it stay as is, or whether to make it a user option via the app settings.

Then, taking a look at colors, generally, you want to make sure that you're using the three colors that we went over, appropriately, if you have controls that are text controls, try using text link if it's applicable. If you have controls that you want to follow the system accent color appearance, set those to control accent color, and if you have a control that has to stay blue all the time, adopt system blue color. And then Taylor and Rachel are going to go into a lot more detail about color uses, so definitely pay attention to their section. When constructing your vibrancy areas, make sure that you're constructing them in a way that takes full advantage of the vibrant effect blending, so make sure that you're using grayscale colors that are opaque. And if you have areas that need to be knockouts or have opacities, ramp towards black in Dark Mode or ramp towards white in Light Mode.

And then, lastly, make sure that the glyphs that you're using are artistically inverted in order to showcase the intent that the glyphs are trying to communicate to the user as effectively as possible.

Finally, make sure to go to the Human Interface Guidelines to see more design guidance.

And then as well as checking the design resources section, where, by the end of the month, we're going to be making available updated Photoshop, and sketch templates, and kits for you to use.

And with that, I'd like to hand it off to Rachel to go over some details on how to adopt and support Dark Mode. Thanks Thank you, Raymond. Hello everybody. Let's take a moment just to thank Raymond and the rest of the design team for designing Dark Mode. Isn't it awesome? Now Taylor and I will take you through the engineering basics of adopting Dark Mode in macOS Mojave. A while back, Taylor and I were chatting, and we discovered that we were both huge fans of chameleons. And while we don't yet own our own pet chameleons, we thought we'd be prepared by writing an app called Chameleon Wrangler. We did this back in High Sierra, and so we thought, "Hey, let's update it for Mojave." The first thing we did was put our system in Dark Mode and launch our app from the dock. And it didn't really look too dark.

In fact, it's exactly the same between light and dark.

And you'll note throughout this portion of the talk that on the left, when we want to compare, we'll have the light on the left and the dark on the right, so you can compare them side by side. Can't actually run the system this way. It's just for show.

So, what we needed to do was link against the 10.14 SDK and Xcode 10.

We built and ran our app, and voila.

It's a lot darker.

Comparing with light, you can see a lot of things are different and darker, automatically, but there's still some things we'd like to fix up.

So, we'll go into detail about some of the colors. There's a lot of colors.

Let's take a look at this header area that's light green.

We implemented this using a hardcoded color, where we specified our custom RGBA values.

The problem with this approach is that it doesn't change between the different appearances. You're stuck with the same color no matter what the system preference setting is.

Instead of doing it this way, we're going to take advantage of colors in asset catalogs.

You've been able to do this since 10.13-- have colors in asset catalogs, but now you can specify colors for different appearances. So, we've added a dark version of our header color.

Asset catalog colors have several advantages. You can give them meaningful names that describe where the color is used or how it is used, and those are often called semantic names. You can have multiple definitions of the color, as I showed you, with the light and dark versions and also for different color spaces-- sRGB versus P3. And it gives you a central location for defining all of your colors. That makes it easy to go in and tweak your colors without changing any code if needed. So, here's our color now in a asset catalog, and it's called headerColor, because it's the header color.

And let's see how it looks now, using headerColor. Looks a lot better and dark with that dark green. But something becomes obvious, and that's the text. Chloe's name and age are hard to read now against the darker green.

Things looked okay in light, but they don't look good in dark. Well, there, we were using black and dark gray, and those are static colors, also. Not exactly the same as hardcoded, because we're using available colors, but they don't change.

So, instead of using asset catalogs this time, we're going to take advantage of dynamic system colors.

NSColor has many dynamic colors available for you to use with definitions across the different appearances.

And a special thing about NSColor is that the colors are resolved at draw time, which means that the actual RGBA values that are used depend on the circumstances at the time that the color is drawn. I'm going to go through some examples of dynamic system colors now.

Starting with the label colors that Raymond talked about earlier, and I'm showing the dynamic colors on the top half and some corresponding static colors just using black in varying levels of opacity on the bottom half. And, as you can see, in the light appearance, everything looks fine. But over in dark, labelColor looks great still, but the black colors disappear against the dark background. Here's an example in the system in Mail of where labelColor and secondaryLabelColor are used.

The more important text is given the labelColor, and the less important text is secondaryLabelColor. To find out which colors are dynamic, in the Interface Builder popup menu for colors, it'll show you the list, and they've done a really nice job of making those be the dynamic colors.

So, now switching, once we know that, black color and dark gray to labelColor and secondaryLabelColor, this fixes our text, and it looks great in both light and dark.

A little bit more about dynamic system colors.

As Raymond showed you, there are a bunch of colorful system colors-- systemRed, systemYellow, systemGreen are just three examples. And they subtly change for the different appearances so that they look great in both places, as opposed to the static, plain red, yellow, green colors.

Another special thing about using systemRed, etc., is that they will match other uses of systemRed throughout the OS as well as matching on iOS.

So, it's great to stick to these kinds of colors when you have an informational content in your color. It needs to be red or yellow for a warning, for example.

Raymond also talked about linkColor, systemBlue, and controlAccentColor, so I wanted to talk about that again.

LinkColor and systemBlue are very similar but slightly different and use linkColor for actual links to webpages or for going someplace in your app, whereas systemBlue is used for standard actions in your application, or you might even use controlAccentColor if you want to match the system preference, in this case, purple.

You may search through your application code and find all the places you're using color and fix it all up and then still end up with a situation like this, where, for some reason, even though your text switched color, there's something behind it that's still drawing wrong. And if you're stuck and can't figure out what to do, I suggest taking advantage of Xcode's View Debugger. I'm just going to cover this briefly here, and the advanced Dark Mode session will go into more detail about debugging tips and tricks.

So, I can see that light view is actually my scroll view, and I had set in the interface builder to a custom gray color. That's why I couldn't find it searching through my code.

So, I switched it to the default background color, and now everything looks great.

And while we're here on this text view, I'd like to go through some of the colors in play here that are dynamic system colors that also may be useful to you. First, there's textColor, which is switching between black and white; textBackgroundColors switches from white to black; selectedTextColor goes from black to white; and then selectedTextBackgroundColor, which is blue. But you can see it's two different versions of blue, and this is special, because it follows the system preference for the highlight color. And you can see, when the highlight color changes, the selectedTextBackgroundColor changes with it. Now, I'd like to move along and talk about accessibility.

In the Accessibility display preferences, there's the Increase contrast checkbox.

If we turn on Increase contrast mode, you'll see that colors and artwork throughout the system change to make the UI easier to see for people to see with low vision.

Well, now in asset catalogs, we can add colors specially for the high contrast appearances as well. So, here I've added to my header color a version for high contrast light and high contrast dark. And this is how Chameleon Wrangler now looks in the dark high contrast appearance. You'll notice that not only is my header color using that special color that I defined, the rest of the system colors are also specially defined for the high contrast appearances. And this is true for light high contrast, as well. Now I'd like to move along and talk about images.

We'll take a look at the toolbar buttons here.

This chameleon color picker button looks pretty good in light, but in dark, that dark outline disappears against the dark background of the button.

So, we'd like to have a special version of it for the dark appearance, and, once again, we turn to our asset catalog friend and add a version for the dark appearance.

And now it looks much better against the dark button with the light outline.

That's great for full color images. How about these other two buttons? Well, they already look pretty good. We didn't have to do anything, so why? Why are these right? Well, that's because we had made these images template images. To tell you a little bit about template images, in case you don't already know about them, it's important to understand that the transparency of each pixel is maintained, but the color is ignored. You can make the starting image any color you like, that's ignored. It's only the transparency. They can be bitmaps or PDFs.

And here's an example from the OS of the speaker volume image.

The original image is black, and then it has this partially transparent section for the larger soundwaves.

And if we put this image into an NSImageView, it's automatically given the Secondary Label Color, and you can see in light, it's a medium gray, and in dark, it's a lighter gray. And then the partially transparent areas have less contrast against the background.

Another advantage of using template images is that they automatically pick up on the button state. When a button is disabled, the images are dimmer, and that's handled for you if you use template images.

Okay. So, Chameleon Wrangler is now looking pretty good. We got our colors sorted out. We got some of our images sorted out, but there's more to the application than what you see here, so I'd like to invite Taylor to the stage to tell you about the rest of it.

Thank you very much. Thank you Rachel.

Now that Rachel's covered a lot of the fundamentals of having our colors and images react appropriately for Dark Mode, let's first take a look at applying some of those to some more detailed areas of our application. First up is Moodometer, where we can keep track of Chloe's mood shifts throughout the day.

You can see here that the popover's background has automatically adjusted for the Dark Mode. However, the button content is way too dark, still, on top of the background.

Taking a look at our Asa Catalog, we can see that we've prebuilt these images with the color defined in the asset themself. So, we can use the technique that Rachel showed us, where we add a dark variant for those images with a lighter color.

However, it's kind of unfortunate that we're only varying the fill color of these images but keeping the same shape. So, there's probably a better way, and, in Mojave, there is, using this contentTintColor API.

With this, you can create a template image and provide a custom tint color to be used instead of the default appearance sensitive one. That will be used as the base fill color for any of the places that the image appears. So, we can set the content tint color on an NSImageView to tint its image or on an NSButton to tint both its boot image and title.

So, let's take a look at adopting this. The first step here is to convert these to simple template images and remember to set the render mode to be the template effect.

Taking a look at Chameleon Wrangler now, we can see that these images are now getting the default templating effect, which looks great in Dark Mode, but the next step is going to be applying that color. So, we could just pull the color out of the asset, add a dark variant, and set the contentTintColor on these buttons to be that named color. And this button will automatically pick the right variant based on whether it's appearing in the light appearance or dark appearance. However, Rachel also showed us how there are a number of colorful system colors that already have these light and dark variants, which we could use instead. For instance, we could use systemRed, systemYellow, and systemGreen, which, if we return back to Chameleon Wrangler, we can see looks really great and has those buttons pop on top of that background.

What's really cool about this combination is that not only do we get a very specific green color for both Light and Dark Mode, but with the content tint API, the system effects applied on top of that vary based on appearance as well.

As Raymond discussed, in the light appearance, there's a darkening effect on top of that base tint color. Meanwhile, in the dark appearance, there's a brightening effect.

All of these effects are further customized for the increased contrast setting without any changes from our application. So, it's really great that we didn't have to specify all 12 of these colors. And instead, we specified a single one and, thanks to dynamic system colors and dynamic system effects, we got all of this completely automatically.

So, our Moodometer is looking great. Next, we can step over to another type of app where we keep track of very important information about Chloe, such as how stressed she's feeling or more importantly, what's her favorite type of berry? We can see here that this already looks great, because we are using stock Cocoa controls, which automatically adjust for Dark Mode.

We can see how it reacts to the accent color feature that Raymond talked about by opening up system preferences, changing the color to a nice chameleon striped yellow, and returning back to Chameleon Wrangler.

We can, again, see that the built-in controls automatically adjust to that yellow accent color, including the focus ring and highlight color.

However, we can notice that our custom tab bar has remained blue, even though we've changed the accent color.

Because this blue doesn't really have any significance for our application, we probably want it to be following that accent color. Like Rachel talked about, we have a few different colors that will follow the users' accent and highlight color selection.

New in Mojave is a control accent color, which you can use to directly mimic the accented areas on system controls, such as the sides of popup buttons, default push buttons, or the selected segment of a segmented control.

There's also selected content background color, which is what you see in the background of selected table rows, and you can use to indicate custom selection.

And selected text background color is exactly what it sounds like. So, going back to our app, we can see that we're using system blue color for this custom tab selection, and, instead, we can just swap that over to using controlAccentColor.

The next problem here with the tab bar is a little more subtle.

If we bring our cursor over and press down on it, we can see that we're getting a darkening effect instead of the brightening effect that we should in Dark Mode.

This is because we are taking that base color and just applying a constant 30% darkening effect to it, assuming that would look fine in the light appearance.

Instead, we want to describe something that basically this color is being pressed, and that semantic description can carry whatever effect it needs to in the light versus dark appearance. So, with the new system effect API in Mojave on NSColor, we can describe that exact semantic.

We can take our base color of controlAccentColor, say that we want to get the pressed variant, and it will react appropriately in both the light and dark appearance.

There's one more area of our application where you can see the accent color, and that's in this photo browser where we draw a selection ring around the selected photo. Here, we were using the selectedContentBackgroundColor, and that, again, automatically adjusts based on the user's selected accent.

Let's open up one of these photos and take a look at a nice, big, beautiful photo of Chloe. The first thing that stands out is the fact that the background has not adjusted for Dark Mode. It's still using its light translucency effect similar to a hardcoded color.

This effect is provided by NSVisualEfffectView, which provides the translucent blur materials you see across the system. For instance, there's the sidebars which blur onto the desktop and other windows behind it, as well as things like the title bar, which blur the content that's scrolled underneath.

NSVisualEffectView also enables the vibrant foreground blending, that Raymond talked about, by taking a grayscale color plus a Blend Mode and making it really pop on top of these backgrounds.

The advanced Dark Mode talk is going to go into a lot more detail about how you can use those blend modes effectively.

Turns out that a lot of places automatically get these blur materials for free. For instance, every titlebar of an NSWindow will automatically have a titlebar material showing onto the content behind it. Source list table views and sidebar style split-view items will automatically get a sidebar material showing onto the content behind the window. For custom UIs it's pretty easy to build these custom effects ourselves, as well. But the most important quality of them are the material that you choose to have them represent.

We have a few nonsemantic materials, which, like hardcoded colors, just describe the exact visual quality of the material and not the intent of what you're trying to represent.

These will not be adjusted for Dark Mode and will stay with that exact quality.

However, we have a number of semantic materials, as well, which allow you to describe what type of UI your custom UI is intending to represent. For instance, for a custom menu like UI, you would want to use the menu material. And these not only adjust for Dark Mode, but guarantee that UI to always match those materials even when the system changes in the future.

We've had a few of these in the past, but in Mojave, we have several more so that you can make sure to really tailor your custom UI to match the material it needs to. Jumping back to our photo here, we can see that we were using the mediumLight material, because we were trying to represent Quick Look style popover windows. And instead, we can just simply swap that over to the popover material and get the exact effect we want to in Dark Mode. Now, this isn't the only area where we get a unique material showing in the background of our UI. Like Raymond talked about, there's this desktop tinting effect that's shown here in the background of our photo gallery. We're getting a little bit of that blue from that desktop behind it, creating this really visually harmonious result.

It's a lot easier to see on top of a more vibrant background, such as these beautiful flower pictures.

There's three different variants that have semantics with these background materials. There's the window backgrounds that we see on the backgrounds of generic windows; Under Page Background, which appears behind document areas such as in Preview or Keynote. And perhaps most commonly is the Content Background material, which is white in light appearance and, of course, dark in the dark appearance.

In fact, all of these are now dark in the dark appearance but also have that wallpaper tinting effect. The great news is that it's really not hard to get these effects. For the most part, it comes completely automatically by using system views. For instance, the default backgrounds of every window has that window background material built right in.

In addition, views such as NSCollectionView or NSTableView also automatically come with the content background material built right in.

We've seen a number of places across this system that were actually able to improve their Dark Mode support by deleting an override of these default colors that these views have.

If you want to customize beyond the default color that these views have, you can explicitly set a variety of system colors as their background color to get the exact material effect you want.

One really important note here, though, is that if you were to read the RGB values of these colors, they would not include the desktop tint.

This is because, as Raymond mentioned, this tint is extremely dynamic. As you move your window around on screen, that's getting updated asynchronously to the applications rendering itself, creating a really nice experience as the user is moving around windows.

So, jumping back to Chameleon Wrangler, we automatically got this content background because we just use a stock NSCollectionView.

In the vital section, we got that window background material showing through because we had nothing opaque covering it up.

However, in our notes section, where we have this awesome custom stationary, we have a light grey background that isn't appropriate for Dark Mode and hasn't been adjusted with that under page semantic. We can open up Interface Builder and see where we're setting up this background drawing view and see that, indeed, we are filing it with a custom gray color.

And pretty quickly in IB, we can change that to using the Under Page Background color that represents that semantic and immediately see that we'll get the right result, making it look just at home with the rest of the document apps in Dark Mode. The next thing that kind of stands out here, though, is the dark foreground on top of light background of our stationary and document area. And because this is a WYSIWYG editor where we, as users of Chameleon Wrangler have complete control over the colors, images, and fonts seen within it, we expect this to stay the same as a light appearing document.

However, there are a few subtle details that don't seem quite right. For instance, the text highlight color is still getting the dark variant of the text highlights, as well as the autocorrect bubbles have the dark appearance, which really clashes with the light appearance of our document.

We, basically, want to have everything in this area revert back to the light appearance, and we can do that using NSAppearance. It turns out that NSAppearance is what's been providing the magic of having light versus dark variance automatically switch in Dark Mode this whole time.

You can conceptualize NSAppearance as a little bundle containing all of the colors, materials, images, and control artwork that you see across the system. Now, when your application does something like request to draw with labelColor, what that does is it looks up in the current appearance for what the exact RGB values should be.

The same is true for control artwork or the different material effects. Now, what's new in Mojave is the dark appearance, which our designers have meticulously crafted with redefining everything across the system.

When the system is running in Dark Mode, what happens is that the dark appearance gets applied to your application instead of the light appearance. So, when labelColor goes to draw itself, it references the dark appearance as white value instead of the light appearance as darker value.

The same is true for all of those materials. And these aren't the only materials in the system. Right, these aren't the only appearances in the system. There are also the high contrast appearances, which get used when the accessibility high contrast setting is turned on, these will get applied to your application instead. And there's actually even more. There are the vibrant appearances that, again, completely redefine all of these colors that appear in sidebars and titlebars. And the advanced Dark Mode talk is going to go into more detail about how you can effectively use the assets that come out of those vibrant appearances to really make them stand out.

Now, by default, the appearance of your application will follow the system. However, you can explicitly override it by setting the appearance property to whatever you want. So, here we have Chameleon Wrangler in Light and Dark Mode, and we can see it's following the system, but as soon as we set its appearance to always be darkAqua, we can see it's always getting that dark appearance.

The inverse is true by setting the explicitly light appearance, and, of course, setting it back to nil will have it return back to the default behavior of following the system.

Now, we know that after a lot of you see your apps running in Dark Mode, you're going to be really tempted to have your app always be dark, because it's just going to look so good.

But like Raymond mentioned, it's really important to keep in mind "When it is appropriate to have an always dark app?" This should be generally reserved for very media focused apps like QuickTime player or professional color-sensitive workflow apps, where it's important to eliminate all of the light behind the content.

And, in general, it should be left up to a choice for the user.

So, in general, this is the system preference. Some of you maybe already have a dark theme for your application controlled via app preference, so your first step would be to tie that back to the system preference so the people using the system can have a consistent experience. And in some ambiguous cases like Raymond mentioned, there may be some additional need for an in-app preference, such as in the mail case, but for the most part, the system preference should be exactly what users go for. If you do decide you need to have an always dark application, it's really important to not to use the Vibrant Dark appearance on the entire window, because that's not appropriate for the opaque window areas of the application and are really only intended for sidebars.

Instead, you want to use the Dark Aqua appearance if you want to have that always dark look.

In addition to be able to be set on the window as a whole, you can also set it on an individual window or view scoping, and that's inherited by all of the views contained within it. For instance, here, we're setting the sidebar to always have the darkAqua appearance if we want to experiment with something like that. And all of the text and images within that also get that dark styling, but we can also use this to fix the problem we had before with our text area.

We can see here that we actually want this entire document area to remain having a light appearance, and so by setting the lightAqua appearance, we can make sure that the text highlighting color gets the correct appearance as well as the autocorrect bubble inheriting that light appearance as well.

However, in addition to be able to be used for some really cool effects, it can also lead to some hard-to-debug situations. For instance, here, we're using the vibrantLight appearance explicitly on our table view, and that looks perfectly fine in the light appearance, where it's actually already inheriting the vibrantLight appearance. In Dark Mode, this quickly becomes a very visible problem. We can see that the text and images inside that table view are now inheriting that vibrantLight appearance and look bad on top of that dark background. So, for the most part, we just want to remove these explicit overrides in places where we really do not intend to have an always light appearance.

This can also happen in Interface Builder, where, at the very bottom of the Attributes Inspector, we've accidentally overridden the appearance for our outline view to always be the light Aqua appearance. Here, the fix is simply to change it back to the inherited style so that it can make sure to follow Dark Mode when that's turned on, so do be sure to check for all of those.

At this point, Chameleon Wrangler's looking really great in Dark Mode.

But kind of an understated thing here is that, at this point, we've written 0 lines of code specific to Dark Mode.

The types of changes necessary for being a great Dark Mode citizen is that you need to make sure to express the ideas semantically rather than literally. So, for instance, these same sets of changes allowed our application to not only look great in Dark Mode but also in the light appearance. Adding support for things like the accent color as well as making our label colors more consistent with the rest of the system.

Further, these same sets of changes needed to be great in Dark Mode are also the same sets of changes needed to have great support for the high contrast accessibility setting. So, to reiterate what those steps were, the first and foremost was linking on the 10.14 SDK using Xcode 10. For a handful of apps that already use system controls and system colors, this is the only step that's going to be needed, and it's already going to look great in Dark Mode. For the rest of us, the next step is to audit our app for the use of static colors, non-template images, and nonsemantic materials, and replace those as appropriate. For instance, this might be using a system color, a semantic material, or, in some cases, defining a custom asset catalog color or image. And, again, it's important to keep an eye out for those accidental appearance overrides.

The advanced Dark Mode talk is going to go into a lot more detail here, including how to correctly use NSAppearance, how to do custom drawing and effects within NSVisualEffectView, how to make sure all of the myriad of ways you might be drawing custom views work correctly in Dark Mode. Some tips and tricks for using View Debugger and Interface Builder to really polish your app. And because we know that a lot of you and your apps' fans are really going to be wanting to have Dark Mode as soon as possible, we want to make sure you can do that without sacrificing how far you can back deploy. So, in general, a lot of these features are available for a year or more, but the advanced talk is going to go into details about how to take that even further back. We have a few Cocoa Labs, but I also really want to point out the Dark Mode Lab, where, in addition to engineering support, Raymond and other members of the design team will be there to help answer any design questions you might have, as well. So, that's a really special treat that I encourage you to take a look at. Thanks for staying until 6:00 today, and have a great rest of the WWDC.

[ Applause ]