Apple’s UI API Trend
Since iOS and UIKit, Apple has produced three products with three new UI toolkits: Â Apple TV, CarPlay, and WatchKit.
In all three instances, the architecture they’ve chosen is one where the UI is essentially a runtime.
There’s a reason that all Apple TV apps look the same, and that’s because the “app†just provides data for the UI to present. NSHipster’s class dump of the BackRow classes doesn’t indicate that this is the framework that Apple intended to expose to applications; rather I think those are the classes that the runtime uses, and that the various applications would essentially talk to the UI server through a pipe.
That’s sort of how the CarPlay SDK works.  You provide the information to present (via MPPlayableContentDataSource), but CarPlay chooses how to present it.
WatchKit is a bit more flexible, in that the data you’re delivering to the watch over the pipe also includes a storyboard that the runtime uses to “play†your app, but there’s still a pretty solid separation between the application and the view.Â
On iOS, the system tells you when it’s time to draw and provides a surface to draw on and a rich set of drawing APIs. This makes literally anything possible. And neither the Apple TV, CarPlay, nor WatchKit provide this.
I’m curious to see whether the native WatchKit uses same architecture but with letting the app run locally (with still no direct access to rendering), or if they’ll provide an actual drawing API.