[caption id="attachment_137982" align="aligncenter" width="1464"] MacBook Pro with Touch Bar[/caption] The most polarizing and alluring part of the new MacBook Pros is the Touch Bar, a small touch-capacitive screen running along the top of the keyboard where the function keys were (and still are for some MacBook Pro versions). Alongside the launch of the hardware, Apple released tools so third-party developers can take advantage of Touch Bar. As it turns out, there’s a lot you can do with it. Straight away, we’ll note some interesting considerations. While we haven’t confirmed the bar is OLED (the documentation doesn’t say, nor do Apple’s hardware specs for the MacBook Pro), it is Retina. Specifically, the bar is 2180x80 Retina pixels, 1370 pixels usable in the center (Apple reserves some space on the left and right for elements such as Touch ID and a “system button”). It’s also powered by a proprietary T1 chipset. Functionally, the bar is pretty dynamic, so long as the use-case suits the form factor. It can display static text, images or actionable menu options as you might find in the top bar on a MacBook screen. It’s just a touch larger, more colorful and interactive than the latter. In an app like Photos, the bar lets you select or scrub through your library, choose to add a filter, and edit the image by rotating or cropping. Photos is actually a good jumping-off point for what Touch Bar can do, allowing you to display buttons, thumbnail images and a tool for selecting or managing filters. Those features relate to two items that figure prominently in the NSTouchBar developer tools: NSTouchBarItem and NSScrubber. An NSTouchBar Catalog shows developers how to create new instances for the Touch Bar. Those instances are also called Bars, as they’re basically views for the entire Touch Bar. Each actionable item or snippet of text on a Bar is called an Item. In-app objects are easily available to the Touch Bar, too. So long as it’s a responder to the NSResponder subclass, conforms to the NSTouchBarProvider protocol and runs a makeTouchBar() method within a NSTouchBarProvider protocol, you’re in business (just keep in mind the object should make sense for the toolbar itself; Xcode 8.1 also has a TouchBar simulator so you can be sure). All you're really doing is telling macOS that the in-app features should be made available to the Touch Bar; there's nothing developers need to do on the code level to identify if a Mac has a Touch Bar or not. The operating system takes care of that. Touch Bar objects are also customizable by users, which Apple encourages “unless you have a specific UI need not to do so.” A good reference point would be the scrubber/picker inside the Photos app; there’s no need to allow users to remove that feature. But you can choose to nest Bars, and it’s often the best option for more robust apps, not least of which because it doesn’t ask a user to float between two environments: the screen and the bar. Imagine choosing to add a filter from the touch Bar, then having to apply the filter using the touchpad and on-screen icons. Because I’m hanging my hat on Photos for this article, we’ll visit how it nests Bars: you can choose your photo with the scrubber, which then surfaces an edit toolbar once the image is on-screen. If you choose filters, a scrubber of filters ends up on the Touch Bar. If you choose to edit the image otherwise, crop and rotate tools show up, with a scrubber for rotation. [caption id="attachment_137961" align="aligncenter" width="880"] MacBook Pro Touch Bar[/caption]

MacBook Pro Has a Deep Rabbit’s Hole

Setting up and nesting Bars is fairly simple, and makes full-screen apps much more enticing. After that, it’s easy to get lost in how much is really available for your app. Developers can create just about any environment for Touch Bar with the tools available to them. It could be something as simple as a level layout for a side-scrolling game, or as complex as a DJ app that requires users to save a series of macros to Touch Bar items to create music. Between nesting and Touch Bar being a bit larger and infinitely more dynamic than the menu bar, Apple has created a seemingly endless array of use-cases for both developers and users. It’s by design, too. Developer and hacker Steve Troughton-Smith thinks the Touch Bar is a bit like the Apple Watch, replete with its own processor. Speaking to The Verge, he suggests it may even be its own environment:

From everything I can piece together, the T1 chip in the new MacBook Pro is a variant of the system-on-a-chip used in the Apple Watch. Running watchOS on the T1 lets the Mac benefit from Apple's deep work on iOS embedded security, as the T1 gates access to the Touch ID sensor and, from the looks of it, the front-facing camera in the new MacBook Pro too.

He also points out that, as on Apple Watch, background apps can’t trigger Touch Bar actions. If you’re in Photoshop, a ping to answer an iMessage won’t activate the bar with new iMessage options until you actually open that app. Troughton-Smith also points out “the Touch Bar theoretically could run while the rest of the machine is turned off, so you get all the low-power and security benefits of an iOS device, without having to switch to ARM completely on the desktop.” Why re-write boilerplate stuff, right? That’s an interesting concept: the Apple Watch reborn for the desktop. It makes sense, too. If you consider a Touch Bar interface for your MacBook Pro app in the same way you consider Apple Watch apps to compliment your iOS apps, the semblance becomes a bit more clear. And maybe that’s what all the ARM-for-Mac chatter was really about. Who knows? I’ll also point out that some of Troughton-Smith’s generalizations for the T1 have been rebuffed by mysterious sources allegedly inside Apple, but the core of his argument stands. Either way, developers are left with a highly customizable Touch Bar interface that can be pretty deeply integrated into existing apps, which also follows current code architecture and requires fairly minimal tooling to start using. If there was an undercurrent of ‘I wish my app could do just a bit more with the menu bar,’ Touch Bar is Apple’s answer to that. I just hope it’s not like Force Touch, which Apple lauded as a new way to dig deeper into apps, but has gone relatively nowhere on the desktop. But by giving developers a fun new toy to play with an a low barrier of entry, Touch Bar should prove itself as the next iteration of just how we’ll interact with our desktop apps.