How To Make Sense of the WatchKit for Apple Watch

Apple has finally released the much-anticipated WatchKit SDK, giving developers time to start experimenting and prototyping in anticipation of the early-2015 debut of the Apple Watch itself. Apple has also released the Apple Watch Human Interface Guidelines to provide recommendations for adhering to its UX standards. ProgrammableWeb has spent some time (pun intended) with the WatchKit SDK, and in this post we offer our thoughts on the SDK and some advice on getting started with it.

image one

You've got your iPhone and your iPad and your iPod, but the Apple Watch (note, not "iWatch, as many had anticipated) is a completely new product line for Apple. This certainly presents a unique opportunity for third-party developers as the form factor evolves.

But the first step is getting started, and here we run through the basics of the WatchKit, starting with a wearable UX primer that explains the various components available for prototyping your app. (Our next article will provide a tutorial on how to develop your prototype, with some coding examples, using Apple’s new Watch simulator, available on XCode 8.2 beta.)

Apple has provided a collection of Photoshop PSD files, containing design resources for the Apple Watch, to help you on your way to prototyping your controls and elements.

Time Is of the Essence

When it comes to mobile apps, the general consensus is that you should aim to captivate users within 30 seconds of them picking up their smartphone. You've got even less time with smart watches or other wearables, which require more context and persionalization, and also have minimal screen real estate. Developers can take advantage of Apple Watch's tapctic engine to gently notify users with vibration, but you need to be very thoughtful in your choice of what notifications appear on a watch and with what frequency.

Most importantly, you should think of the Apple Watch as just an extension of the iPhone, rather than as a replacement. When you require interaction beyond a mere press of a button, you can get contextual information, with minimal interaction, by handing off to the iPhone using iOS 8’s continuity capabilities. In fact, the Apple Watch has to be paired with an iPhone to work.

Navigation Methods and Views

With its limited interaction points and screen real estate, the first iteration of Apple’s wearable device supports only three types of navigational modes: hierarchical, page-based and modal-based views.

navigation types


Hierarchical Navigation

Adapted from iOS, Apple Watch’s hierarchical navigation follows a similar push-and-pop, or master/detail paradigm. This model is well-suited for apps designed to provide information that can be drilled down into. Most commonly, you would present a table with rows and have users select a particular row to present more contextual information based on the interaction.


Page-based Navigation

Page-based navigation is synonymous with the UIPageViewController element found in iOS. While hierarchical navigation emphasizes a master-detail relationship, page-based navigation is ideally suited to an app that has a few screens, where data between each screen is not related.


You must decide at design time whether to go with hierarchical navigation or page-based navigation; you cannot mix and match.

Modal-based Navigation

When you want to present a view that would normally interrupt a previous interaction, with a similar purpose as action sheets in iOS, you would opt to use a modal sheet. Modal sheets can be called from either navigational or hierarchical paradigms.

modal view

Modal sheets can be a bit disruptive because, in use, they prevent users from interacting with the rest of the app. It’s therefore appropriate to use modal views only when, for example, you need an app to gain a user’s attention, or when a task needs to be responded to or dismissed. Modal screens are page-based and can contain one ore more horizontally scrollable screens.


You can think of glances as a user-initiated glance (for a lack of a better word) of specific contextual information from an app. Initiated from the watch, as opposed to being pushed from the phone, this Function allows users to quickly glance at essential information, such as weather and flight boarding status. Glance screens are read-only. There is only one screen, and it cannot be scrolled.


Within XCode (which we will discuss in detail in our next article), you select a specific template, then design your content around that. When the user single-taps on the glance screen, the relevant Apple Watch app comes up with the ability to deep-link within a specific part of the app and make use of the handoff/continuity functionality to notify the app that the glance view was tapped.

Interacting with the Interface

Apple makes available three forms of interaction on the Apple Watch, with one differing from what you might normally be accustomed to on iOS. The interactions available are Action-based, Gestures and Force Touch (the latter being brand new).

Action-based Interaction

On the Apple Watch's miniature retina screen, users will mostly interact with your app via a one-tap gesture. Later on, we will introduce the various UI control elements that you will interact with using one-tap gesturing, but you have already seen one--the tableview with rows, generally found in hierarchical navigation.

Gesture Interation

Gestures are handled on a system level, and are consistent across all apps--native and third party. The types of swipes available are vertical, which is common when scrolling the screen (such as in hierarchical navigation); horizontal, which is often used for page-by-page swiping (page-based navigation); and left-edge, for navigating backward.

Force Touch Interaction

Apple has also introduced a new form of interaction, exclusively on the Apple Watch, to compensate for users' inability to use multiple-finger gestures on the relatively small device. Force Touch allows your watch to sense the level of force, so in addition to detecting touches, the wearable will also detect press and hold. The typical expectation for this action is that it will bring up a contextual menu.


Digital Crown

The digital crown serves to assist users in scrolling vertically through pages (and provides an alternative to obstructing the screen).



Apple provides two types of notifications: Short Looks and Long Looks.

Short Look

A Short Look notification is discreet and minimal--ideally, it is used to get a user’s attention. This notification appears only briefly and is automatically dismissed. (The user does not need to take action.) 

Long Look

When the user keeps his or her arm raised, or interacts with the screen upon receiving a Short Look, the notification then becomes more detailed and less discreet, therefore considered a Long Look.

long look

Long Looks require active dismissal from the user. They can therefore be obtrusive if used too frequently. Think of Long Looks as synonymous with the interactive notifications of iOS 8, with the ability to reply or dismiss.

UIView Elements

WatchKit offers developers several interface elements--some familiar, some less so.  


Groups is the quintessential tool for laying out elements in your interface, acting as containers that can be positioned vertically or horizontally, similar to having a subview within a view in iOS. Groups can contain background colors (or background images), as well as set size, width, margins and other layouts. You would normally nest groups within other groups to create intricate visual representations.

Labels and Images

The most prevalent UI control element is Labels, which consist of static text. Labels are non-interactable.


Images are also static and non-interactable, and they can be used to programmatically start and stop a collection, to form a pre-built animation sequence. 


As with iOS, tables in WatchKit represent a set of one or more rows. They are also scrollable and interactive. However, rows are specified at design time, not run time, as you would normally do on an iOS project.


Switches and Sliders

Another common UI element found in WatchKit is Switches and Sliders. Switches always contains a label and, as with iOS, are switched either on or off.


Sliders provide multiple value states; they can have a limited number of discrete steps or be continuous, showing a label with the current value, as well as a toggle for incrementing or decrementing.



Buttons are a prominent feature on most UIs, and things are no different on the Apple Watch UI. The Buttons are interactive, and their appearance can be customized in terms of opacity, color, size, position, and whether they have rounded or square corners. (Apple prefers rounded corners to distinguish the Buttons from other elements that have more Angular corners.)


While Maps are interactive in iOS, they are static in WatchKit, showing a geographic representation of a particular point of interest. Since users cannot pan, zoom or otherwise interact, developers will need to remember to keep the maps small and contextually focused on the pin, along with appropriate annotations.


Dates & Timers

You won’t see specific elements like these in iOS, but Dates & Timers are types of labels that illustrate chrono-information, or time-related values, configurable to show dates and times in various regional or preferential formats. Timers count down (or up) from a specific value, visually.


Menus are typically shown as a grid of one to four icons, modally displayed and usually triggered by a Force Touch. This allows users to perform actions elegantly from the current screen. You will need to fit all the icons of the menu on the one screen, without scrolling. This can be done at design time or programmatically.


Each item in a menu consists of an icon and label string, with the label fitting in one line or, at most, spanning two lines.

Fonts, Color & Typography

When designing for the Apple Watch, Apple recommends use of a black (or dark) background, and one key branding color in the foreground, to emphasize your brand. This creates a clear distinction between the background and foreground.

Developers will need to be sure that fonts used are legible and clear on the Apple Watch's small screen. Dynamic typing should always be given preference. This is suggested on iOS apps, but it’s even more critical on wearables, where the system adjusts for line spacing and height. Apple also prefers that you use a single font throughout the app, similar to the UX guidelines for iOS apps.

Choose the San Francisco Text font for text that is 19 points or smaller. Choose the San Francisco Display font for text that is 20 points or larger.


In line with minimalist and metaphoric principles now prevalent in most contemporary mobile designs, Apple Watch should also present animation that provides reactive feedback, without gratitutiy. Apple Watch animations consist of pre-rendered static images, which are stored in the app bundle, allowing for the animation to be presented without delay.

Most of the runtime logic is done on the iPhone side of WatchKit, with the UI elements constructed at design time (such as storyboards and nib files) and stored on the watch side. This allows for the right amount of processing power to be allocated to the watch, with the chunk of the complex procssing left to the more powerful iPhone processor.

Our next article will take off where we left off here, using XCode and WatchKit simulator to create a simple Apple watch prototype. What are your plans for (and questions about) WatchKit and the Apple Watch. Share your thoughts in the comments section.


Be sure to read the next Mobile article: Yahoo Mobile Schedules First Ever Developer Conference