I spent my first day reading the programming guide, watching the “getting started” video and playing with Xcode 6.2 Beta. This post is a summary of what I learned. Have in mind that I focused most of my attention on WatchKit Apps and that this is a first Beta. Apple will make changes before the final release.

I must say that Xcode’s Beta surprised me in a good way. It crashed only once for the entire day, and I spent half an hour looking for a way to enable multiple lines in WKInterfaceLabel, only to find out, after restarting Xcode, that the option was right there in Interface Builder.

WatchKit is very limited. What they call an App is just an interface living on the watch that sends user input to the phone, and the phone can send commands to change the interface on the watch. Put simply, no third party code running on Watch. I don’t expect this to change for the first release.

During the day I encountered many limitations. Most of them are understandable if you consider what’s happening behind the scenes. You see, practically any operation you perform on WKInterfaceObject will be sent over-the-air to Watch. I don’t have specifics yet, maybe the phone is caching the messages and sending only a setNeedsDisplay: in the end. Maybe.

My main concern is: Will simple actions be slow? How many of us will build WatchKit Apps for the first day, only to find out the app is terrible slow in the actual device. Notice the following code:

The method toggles the selected state for that specific row, which changes a group background color. This requires another message to be sent to the device.

At least two messages are sent over-the-air to build this simple interaction. Now imagine if you send images.

Speaking about images, WatchKit provides a 20MB cache, per app, on the device. This is more than I expected and makes me consider if Apple is hinting us to use images for our custom UI needs.

Unfortunately, the cache seems to be missing a key feature (yes, I’ll open a feature request). There’s no way to check if a given image is on the cache. You can set an image for a given name, you can provide WKInterfaceImage with a name instead of an image, but you can’t know if it was present or not.

The last thing I discovered was that you have to specify all the cells of a WKInterfaceTable before those are presented. There is no cellForRowAtIndexPath:.