WatchKit: Initial Impressions

I was pretty excited when Apple announced its WatchKit SDK today.  There's a lot to learn, but even better than that, there's a lot of stuff that is easily translatable if you're an existing iOS developer.

Here are a few initial impressions:

Watch Logic & Communication

Because the logic for your app resides on the phone itself, latency really becomes an issue.  Pushing on controllers and associated data to the user requires Bluetooth communication that introduces a quite a bit of latency.  Instead of pushing just data to the watch and letting it decide how to store/cache/manipulate the data, the watch is continually pushing and pulling data to and from the phone just to put things on there that could otherwise instantly show.

This can be problematic from a user experience perspective, but if you have so many screens, maybe it isn't appropriate for your wrist.

The upshot to this model is that, from a development perspective, there really aren't any special skills needed to develop apps, outside of learning the specific frameworks for WatchKit.  There isn't a new language, there aren't any device-specific things that need to be done. Which leads me to the next curiosity:

Opaque APIs

There is no direct interaction with views or other UI objects with WatchKit.  Instead, there are opaque objects that represent these elements, but there's actually very little that can be done to manipulate them outside of changing the size, color, and opacity of them.  This really tells me that the internals of WatchKit are not just being closely held (in typical Apple fashion), but likely designed in a way to be dramatically changed under-the-hood as the platform matures.  I suspect that as the hardware improves and the underlying capabilities become more rich, so will the API support for more customizability.  At this point, Apple is setting itself up for change that minimizes impact to how we interact, software-wise, with the device.

Another way to look at it is that if Apple come up with other devices with limited interactivity, say, like a TV, a lot of the programming paradigms in WatchKit are transportable to other platforms.

WKInterfaceController

1WKInterfaceController is the UIViewController equivalent in WatchKit, except you're not directly manipulating its views.  One of the big problems I have with UIViewController is how poor separation of concerns has become over the years with that class really knowing too much and having too much control over the entire flow and state of the app.  I think that Apple is repeating this mistake in a much more serious way.  For example, there is a WKInterfaceTable class that operates similarly to UITableView, except that it does not have a delegate property for selection callbacks.  This callback is instead hard-bolted directly into WKInterfaceController.  If I wanted to create a more generic class for managing a table and all of its associated interactions, I'm kinda out of luck without some workarounds in the WKInterfaceController.

There are a couple of other examples where classes, IMO, need to be carved up a little bit.