For years, many have predicted the announcement of an Apple TV SDK. We all know it’s coming. It has to. And it will be amazing when it happens… whenever that is.
Everything is in place for Apple to kick-start the next generation of television, completely leap-frogging the current, pathetic crop of “smart TVs” like the iPhone did with its “smart phone” predecessors. All they need to do is open up the ecosystem.
But rather than simply wait for the future, we can take matters into our own hands, with class-dump and some reverse-engineering chutzpah.
Voila! A class dump of the Apple TV private framework headers
That’s right: this edition of NSHipster covers a topic so obscure, it doesn’t even officially exist.
Back Row is a private framework used in the Apple TV user experience. Its name is a reference to Front Row, an application included in OS X Tiger – 10.6 that paired with the Apple Remote to transform the Mac into a couch-friendly media center.
The original Apple TV could be described as a “short Mac Mini”, which ran a modified version of Front Row on a stripped-down build of OS X. It was little more than an iTunes remote, streaming content from a shared iTunes library on a separate computer.
The second generation of the device took a smaller form factor, shifting its focus from media storage and management to on-demand streaming. The second generation Apple TV user interface reflected this in both its design and implementation. BackRow was ported from OS X to iOS, as it transcended its original role coordinating iTunes libraries to become an extensible platform for streaming media appliances.
Back Row & UIKit
Back Row (name prefix:
BR) bears a striking resemblance to UIKit, with many of the familiar metaphors and conventions of iOS development.
Here’s a brief list of some Back Row classes & protocols and their UIKit equivalents:
Apple TV Appliance Structure
In the current Apple TV interface, the home screen contains a grid of rectangular icons, similar to the home screen on iOS. Each icon corresponds to an appliance.
Why an appliance and not an application? An appliance is more limited in what it can do as compared to an application. On iPhone or iPad, applications range from social media clients and photo tools to games and musical instruments. Whereas on Apple TV, an appliance consists of a series of remote-friendly menus, lists, and grids, which ultimately lead to media playback of some form. When it comes to appliances, (audio / video) content is king.
When an appliance launches, it displays a list of
BRAppliance items. Each category has its own name, identifier, and preferred ordering. When a category is selected, the appliance calls
- controller, which returns a
An appliance also has an optional
top, which is what displays at the top of the home screen when the app is highlighted.
Pushing and popping controllers is managed by a shared
BRController. When a controller is selected with in a list, it is pushed onto the stack. When the user presses the Menu button, the stack is popped.
A typical controller consists of a menu list on the right, with some kind of complimentary view on the left.
On top-level controllers, this sometimes takes the form of a
BRMarquee, which animates a Cover-Flow-style sequence of preview images for each of the controllers.
For controllers listing media that can be played, the complimentary view usually shows a preview image, along with meta data in a
BRMetadata, such as runtime, date created, and other relevant information.
iTunes store controllers also use a horizontally-stacked layout, with media information at the top, with related titles listed below.
Points of Interest
Diving into the class dump of the Apple TV frameworks reveals a treasure trove of interesting tidbits. With only undocumented header files to go by, there’s still a lot of mystery to what all’s in these private frameworks, or how they fit together. However a thoughtful analysis of class and method names offers some workable clues into their inter-workings.
Here are some of the more interesting parts of the Back Row framework headers (again, all of this is complete speculation):
BRURLImage: A protocol that encapsulates the process of loading and displaying images at various dimensions.
BRKeyboard: It’s always fascinating to see how Apple architects controls. Keyboards populate and manage interactions with the grid view of character and action keys, and are divided into classes for Roman and Japanese scripts.
BRState: No other Apple frameworks expose a class for state machines.
LATVLeaseis a subclass in the
Appleframework that appears to negotiate the terms of iTunes movie rentals.
BRMapping: A new and useful-looking collection class that functions as an
NSMutable, but also allows for an
NSValueto be set for each key (
-transformedin addition to
Value For Key:for Object:
BRMerchant: What you might expect in terms of a class representing a store client, with some interesting class methods.
itmsis in reference to the iTunes Music Store, but what’s
flagstaff? They’re probably codewords for streaming services that fall under the umbrella of the iTunes store.
BRControl: Factories, Populators, and Mediators are not commonly seen design patterns in Apple frameworks, although they are described in the Cocoa Fundamentals Guide.
Building Your Own Apple TV App
In the immortal words of Jeff Goldblum: “Life finds a way”.
Undeterred by the litigious shadow of Apple Inc., nor the undocumented wilds of a private API, a cadre of jail-breaking homesteaders have cracked the nut on Apple TV development with promising results.
One of the most polished among them is UitzendingGemist led by none other than Eloy Durán of CocoaPods fame, along with Kevin Bradley and Michael Gile.
As you can see from this video of an early version, you can run your very own applications on a jail-broken Apple TV (OS 5.0.1 or compatible). The code is relatively straightforward, fetching a catalog of media files from the Dutch public broadcasting site UitzendingGemist.nl, and playing them on demand.
It’s hard to say what it will take for Apple to open up the Apple TV ecosystem. Is it a matter of getting the APIs documented and ready for public use? Is there a process underway to refactor Back Row into UIKit? Or is everything pretty much ready, and it’s just a matter of other business pieces falling into place?
Only time will tell.
In the meantime, you can get a head-start on what will almost certainly be a gold-rush on the scale of the first generation of iPhone apps.