Developing For Apple Watch

9 October 2017

The Watch is cool, making apps for it not so much. WatchKit doesn’t give the developer much freedom when it comes to design. The interface is composed of pre-compiled layouts and generic UI elements, with limited customisation. It’s a rich templating engine.

Behaviours and interactions are only achievable for third-party developers on watchOS if someone at Apple has already invented them and exposed a checkbox in Interface Builder. Any dynamic transition or animation in a WatchKit app is basically impossible.

For example, you can transition a table row to a new appearance if that row changes height because WatchKit happens to support that. But if you want to cross-fade the contents of a row that has the same height before and after, you are out of luck.

Want to create a social feed with post summaries and photos that use a parallax effect to subtly shift perspective as you move through a story? No joy. WatchKit does not provide realtime scroll events to apps so there is no way to react to a change in view offset. Even if it did, the lack of freeform layout effectively makes it unfeasible.

Let’s pretend Flickr wants to make a watch app that showcases the best images of the week uploaded to the platform, with a wall of thumbnails that fills the watch display. Users could use the Digital Crown to zoom in and focus on a single photo in fullscreen. You could perhaps favourite it to find it again later on a Mac or iPad. Seems like an interesting app? Literally only in your dreams with WatchKit. (In my dreams, Flickr is also a thriving photo sharing site.)

You have to fight the system at every turn to do anything non-standard … and in most cases it still isn’t achievable. There are a few ‘advanced’ interactions that Apple has made special affordances for developers to take advantage of, but I can probably count the number of them on one hand. There’s a reason why all third-party watch apps look uninspiring and generic; there’s just not much you can do to make your own app stand out.

What really puts salt in the wound is that Apple has access to a completely different Apple Watch technology stack and doesn’t hesitate to take advantage of it in its own apps. In thinking what I wanted to say for this article, I started flicking through the honeycomb and trying to find a stock app that could be visually replicated by a third party. I really, really, struggled.

The examples I wrote up above were not invented arbitrarily. The parallax story feed is literally describing the Apple News app. The photo wall describes the interactions of the Photos app. The update-in-place custom transitions are used all over the system — I was specifically thinking of the Heart Rate app which dynamically updates the current heart rate readout using a rotary-dial text animation.

The kind of things Apple doesn’t let you do are critical things that makeup a rich and responsive application. These things should not be passed off as little niceties, they serve a significant role in making an app feel alive and more enjoyable to use. Let’s drive this home with more examples of stock apps doing things third-party developers can’t.

Messages uses a zooming effect for bubbles as you scroll through the transcript, and swipe actions for the summary cells on the main screen. Calendar pushes the title bar alongside the list of events. Music has a beautiful transition for scrolling between albums on the home screen, it feels like you are flicking between jewel case CDs on a shelf. Activity relies on a rich graphical representation of progress, the rings, with independent animations for each segment and several custom live-updating animated charts hosted inside table cells that scale up as the user scrolls.

Even something mundane like the contact list in the Phone app shows hundreds of rows with a large address book, far more cells than WatchKit can manage, and presents a custom letter-by-letter scrubbing interface when you scroll the Digital Crown quickly. Tap on a contact photo and it smoothly expands to fill the Watch display. These interactions are so basic I had to double-check I wasn’t crazy, but sadly it is true these things are all unavailable to external developers.

After looking at every app on my watch, I think three Apple apps could be implemented by an outsider: Alarms, Settings and Stocks. That’s it. (Alarms and Settings are very plain apps mostly consisting of standard table rows. Stocks has a dynamic behaviour where you can scroll/swipe through the detail views like vertical pages. This interaction is one of the few things Apple has packaged up for WatchKit developers to access.)

Apple engineers are using a completely different technology stack to create the system apps. They get to write real iOS apps with a watchOS appearance theme, essentially. Third-party developers have to use WatchKit — a completely separate abstracted framework that exposes only high-level interface objects (whilst creating UIKit components under the covers).

The current WatchKit API leaves no room for invention. iOS innovations like pull-to-refresh came about because the iPhone OS UI frameworks were flexible enough to let developers and designers run wild with their own ideas, if they wanted to. Some of these custom controls worked so well Apple later incorporated them as standard components in UIKit. That free reign creativity simply can’t happen on the watch at the moment. Apple defines what is possible.

I hope this adequately conveys the frustration I had developing Visual Codes for Apple Watch. There’s no freedom to make what you are imagining in your head which means, for me, there is almost no fun in making it either. I did it because I had to.

Unlike iOS, making a WatchKit app is like a chore where you have to do a set number of things in a set number of ways. And that’s just an exposition of the UI side. I haven’t even covered the restrictions on what features are actually implementable on current watchOS. Those functional limitations preclude many categories of Watch apps from being made at all.