App Development

Developer Perspective on Apple's WatchKit

WillowTree default article featured image

A Note on NDAs - while an Apple developer account with NDA is required to download Xcode betas and actually use WatchKit, all of the reference documentation is publicly available at this link. The programming guide is similarly available publicly here. Since all of this information is public, we don’t have to worry about NDA trouble.

From a developer point of view, WatchKit provides a very bare-bones framework for building watch apps; the kit contains a grand total of 15 classes, including 11 subclasses of WKInterfaceObject which represent UI elements like buttons and labels. Each of these, in turn, presents an extraordinarily simple interface consisting of two to five “write-only” setFoo: methods with no way to obtain current state. By far the most complicated WatchKit object, WKinterfaceController (the rough equivalent of UIViewController) has 27 methods and properties; contrast this with UIViewController's 90! There are some properties that are accessible in Interface Builder that you cannot access programmatically at all; WKInterfaceSwitch, for example, has a “Title” property in IB but no setTitle: method.

Which leads us to the next interesting point: WatchKit depends very heavily on Interface Builder and Storyboards. It’s actually impossible to build an interface programmatically: WKInterfaceObject has no equivalent of addSubviews:, nor does it have any equivalent of setFrame: (or even autolayout) for positioning. WKInterfaceTable does provide some dynamic UI, in that you can add or remove rows at runtime, but these rows themselves must be created and assigned string-based identifiers and “row controllers” NSObject subclasses you create entirely yourself) in IB. It’s even impossible to assign targets/actions to buttons at runtime, IB is the only game in town!

Obviously, while WatchKit appears easy to learn, mastery will not come so easily. In WatchKit, Apple provides us with very simple building blocks, so it will be up to us as developers to build complicated and useful apps with less support than UIKit provides. We will also need to keep battery life in mind at all times; sending images to display on the watch will use the radio, and represent a large drain. Caching images and data on the device for re-use could become very important.

In many ways, this is a return to iPhone 1.0 days; while the WatchKit framework is clearly superior to the old HTML5 iPhone 1 apps, it is much rougher and simpler than modern UIKit. Apple has also explicitly stated that they will provide a fully-native watch SDK later next year, though I strongly suspect it will initially be an expanded version of what we have now, rather than straight UIKit or something completely different. Until that time, though, the new WatchKit certainly enables a wide variety of phone-powered applications, and I for one look forward to being on the ground floor with this new platform.