Back to top
A Timely Essay on Apple Watch App Development

Know What the Apple Watch Can — and Should Do Before You Even Think about Creating an App

by Jeff Kelley

When the iPhone SDK came out in 2008, many developers were struggling to find the right balance. They had Mac apps with tons of great features, but not all of those features made sense on the iPhones of the time. Apple gave some guidance here, suggesting to developers that they aggressively pare down their apps’ feature sets in the transition from desktop OS X to iOS. As time went on, iOS apps have become more full-featured than those initial apps, especially with the introduction of the iPad, but OS X apps are still by nature more complex.

The Apple Watch and its WatchKit SDK brings us to another of these points in time. Not every single feature makes sense to bring from your iPhone app to its WatchKit extension, and some just flat-out don’t belong.

If your app is an RSS reader, for instance, your users aren’t going to be reading long-form think pieces on their wrist during their morning commute; they’ll just pull out their iPhone for that. That doesn’t mean that an RSS reader shouldn’t have a WatchKit extension, though — users might want to skim headlines on their watch, marking uninteresting articles as read or saving interesting ones to their Reading List.

Other apps might actually want to bring every feature to the watch, if every feature makes sense. So the question to answer, then, is how do you take an existing iPhone app and pare down its features to those that make sense on the watch?

Finding the Right Features

The easiest way to cut a feature of your iPhone app is to say that Apple Watch can’t do it.

That rule applies to plenty of features you might consider. At least at first, WatchKit is incredibly limited. Without access to hardware sensors, real-time health data, the microphone and speakers, or an accelerometer, many potential watch features you may have been envisioning since the announcement are just not possible with WatchKit.

That makes it very easy to say “no” to a given feature, but it’s not quite the end of the road for all of these ideas. What some WatchKit apps are doing instead is rather clever: to get to the microphone, for instance, the watch app starts the microphone on the user’s iPhone in the background, then does what it needs to do with that audio.

Tricks like that aside, many potential features will wind up on the cutting room floor in this initial release.

For features that are possible on the watch, our next step is to determine if they belong on the watch at all.

Our previous example of reading long-form articles in an RSS reader is a great example of one that doesn’t. We’re looking for things our users can do quickly on their watches, where “quickly” means “no more than a few seconds.”

Say you have an iPhone app to control the temperature in your house through a connected thermostat. Increasing and decreasing the temperature are fantastic features to include: users can cool down their house without even glancing at their iPhone. Managing the schedule of temperature settings through the week, however, is probably not a great fit for the watch. Trying to fit a weekly view onto that small screen, as well as controls to modify it, is asking too much of WatchKit.

The ideal features take no more than a few button taps to accomplish what needs doing.

At this point, the only features we have left are those that don’t take a lot of time and don’t try to use advanced hardware features. This gives us a lot of room to add great features.

A messaging app can show the user their messages, allow them to dictate replies, and show notifications. In fact, a simple messaging app wouldn’t need to eliminate any features in their app to go to WatchKit.

It’s not enough, however, to just port your existing functionality to WatchKit and call it a day. Apple Watch has features you can take advantage of to make your apps an even better fit, and you should definitely take advantage of them in your app.

Integrating Important Watch Features

A simple messaging app could definitely be ported to WatchKit without losing features, but one feature in particular could make all the difference in the world: actionable notifications.

Instead of just showing the user that they have a new message, the developer of a messaging app could create an actionable notification with the option to reply. Now, the user doesn’t even have to be using that watch app to get value out of it. When the message comes in, they hit “Reply,” dictate a response, and send it.

This is one of the watch’s real strengths: it allows the user to spend the minimum amount of time doing something. Instead of digging their phone out of their pocket — a tougher task these days with our bigger phones — and opening the app to respond, they just need to move their wrist a little.

Sometimes, despite your watch app’s best efforts, the user is going to need to do something on their iPhone.

If you get a message in your messaging app and realize that your response really needs an animated gif to go with it, you shouldn’t have to re-type the message on your iPhone just to add the gif. Instead, support Handoff in your app. When you do, you’re able to describe to the system what the user is currently doing.

Our messaging app example, supporting Handoff, would display an icon on the user’s iPhone lock screen. Swiping up launches the messaging app right to the reply in question, and if you include the message content in your Handoff information, it’ll be pre-filled into the text box. Now, all the user needs to do is add the gif and hit Send.

Even though the user isn’t able to do everything on the watch, it’s important to save their work so they don’t feel like it’s a waste. In that same scenario without Handoff, where the user needs to start over on their iPhone, you run the risk of alienating them from using the watch app in the first place — after all, if they might have to re-do it, why not just start on the iPhone?

Providing Information in a Glance

Glances are a very interesting feature of WatchKit in that they have a unique restriction: you can only have one.

For all of the things your app can do, all of the information it contains, you can only display one screen as a Glance. Think carefully about what information you display. It should be timely information that the user will want to know about, but not necessarily get notified about. The current temperature in your house, information about your next to-do item that’s due, or the date and time of your next dinner reservation are all great Glance examples.

As if that wasn’t restrictive enough, the user can’t even interact with the Glance, so buttons are right out. If you’re having trouble determining which information to put in a Glance, try to figure out what information is most commonly accessed in your app. That’s what you should be putting in it.

It may seem counterintuitive, but the goal for your Glance should be to get users to open your watch app less.

Making It Beautiful

Once you know what features you’re going to implement in your WatchKit Extension and its Glance, put on your designer hat (or hire a designer) and think about your app’s user interface.

Having a black background is strongly recommended, but color is one of the best ways to make your branding consistent from iPhone to Apple Watch. Try to avoid a black screen full of plain, white labels and stock buttons. Be bold with your color choices and try to make your app stand out from the crowd.

One of the coolest things you can do on the watch is animations. Unlike iOS, though, you can’t just create a view that animates itself. Animations on the watch are simply image sequences, animating like a flipbook.

Given this constraint, animations take a different turn on WatchKit: instead of animating UI elements into place or animating a transition from one screen to another, use animations to indicate to the user that things are happening. If you can’t display a screen immediately — if you need to go out to the network, for instance — use an animation to indicate that. If a button begins a long-running task like charging a battery, you can add an animation to indicate that’s happening. In a small way, it can make an otherwise-boring app lively and fresh.

Identify truly useful features that are appropriate to implement on the Watch, integrate Watch functionality that enhances your features, provide exactly the right information in a Glance, and deliver a beautiful and functional design. That’s all it takes to create a great Watch app.

Hopefully the tips in this article help you on your way to making an amazing watch app. Despite its constraints — or perhaps because of them — the watch apps we’ve seen even before launch display a wide range of creative solutions to providing an app for a tiny screen. When the native app SDK is officially announced later in 2015, it’s almost certain that some of these constraints will be lifted. Until then, the best apps for Apple Watch will help their users by offering quick, convenient, and timely information on their wrists.

I can’t wait to see what you make.

About the Author

Jeff Kelley is an iOS developer at Detroit Labs and author of Developing Apps for Apple Watch [U1] and Learn Cocoa Touch for iOS [U2]. He got his start with programming at the age of five, modifying programs his mom dutifully typed from a magazine into Qbasic (thanks, Mom!). He’s been working with iOS since its infancy in 2008, and before that managed the OS X environment at the University of Michigan, where he obtained a very-related degree in Philosophy. Apps he’s worked on that you’ve likely seen are the Domino’s Pizza iOS ordering app and 3D Pizza Builder, the award-winning Chevy Game Time second-screen Super Bowl experience, and the DTE Energy outage center app. When not working on iOS apps, Jeff listens to an inordinate amount of podcasts and organizes the Motor City CocoaHeads group in Detroit.

External resources referenced in this article:

[U1] http://shop.oreilly.com/product/9781680500684.do

[U2] http://www.amazon.com/Learn-Cocoa-Touch-Jeff-Kelley/dp/1430242698