WatchKit - first impressions

Yesterday, WatchKit became available for us developers, and as far I can tell, open for the entire world to see, which is a first for Apple at least since the iPhone introduction. I thought it’d be good to share my first impressions.

I remember the second day the first official iPhone SDK had entered beta. It was new. It was fresh. At the same time it seemed well thought out. It was opinionated. It laid a path of where we would go. And it was a very nice framework on top of BSD. I was thrilled!

WatchKit doesn’t quite feel this way. The first thing I noticed that “the way it’s done” in iOS is not the same on WatchKit. For instance, there is no autolayout. Autolayout is THE way to do dynamic layout, Apple has been pushing it hard. Yet it’s nowhere to be found on WatchKit. It’s older brother, springs and struts, is also missing in action. Instead we have a swing-like layout system of stacked elements, either stacked horizontally or vertically. Heights and widths are explicit, yet the watch comes right of the bat in two screen resolutions. So there’s the interface dynamicism out the window.

Despite Apple pushing Swift heavily, the first examples they choose to show, being the examples in the demo video at http://developer.apple.com/watchkit, are all Objective C. Sure, they provide demos in both Objective C and Swift, but I’m surprised they’re not keeping the message focussed.

Controls are not UIViews, and they don’t seem to be layer backed. This means no Core Animation, and the result is that all animations have to be a series of pre-rendered images, rather than smooth images set up to be run on the fly. And yes, that means pre-rendered animations in two sizes, for 38mm and 42mm.

Is it running BSD? No idea. This is probably only important to my nostalgia as I can’t remember having dived directly to the BSD layer the last year. So it’s probably just my security blanket, but I like it being there and being available to my native app. But the WatchKit apps are not native. They are resources pushed on the phone and managed by the phone. All the logic is on the phone, the watch will only show resources already there, plus a tiny little bit of content generated on the fly by the phone and pushed over via what I expect is Bluetooth. So it’s not native, it’s more like a puppet theatre. That’s why map components in our apps cannot be dynamic. I’m sure Apple’s apps are native, so we’re really back to the iPhoneOS 1.1 situation where we were only allowed to make webapps. I hope Apples apps have the BSD layer available. But I would very much like to have that too. Perhaps with version 2.0?

But yes, we got a lot more than we expected. What I and many with me expected was the ability to make “glances”, but we also got notifications and we got these puppet-theatre apps. That gives us an awful lot of tools to begin with. Truth be told I can probably implement all the ideas I had so far with this. It’s going to need more work than I expected with the resolution-dependent layout, but much can still be done and I expect we’ll see a bunch of awesome apps.

The limitations, though, make me even more curious as to what kind of computer the S1 chip really is.

One thing I found really interesting is the UITableView replacement. UITableView is an old beast that’s been our bread and butter for a very long time. I look forward to giving it a run and see what kind of abuse it can withstand. With no scroll views, this one looks to be a target for an awful lot of experimentation in the months to come.