Good morning

. Thank you. I'm Chris Dreessen. This is Touch Bar Fundamentals. If you have no idea whatsoever what Touch Bar is, I'm not sure how you got here, but I'm glad you're here. Likely most of us are a bit more familiar with Touch Bar, but we may not have had a chance to actually play with it. So, let me orient you to it.

So, we have here a picture of a MacBook Pro and in place of the F keys you might be used to, we have this thing we call Touch Bar. And this is an interactive input and display device. And let me familiarize you with these parts. On the left, we have the escape key, which should be pretty familiar to everyone.

And on the right, we have this thing called the control script. And you can go ahead and disclose the control strip if you want. And you'll have basically the old media functions the F keys offer. And you can use this the same way you always have, button presses. You don't have to disclose it thought.

You can actually just go ahead and use it in its collapsed form. And when it's its collapsed form it has some neat functions too. We can just do like a glancing swipe over the volume button and adjust the volume directly. So, there's a lot of conveniences here for adjusting certain system functions.

But, that's not really the most interesting parts of Touch Bar, the most interesting parts are between the escape key and the control strip. And that's where your application content is going to go. And so, let me show you what some of our system applications have done with this.

So, here we have photos. And this is just browsing the photos library. And we can actually go ahead and scrub through our photo library here. It's just like in iOS with direct input with our finger, so we plop our finger down on the Touch Bar and it's just tracking it.

We also have momentum swipes there if we want to browse through it quickly. If you go to edit a photo, this is the photos crop and rotate tool. And they have this rotation thing in the middle of the Touch Bar and it tracks your finger directly, which is pretty fun, because it's sort of like actually rotating a picture on a table.

Finally, photos also exposes filters. So, we can scrub and swipe through our filters here. And this is an interesting use of Touch Bar, because normally if we were using a mouse or a track pad, we'd go ahead and look at our photo and then look at the filters section and move the mouse or track pad to that, select the next filter. And with Touch Bar we can actually keep our eyes on the cat.

Here's QuickTime Player. QuickTime Player has a scrubber control directly in the touch bar, so we can move a movie back and forth, it's pretty neat. And they've also gone ahead and exposed a similar control for trimming, so we can adjust the beginning and end of a movie that we've recorded. Something I'd like to point out about QuickTime Player here, is that QuickTime Player didn't write any code to do this, this is all inside of AVKit and AVPlayer view. So, if you're already using AVKit, you've probably got this functionality for free, congratulations.

Let's look at text edit for a moment. So, everyone's familiar with QuickType on iOS. And We've gone ahead and brought QuickType over to Touch Bar on macOS, and as everyone know QuickType is a great short fiction writing tool. So, if we go ahead and write a short story here, 'the fact is he has to;' this is not the best short fiction I've read. But that's okay, because Touch Bar gives us a way of spicing that up. We also have the emoji picker.

And, let's go ahead and spice it up a bit. We can browse our emoji here and say I laughed until I cried, I was turned into a frog, and I'm happy I'm no longer a frog. So, we've added some nice human emotion and drama to our story, all thanks to Touch Bar.

TextEdit of course, is a text editing tool also, so we can collapse the QuickType options here and bring up text formatting controls. And maybe the most useful thing is to make it bold, or italic, or add some color to it and pink feels right for the story where I'm turned into a frog, and not a frog again. Anyway, let's never speak of that.

Something else I want to point out about all these examples I've show you is that they're customizable. We have a customization panel for Touch Bar. And you can rearrange items in it. You can add items from the customization panel on the screen or remove them from the Touch Bar.

And this is important, because every user's workflow is a little bit different. Some are doing different things with your application, and others just prefer to use the computer in a different way. And by enabling customization, you can give users the exact experience they want. And I'll teach you how to do that programmatically in just a little bit.

Let's cover some of the technical details and some of the implications that come with that. So, the Touch Bar is the beautiful P3 retina display. It has a nice P3 color gamut, great blacks, wonderful contrast. And that means that our assets we include in our applications don't have to cover as much as what we do on the main screen.

Additionally, it's a true multi touch device, which means we can actually track multiple fingers. And that affords us some new options for what sort of controls we might make. You're going to hear this a lot about Touch Bar, that it's context sensitive. And that's very neat in terms of enabling the user to work with functions in the application that are appropriate, but it has implications for event handling, because the context in the application might change, which the user is using the Touch Bar, and our controls need to react to that.

And finally, we actually go ahead and take some care to match the key taps and glyphs on the Touch Bar to those on the physical keyboard, and we do that by watching the ambient brightness, and knowing whether or not the keyboard backlight is on. But this has implications for how we might draw custom controls. And we're not going to go into detail on any of those implications in this session, but we do have a session later this afternoon that will cover all these topics.

So, I'm assuming that once you're done here, maybe even before that, you're going to be really jazzed to add Touch Bar support to your application if you haven't already. But when you're coming up with your UI's there's a few things to keep in mind. And the first of them, the prime directive of Touch Bar is that the Touch Bar is an input device. It's meant to be interacted with by the user. It's not supposed to be displaying things. So, no status indicators or stock tickers.

The next thing we should keep in mind when making our Touch Bar UI's is that we don't want to put functionality in the Touch Bar that doesn't exist anywhere else in the application. It's great to have null and fun Touch Bar UI's, but it shouldn't be the only way of accessing functionality. And there's a good reason for a lot of that, and that's that not every user has a Touch Bar, so if you only put something in the Touch Bar, you're going to be losing out on functionality for a lot of users.

And finally, this is almost a side effect of saying the Touch Bar is an input device. While we want creative beautiful UI's in the Touch Bar, they shouldn't be taking center stage. The content the user's working with on the main screen should always be their focus. So, the Touch Bar shouldn't be distracting.

With that out of the way, we're going to go ahead and cover the core classes that let you use the Touch Bar in your application. We're going to cover how the responder change is integrated with these for discovering what context sensitive functionality to display. And then, we're going to go ahead and take a deep dive on one of those core classes and show you most of what it can do. So, let's start with the classes.

The first class is of course NSTouchBarItem. And that plays with NSTouchBar and NSResponder. And let's just take a closer look. This is a mockup of the mail Touch Bar I've made. And everything I'm highlighting here, is an NS view, or NS control, or NS button. They're all things you're very familiar with because Touch Bar is reusing the existing view functionality we've been using in our Cocoa apps for very long time. There's a few things though that Touch Bar does, that view isn't prepared to do. So, we need some way of adapting that. And that's what this NSTouchBarItem class does. So, it binds a view to the Touch Bar.

NSTouchBarItem itself is a very basic class. It's intended to be sub classed and that's probably not something you're actually going to have to do. Because AppKit includes about half a dozen existing Touch Bar subclasses that will handle a lot of the needs you're going to have. And finally one of the most important features of the NSTouchBarItem class is that it has an identifier that uniquely identifies that item and functionality within its NSTouchBar instance.

So, let's talk about NSTouchBar itself. The most important thing is that it has an array of those item identifiers that identify the items. And this is important for resolving what functionalities goes into the Touch Bar to the views used to display it. Let's take a quick look at a code snippet.

So, here we're going to go ahead and just declare some identifiers for a shark and sea turtle. Usually when you come up with identifiers for our code, we recommend using reverse DNS, but these are a little bit more legible. And once we have those identifiers, we're going to go ahead and instantiate a new NSTouchBar and just set the default the item identifiers array. And this let's AppKit know what sort of semantic functionality we're putting in the Touch Bar.

What we're going to cover now is how AppKit resolves that. And there's two ways we do this look up. There's two ways we find NSTouchBarItem from the item identifiers. And the first is a property on NSTouchBar called template items. And this is just a set of items. So, if we go back to some code snippets, this is what we had before, exactly the same, and we've added some. So, here I'm using an NSCustomTouchBar item class for the shark and turtles respectively. And this is one of those subclasses I mentioned. And we're just setting the view of these items to an NS button.

And we go ahead and we make the title, you know the shark emoji or the turtle emoji. You'll notice we're using the NS button convenience constructor we introduced in macOS 10.12, and that's important because these convenience constructors will configure the buttons to be appearance sensitive to use the right styling and font.

And if we build an NS button directly, we may not get that functionality. So, this is a big time saver. But, finally after instantiating these items, we're just going to go ahead and stuff them in the template item set. And if we do all of this, we're going to wind up with the Touch Bar we see at the bottom of the screen, with our shark button and our turtle button.

Something I'd like to mention, if you go ahead and copy and paste the code on the slide into a Swift playground, XCode will go ahead and preview the Touch Bar items we construct and the Touch Bar itself. And this is a pretty useful way of rapidly prototyping your Touch Bar UIs.

So, that's template items. Let's go ahead and cover what we can do with the delegate. So, there's a single delegate method in the NSTouchBarDelegate protocol. And that's Touch Bar, makeItemForIdentifier. And it's pretty simple. If we take a look at this code here, this is exactly the same as the template items case.

What's different is we've structured it in a switch statement, so we can go ahead and conditionally create a new item when AppKit asks for one of our specific identifiers. AppKit cahces the result of this method. So, you really can just treat this as a factory and make a new instance each time. You don't have to maintain a back pointer yourself, unless that's useful for other reasons.

Something else that's important to mention is, you know I've covered customizability a little bit, and let's take that Touch Bar we've made and make it customizable. So, that involves adding a few things. The first bit is actually this top line, where we go ahead and tell NS application to set isAutomaticCustomize TouchBarMenuItemEnabled. That's a mouthful, but it's actually a very simply way of handling this. If you set this to true, NSApplication is going to go ahead and create a menu item for you automatically that will show and hide the customization panel.

You don't have to use that. NSApplication has a method to show and hide it explicitly and you can wire that up to your menu item if you want a little bit more control. But with that out of the way, let's look at the bottom of the code in this slide, where we set the customization identifier. And in this case, I'm just making up an ocean animal identifier. But it's important to set this, because this is the token which enables persistence of the Touch Bar configuration across launches of your application or reboots of the system.

And there's one other important step for enabling customization, and that is to set this customizationAllowedItem Identifiers array. And we're just going ahead and set it to our shark and sea turtle again. But setting this allows the customization panel to know which items can be added and removed. If we do all of that, we can bring up the customization panel and we'll see exactly this, the defaultItemIdentifiers array is translated faithfully to the default set of items on the left. And the individual items from the allowed item identifiers are shown on the right. This is kind of a boring customization panel and we can spice it up a little.

So, here's a whole menagerie of ocean animals. Something I want to mention, and it will come into play with deciding whether you're going to set the template items on a Touch Bar when you create it, or whether to use the delegate is by default we were only showing the shark and sea turtle.

And there's a lot of applications where your default functionality in the Touch Bar is going to be a very small subset of the total functionality you can add through customization. By using the delegate, users who don't bring up the customization panel aren't going to pay the CPU time of creating new items.

Something else to mention here is you may have a situation where you're building a Touch Bar UI and there's some functionality you want to be there all the time, you don't want the user to be able to remove it in customization, and if you have a case like that you can set the customization required item identifiers array.

And in this case, obviously, the sea turtle is critical for the function of our application. So, we're going to prevent it from being removed. So, that kind of covers how to make instances of NSTouchBar and how to facilitate item lookup by the item identifier, through the template items and delegate methods. But one of the things we're missing is how the applicant finds those instances of NSTouchBar. And I big part of that is the NSTouchBarProvider protocol.

And it's a fairly simple protocol. It's just exposing a read-only Touch Bar property. NSResponder itself implements this protocol right out of the box. And we'll cover that in just a second. But sometimes it's useful to attach a Touch Bar to your application delegate, or window delegate. And neither of those is likely to be a subclass of NSResponder. So, let's see how you go ahead and implement that protocol yourself.

This looks like a lot of code, but really we're just using a Swift lazy variable here for the Touch Bar property. And the first time the Touch Bar property is accessed, Swift is going to go ahead and run this block to instantiate our Touch Bar. All the code to create the item in bar and stuff we looked at in the previous slides. Something else to mention is that AppKit key value observes this property. So, if you feel the need to replace your Touch Bar wholesale, we'll notice that sort of change.

Let's look at how NSResponder implements this. First, it exposes that Touch Bar property as a read-write property instead of read-only. And the significance of that is that you can set instances of NSTouchBar on various pieces of your application. On the responders, you have in your windows. Like views and view controllers, and window controllers. And that's really neat because you don't necessarily have a subclass for each and every one of those controls. If you are making a subclass of a control, or really any NSResponder, NSResponder also exposes this makeTouchBar method.

So, makeTouchBar is pretty simple. The first time the Touch Bar property is accessed on an NSResponder, it's going to call self makeTouchBar and run this code. And we just have to return a new Touch Bar for it. A lot of the system controls and system frameworks, which expose functionality use this method to provide it.

So, I mentioned that NSResponder has a read-write Touch Bar property and you can set the touch bar. And one of the most important clients of that is actually Interface Builder. So, let me show you how to build a Touch Bar UI from Interface Builder. If we go ahead and start with a new story board, we have a window controller seen here, and we can filter the object library to show us Touch Bar controls.

So, if we just check the object library, here an instance of NS Touch Bar and we can drag that onto our window controller. And now we have an empty Touch Bar to play with and going back to the object library, we can go ahead and see that there's dozens and dozens of preconfigured controls and Touch Bar items we can just drag into the Touch Bar. And from here, we can wire these items up with ID connections, or bindings or whatever. And it's actually very possible to write Touch Bar apps that are perfectly functional and useable without ever writing a line of code for it.

So, that covers creating instances of NSTouchBarItem. Let's see how this fits into the bigger responder chain and how we discover all of these individual Touch Bar instances. So, a refresher, a responder chain is made up of instances of the NSResponder class. And one of the most important properties of the NSResponder class is this next responder property it has. And that just points at another responder.

But it basically means that given a responder, we've anchored an entire chain of responders capable of handling events and actions and things. And AppKit uses many different responders as the anchors for chains for handling keyboard events, and actions and kit testing and routing mouse events and things, but let's cover how keyboard event works. Because Touch Bar is part of the keyboard.

So, we're going to have an NSEvent handed to us by the system, and that's going to go over the NSApplication. And NSApplication is going to say what do I do with this keyboard event. And most NSApplications are going to say do I have a key window? Okay, it gets the keyboard event now.

And the key window meanwhile is going to have the same question, what do I do with this keyboard event. Every NS Window had a property called first responder and that's designating where the responder chain starts for keyboard events and actions and things. So, the key window is going to go ahead and say, all right let's send this event to my first responder, like in its key down or key up method.

So, the first responder meanwhile it's interesting, because that's where it's anchoring the responder chain, where we're going to be handling this as a responder method, not just generic event routing. But it's going to have a decision, do I handle the event in key down, or do I call super and let it pass that to the next responder. So, let's say it passes it to the next responder. Usually the first responder will be a view, the second responder will be a super view.

It will make the same choice. And these days, use and view controllers tend to be [inaudible] in the responder chain. So, pass it up to a view controller, have the same choice handler call super. It doesn't handle it. It might even go and reach all the way back to the initial window that routed the event in the first place. And that, as part of the responder chain, can make the same decisions whether to handle it or pass it on.

And that can percolate all the way back up to the application. So, that's how we handle keyboard events. Touch Bar is part of the keyboard. So, it also turns out these are all the places we can attach instances of NSTouchBar. And we search them in exactly the same order the keyboard event was routed through the responder chain.

So, one question you should be asking is hey, I notice you have five instances of NSTouchBar here. How do you go from that to one Touch Bar on the device. And I'm going to cover that in just a second. But first I want to make a small note about views and views controllers.

You're probably going to be attaching a Touch Bar to a view controller at some point, making your application. And you'll run and test this. And you're going to see that your Touch Bar doesn't show up at all and you'll think, oh, I guess my view controller is not in the responder chain. And you'll go ahead and look at your view controllers view and see that its next responder is indeed your view controller.

And what's going on here is that while your particular responder chain is set up correctly, it's not anchored in the first responder of the window. And that's often because the first responder of the window has to return true for the acceptsFirstResponder method. So, if you wind up in this situation, it's really easy to subclass NS View or whatever your first responder is to accept first responder and make a valid responder chain anchored at the first responder.

So, let's get back to how we're going to handle multiple NSTouchBar instances on this. The easiest thing to remember is that the responder, with an NSTouchBar closest to that first responder, so closest to the keyboard input, its Touch Bar is going to win and take over the whole thing.

Calling back to earlier where I mentioned that AVKit and some other system frameworks provide support, you're probably thinking that they're likely going to provide support in NS Views which are going to be closer to the first responder than your window controllers or application delegates might be. So, we need some way of sharing the device Touch Bar across multiple instances of NSTouchBar and we have a way of doing that. And that's accomplished with this special item identifier, called the otherItemsProxy.

I say it's a special item identifier because you don't have to create any item for this. You don't have to put it in your template item set, you don't have to handle that identifier in your delegate and make item for identifier case. But when you go ahead and include other items proxy in your default item identifier array, when AppKit is harvesting NSTouchBar from the responder chain, it will go ahead and replace the otherItemsProxy with the items from responders closer to the first responder.

So, let's look at that in action. Here's an example of mail. My keyboard focus is on the recipient's field. And the recipient's field is providing suggestions for who I might to send the email to. I also have this send button on the left side of the application section of the Touch Bar.

If I were to change my keyboard focus instead to the composition view in the window, I have a bunch of text formatting controls and an emoji picker. But I still have that send button. And the way this breaks down is that mail's composed window controller has a Touch Bar with a send button and an otherItemsProxy.

And the recipient's field is providing the candidates. And the recipient's field is very close to the first responder, so it's going to get first shot at that. But the window controller including the otherItemsProxy means we can merge those two Touch Bars. Likewise, for the composition view, the window controller is exactly the same instance, it's just the responder chain anchored at the first responder includes the composition view before the window controller.

Something else to mention is that this is completely compatible with customization. We use the otherItemsProxy to build the default set of items, like you'd expect. And we go ahead and union the allowed items from the eligible touch bars. So, we can see we can customize the send button in mail, even though it's provided by a different responder than the formatting controls.

You might think, hey the otherItemsProxy sounds pretty great for the reliable functioning of my Touch Bar stuff, and you'd be right, but there's a few cases where you do want to omit it. And if we go back to mail, but close all the windows, we're going to see that we have a new viewer window button in the Touch Bar.

And that's provided by the application, but it omits the otherItemsProxy. When we go ahead and bring a window up that has Touch Bar content it's going to be closer to the first responder, and the lack of the otherItemsProxy in the farther out Touch Bar means it gets replaced entirely.

So, there's another sort of special item identifier I want to cover and those are spaces. So, if you see here, we've made a mockup Touch Bar and we have a shark item and an angelfish. And the angel fish probably isn't that comfortable being so close to the shark. Thankfully, the shark is facing the wrong way so the fish probably isn't on the menu yet.

But we can go ahead and give the angelfish some breathing room. And we can do that by adding a fixed space small item identifier in the default item identifiers array in between the shark and angelfish item identifiers. And we don't have to settle for small, we can also use a large one and give it a little bit more space. And it's useful to use these instead of hard coding your own space, because these are our system defined values that may change from release to release, but they also give your app an appearance similar to other apps on the system.

We don't have to stop with fixed spaces though, we also have a flexible space identifier. And the flexible space is interesting in that it's going to push the adjacent items as far away from each other as they can get. So, in this case, the angelfish probably feels a lot better with that flexible space between it and the shark.

You might be thinking you could put flexible space on two side of an item to center it. And that's a very reasonable thought. If you do that, you're going, actually, let's say we do that with our purple circle. We put flexible space on the left and right sides of it.

The circle is centered within the application section of the Touch Bar, which might be what you're going for. But you might also want to be centering that item on the actual device, and it's not there. We're a little bit to the left. So, we can fix that by using and NSTouchBar property called the principal item identifier.

And we can go ahead and set a Touch Bar's principalItemIdentifier to the identifier of any visible item, and it's going to go ahead and actually place that item in the center of the device. So, if we go ahead and look at this example, all the code in here is stuff we see in our previous slides except this last line where we set the principalItemIdentifier.

And by setting to the shark identifier, we go ahead and move and the shark to the middle of the Touch Bar and lay out the items left to right like we did in other cases. If we were to use the turtle instead, the shark winds up on the left side like it would normally, and the turtle is centered on the device.

And this plays really well with flexible spaces and other things. Son you can make some nuance device with that. And there's additionally types of NSTouchBar items subclasses that modify the behavior of the principalItemIdentifier. And John is going to go ahead and cover those as we take a deep dive into NSTouchBar item. Welcome John Tegtmeyer.

So, Chris gave us an overview over the NSTouchBar API and how it's tied to the responder chain allowing us to provide context sensitive controls to our users. He also eluded to this NSTouchBar item object, which is the wrap around all the views in the Touch Bar. Now, AppKit provides a lot of subclasses of this item, and they all offer some really unique, very cool functionality. So, I'm here to give us a deep dive into those items.

NSTouchBar item is a base class of everything that we'll talk about today. That means the properties on this will be inherited by the subclass. The first thing that all Touch Bar items have is a unique identifier. This is what NSTouchBar will use when looking up your item through the template items array, or through the delegate.

Items also have a view or a view controller. This is what's actually presented to your users. And if you're using the view controller, this is a good opportunity to lazily load your views. We also have a customization label. And this is the string that's presented in the customization UI. And describes what your control actually does.

I hope you notice one thing that we don't have here is an explicit minimum or maximum size property. That's because, unlike tool bar item, which does have these explicit properties Touch Bar items are actually measured using constraints. That means if you're using something like an NS button which has an intrinsic content size, it will automatically be sized to fit its title and its image.

You can also choose to use inequality constraints to set up minimum and maximum sizes. And AppKit will automatically size you view based on how much space is available in the application section. And you can find out more about how items are sized at the "Advanced Touch Bar Talk" later today.

Now, as I mentioned, AppKit provides lots of subclasses of this item. And we'll talk about each of these. We'll talk about the custom Touch Bar item, pop overs, sliders, group item, as well as a few bonus topics at the end. So, let's get started with the custom Touch Bar item.

Now, the custom item offers rewrite properties on everything that we just talked about on the base class. That means you can simply set the view of the view controller rather than subclassing your item. This is likely the item that you'll use if you want to show something like a button or a segmented control. Anything that you're familiar with through AppKit, or custom container views.

Now, this is also a really great opportunity to use some of the convenience constructors that we introduced in 10.12. Let's take a look. In this example, we're going to create a simple button for Touch Bar. We're doing that by creating a custom Touch Bar item and providing a unique identifier.

And then we're going to set the items view to be an NS button using the title target action constructor that we saw earlier. And as Chris mentioned, this will assign the correct font and the correct appearance to this button. So, we have a great looking button that's ready for Touch Bar in two simple lines of code.

This is also true for a more complicated control. In this case, this is a segmented control. Segmented control also has a convenience constructor. And so, again with two lines of code, my spacing for clarity, we have a great looking control that's ready for Touch Bar with the right appearance and the right font.

Next, let's talk about popovers. Popover item is really cool because it allows you to provide extra content to your user, but only when the user requests it. Popovers have two parts. The first is the class representation, which is the view presented to your user when the popovers close. And the second piece is the popover's NSTouchBar, which actually takes over the application section when the popover is open. And this lets you use things like the principalItemIdentifier, or even enabling customization. Let's talk more about the class representation.

AppKit will provide a default on for you and you can customize the way it looks by using the class representation image, or label properties. And you can see an example of this in the list in alignment popovers and the formatting controls. You can also choose to use something more custom.

Mail chooses to use a segmented control. And if you tap the main portion of this control, it will immediately move a message to the suggest mailbox. But if you tap the arrow, it will show a popover with additional suggestions. This is actually really easy to achieve by providing your own view for the class representation and then using the show popover and dismiss popover methods.

Popovers also have two interaction models. First is touch and show. This happens when the user taps the class representation. The popover's opened and it's sticky allowing you to make multiple selections. It's only closed when the user taps the closed button. The second interaction model is press and hold.

And this happens when the user presses and holds on the class representation. The popover's open directly by the user's finger when possible and immediately starts tracking their input. It's closed when the user lifts their finger and a selection is made. But you'll notice that in these two examples, the popovers actually showed different content.

Touch and show showed several controls whereas press and hold only showed a single segmented control. And that's because press and hold is tracking the user's finger the entire time. And so, it's best to leave that kind of interaction to a single control. In this case a segmented control, or even something like the slider item.

This is easy to achieve because popovers actually have two different NSTouchBar properties. One for the touch and hold popover and another for the press and hold. Press and hold, if you do not provide an NSTouchBar for press and hold, press and hold will not be enabled. It is possible to provide the same NSTouchBar object for both of these properties and that will work just fine. But as I mentioned press and hold is best left reserved for single things, single items like a segmented control or a slider item.

Speaking of the slider item, let's talk about it. Now, you might be thinking what's the difference between a slider item and a custom Touch Bar item with an NSSlider as its view. Well, let me explain. Sliders have a few different parts. First we have the slider itself. Then, we have these new value accessories, which are images and are actually intractable. You can tap on them to increment or decrement the value of your slider. We also have a label.

This can make it extra clear to your users what this slider is actually controlling. And it's really useful if you have multiple sliders in your UI. As I mentioned these make really great content for press and hold popover. And that's because the immediately start tracking the user's finger, even though the touch is offset from the knob of the slider. That means the user can immediately start interacting with it and not go searching around for the knob for interacting with the slider.

Let's take a look at what this actually looks like in code, though. First, we're going to create the item itself. We're going to provide a unique identifier. Next, we're going to assign it minimum and maximum value accessories and we're going to use images that AppKit provides. And lastly, we're going to assign a label, because maybe we want multiple sliders in our UI. But you'll notice that the slider is actually taking up the entire application section. Well, that's because sliders do not have an intrinsic content size. They're happy to be whatever size is available in the application section.

You can change this by adding a constraint to the slider and AppKit will check that and automatically remeasure and resize the item. But notice that we're doing this on the slider itself, and not the slider items view and that's because we have a label here. And if we change localizations the length of this string will also change and we don't want to cause clipping.

Next, let's talk about group Touch Bar item. Group item is neat because it allows you to group multiple Touch Bar items into a single NSTouchBarItem instance. This is because it's similar to popovers in that it offers its NSTouchBar property. An example of this is the formatting controls above me. These have actually been grouped into a single NSTouchBarItem.

There are several reasons you might want to do this, and we'll talk about each of these. When centering multiple items, there's some tricks you can play with customization as well as localization purposes. If you remember a few minutes ago, when Chris was talking about the principalItemIdentifier, you'll recall that a single item identifier is actually provided as principal. But what happens if you want to center multiple items together like FaceTime is doing here. Well, you can group these items to a single group Touch Bar item and then provide that item's identifier as the principal item identifier.

You can also play some cool tricks with the customization. If you have a non-customizable group like we do here, you'll notice that these items are actually grouped together. That means when the user drags these things into, these buttons into the Touch Bar, all three of these will come together. There's also a single customization label describing these controls as the playback controls.

If you do choose to enable customization on your groups, you get some cool behavior there as well. In this example, we have two group Touch Bar items. Both of them have customization enabled. One contains a group of animals that you might find in the ocean, and another on a farm.

If I start customizing this, you'll notice that I'm free to re-order these items however I choose within their groups. If I try, however, to grab one of the ocean animals and put it into the farm animals group, it snaps back to where it was. Because that would be removing the item from its group and that's not supported.

GroupTouchBarItem also has really cool purposes for localization. Now, I'm sure your applications reach lots of users. Some of those users might be native right to left speakers of languages like Hebrew or Arabic. And I'm sure your applications are already flipping were appropriate for those users. And we want Touch Bar to reflect that as well.

A good example of this is FaceTime's UI. FaceTime chooses to show a full screen and a mute button both on the screen as well as within Touch Bar. And you'll notice that the order of these buttons match. If I go ahead and change the language to Arabic, you'll notice that the on-screen buttons will actually reverse their order. And we do the same in Touch Bar to maintain that matching order.

But it's important to note that not everything actually flips. The escape key and the control strip stay where they're at whether it's left to right or right to left. And only specific groups of items should possibly flip. Such as the center controls here, which we're flipping to match on-screen UI.

As well as the image and label about the incoming call are flipped. But the position of that item did not move to the opposite side of the Touch Bar. This is easy to achieve using GroupTouchBarItem's new group user interface layout direction property in 10.13. You can simply set this to reflect NSAppuserInterface LayoutDirection.

Now, I'm sure you're aware languages aren't just left to right or right to left, they also have variable length strings. And it's important to remember that when you're designing your UI. In this example, I have a list of some of my favorite ocean animals. And I ran this exact same app in both English and in German. In English I was able to fit 6 items here. But in German I only have 5. That's because the shark item actually didn't have enough room to fit in Touch Bar and so it was hidden from the user. Which is really unfortunate for our German friends.

Now, you might be tempted to fix this using constraints, tying each button to be a specific width. But that's actually not a great solution because as we change localizations, we're almost certainly going to cause clipping in one of them. Now, GroupTouchBarItem actually has a great way of handling this for you automatically starting in 10.13. And I encourage you to check out the "Advanced Touch Bar Talk" later today which will do a dive into exactly what happens.

Now, we have a few bonus topics. These are all covered great in documentation, but we'll mention them briefly now. First is the ColorPickerTouchBarItem. This allows users to interact with the color picker right through Touch Bar. They can choose the exact color that they want. They can even change color models and your document can restrict which color models are supported. Users also have access to their favorite color swatches. So, it's a really great experience. We also have a SharingServicePicker. This lets you easily share a document through mail, messages, air drop, or even third-party insurance services. And these are all the same services available through the share sheet.

And finally, we have an NSScrubber, which is actually a view, not an item. This could be the view of a Touch Bar item. And you can see in an application such as calendar's timeline, Safari's tabs or even the color swatches of the color picker that we just talked about. It's a very versatile, very fluid control. And it was designed specifically for Touch Bar. You can find out more about this at the advanced talk, which will do a deep dive on exactly how to use this control.

Now, we've covered a ton of material today. We talked about the NSTouchBar API, how it's tied to the responder chain, how you can use it to provide context-sensitive controls for your users. We've talked about the NSTouchBarItem and all of its subclasses that AppKit provides and their unique functionality.

So, you now know enough to go adopt Touch Bar in your applications today. While you're there, you should definitely enable user customization so that users can get the exact experience that they're looking for. And definitely remember to design you UI with localization in mind so that all users have a great experience.

For more information, you can check out our developer website. We have some related sessions you might be interested in. "Choosing the Right Cocoa Container View" will look at when you might want to choose a grid view over a stack view. And this could be important because you could use one of these container views as the content view of a TouchBarItem. We also have the "Advanced Touch Bar Talk" which we mentioned several times, which will do a dive into extra functionality of Touch Bar. Thank you all so much for joining us today. Enjoy the rest of your conference

.