I've been working with NSTouchBar for the past couple of days, seeing what I can put together in Acorn in some sort of reasonable timeframe. I was initially worried that classes would be pretty sparse and I'd have to write a bunch of custom subviews to get anything reasonable to show up on Touch Bar, but to my surprise the API seems pretty well fleshed out. A quick look at the headers shows the number of new classes and APIs available to us with this .x update:

$ cd AppKit.framework/Headers/
$ grep 10_12_1 *.h | wc -l
176

Another worry I had was that the API would be hacked together by some intern or that it would have an iOS bent to it. But again I was happy to see NSTouchBar and friends use the responder chain in a very reasonable fashion, and it really embraces how Cocoa APIs work on MacOS. I get the feeling this was worked on for a number of years and heavily refined, and was used internally by a number of applications. Which of course makes sense, but not something I had expected.

What are the drawbacks though? There's a lot you can do with this API and based on the examples Apple shows on the MacBook Pro page, there are a lot of different ways to interact with Touch Bar. But this also means a lot of code, and quite a bit of duplicate code unless I want to do some heavy refactoring. And this is for a tiny subset of the market. Do I really want to invest heavily into something that'll only be on pro laptops for the foreseeable future?

I've already implemented a number of Touch Bar things in Acorn, so I'm obviously invested in some part. But time spent on this is time not spent on features that'll help every one of my customers, not just the ones with pro laptops. Maybe I'll think differently once I get my hands on actual hardware.

Still, the API is pretty sweet.