1 Week with  WATCH

Roy Marmelstein
Swift and iOS Writing
5 min readMay 1, 2015

--

A Developer’s Perspective

It’s a cool watch that does cool things. (John Gruber)

“The Watch is Coming” Apple promised — generating a concoction of thrill and intrigue mixed with a soupçon of suspicion. After all, it’s the first addition to the family of iOS devices in almost five years. What will this little brother to the iPhone and the iPad feel like? What will it mean for developers? Will users love it?

Hey WatchKit!

As soon as WatchKit was released, I began working on a Watch version of my current project — Spaces. Spaces is all about placing content in the real world and the idea of being able to access a layer of useful information wherever you go seemed like the sort of thing the Watch was made for.

As someone so used to the freedom of building iOS apps (at least when it comes to the interface) — what struck me immediately about WatchKit was the restrictiveness of what one is actually allowed to do with the UI. There’s really not that much room for creating something visually unique.

48 hours after beginning development, Spaces was watch-ready. In the simulator, everything was working beautifully but when Apple started accepting watch apps, I decided not to submit until I had the hardware to test on. In retrospect, that was a very wise decision.

At the time of writing this post, I just spent a week with The Watch on my wrist — tapping me when notifications arrive, measuring my vitals in colourful circles and telling me to stand up at strange intervals. It really feels like the “front seat to the future” many reviewers were mentioning and at the same time it’s also a complex and not-for-everyone v1.

As far as apps go, the sad truth is that the majority of the 3500 watch apps that are available today are not that great. It’s not a comment about the skills of the developers but about the difficulty of developing without a device to test on (my sympathies to most Android devs). The simulator was really poor at showing us the latency in real phone-to-watch communication and the real consequences of launching the iOS app in the background. It was also hard to gauge how small the screen actually is or how inconvenient a ‘force touch’ can sometimes be.

I thought it’ll be useful for other Watch app developers if I shared three quick lessons I learned following the Watch’s arrival.

Darwin notifications / MMWormhole

The first thing I wanted to do with the watch app was to get it to communicate with the app on the phone.

Apple has a nice way for the watch to ask the phone for data with openParentApplication: reply: . However, I really wanted to transfer data in the opposite direction — the ability to push information from the app to the Watch.

With ‘app groups’ enabled, the documentation says that the WatchKit extension and the iPhone app can communicate via CFNotificationCenter Darwin notifications. An even more elegant solution presented itself with https://github.com/mutualmobile/MMWormhole , a framework that wraps the old Darwin notification API in a more modern KVO-like observation pattern (with blocks!).

Given the success of this approach in the simulator, I was shocked to discover it didn’t work at all on the real device. It turned out that the Darwin notifications only worked when both watch and phone apps were in the foreground.

My imperfect solution for now is to go back to the old days of a UI that doesn’t automatically refresh — providing the user with a refresh button for updating things manually.

Foreground vs Background

When WatchKit came out I was excited to read that a watch app can silently launch the iPhone app in the background. Spending time with the real device I discovered there are some major caveats.

Firstly, it’s a slow process with a very user-noticeable lag.

Secondly, how certain APIs behave in this silently-launched state is very badly documented. Trying to use CoreBluetooth or websockets in this way is still proving a pain with pretty unpredictable behaviour.

Images

Loading images from the iPhone app is very slow and apps that feature big images are the worst-performing of this first batch of Watch apps. It’s best to avoid loading images if at all possible.

The NY Times doing it right
Flipboard being beautiful but slow

If you really need to show a photo - load it in the iOS app, resize it and only pass the resized image to the Watch.

If you only actually need a background photo (see Flipboard), my creative solution was to use ColorArt to find the dominant colour in the background photo and only pass that. The Watch screen is small enough that it actually looks nicer and the user experience is infinitely better.

What’s next?

I honestly believe the Apple Watch will usher in a new class of app that’s made for quick glance-able interactions. Despite WatchKit’s limitations, it’s already better than the infamous sweet solution and there’s a lot we developers can already do.

I’m also really looking forward to hearing more about the future of Watch app development at WWDC.

Spaces for Apple Watch will be out soon. If you would like to beta test the new version, please sign up on http://pitch.spacesapp.co

Spaces for Apple Watch — get the beta http://pitch.spacesapp.co

--

--