WatchKit Day 1

So, WatchKit is here. It supports Glances, Actionable Notifications, and unexpectedly, something Apple calls WatchKit Apps.

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:

import WatchKit

class TableInterfaceController : WKInterfaceController {    

    override func table(table: WKInterfaceTable, didSelectRowAtIndex rowIndex: Int) {

        let rowController : RowController = table.rowControllerAtIndex(rowIndex) as RowController

        rowController.selected = !rowController.selected


  1. User taps a cell in the watch.
  2. The watch sends a message to the phone that calls the method.
  3. 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:.

Also, if you need to share code between your app and the WatchKit extension, you should have a look at WWDC’s Session 416 - Building Modern Frameworks.

In short, I’m very excited about WatchKit. The limitations are making me think of different ways to solve problems. It’s “first iPhone” fun. ?

Update: I just wanted to link to a couple of other posts on WatchKit and Watch that I find very well done.


Now read this

Server-side Swift notes

This is the result of a recent look into server-side Swift for my own personal use. This area is changing everyday, and with less than a month until WWDC, expect most of this to become incorrect in the future. It all started with me... Continue →