First Look: Apple Watch Development

With the release of the Apple Watch on April 24th, customers are wondering how this new technology fits into their business goals, and mobile developers and designers are scrambling to learn yet another form factor. This blog series will address the overall feature set at a high level focusing on development to provide a brief introduction on application programming for the watch.

Apple Watch development is very similar to native iOS development for iPhone and iPad, but with much simpler paradigms along with the restrictions that go with the simple paradigms. After playing around with WatchKit in XCode for a week, I had several “Wow, that’s a nice improvement” moments. I’ll talk about a few of those in addition to giving an overview of the basics of Apple Watch development.

Some of the key concepts that every developer needs to know about prior to starting development for the Watch are covered in Part 1 of this blog series: WatchKit apps and extensions, Glances, Notifications, and hybrid development patterns. The second part of this series will delve into some of the more advanced topics and highlight some of the enhancements made to Apple’s SDK in the area of Auto Layout, tables, segues, and other advanced features of the WatchKit SDK.

The Basics

For the first release of Apple Watch, Apple—aside from the $17,000 Apple Watch Edition—did a great job of sticking to the basics and ensuring simplicity. Striking a balance between simplicity and feature set is always the biggest challenge when creating world-class mobile solutions, and I feel that Apple did a pretty good job keeping the first release of the watch simple in order to give itself room to maneuver and adapt to feedback of early adopters.

Apple kept things pretty consistent from a programming perspective and actually improved upon several of the patterns used for native development of the iPhone and iPad. As a result, the programming patterns used to develop Apple Watch apps will look very familiar to someone skilled in native iOS development in the Swift or Objective-C language. As a developer, you are still in an XCode IDE, you still design interfaces by dragging and dropping controls in Interface Builder, and you still switch scenes using segues. 

As always, with simplicity also come limitations. The most important limitation to consider for the first version of the watch is the fact that every Apple Watch app must be paired with an iPhone app. No exceptions. In order for the watch to be functional, it must be paired with an iPhone 5 or later running iOS 8.2 or later, and under the covers this means that your phone and watch will be communicating using Bluetooth Low Energy (BLE). Once this pairing is complete, apps for the watch can be downloaded using the iPhone to navigate the App Store and download apps in the same way. The phone will automatically detect that the iPhone has been paired with an Apple Watch and prompt the user to download the watch app. This limitation means that any standalone scenarios for the watch are off the table as of now.

WatchKit Apps and Extensions

Every Apple Watch app contains two main pieces: a WatchKit app, which contains the storyboards and interface elements necessary to render the scenes of the app, and a WatchKit extension, which runs on the user’s paired iPhone. These two pieces work in tandem to manage the state of the app, collect data from outside sources, and render the storyboard created with interface builder onto the watch.

When a new WatchKit app target is created in XCode, you may notice an important but often overlooked fact: The main controller lives within the WatchKit Extension rather than the WatchKit App, which is not the same pattern used for iPhone and iPad development. The reasons the controller lives in the extension rather than within the app itself are pretty straightforward:

• The iPhone hardware is much more powerful and much faster than the Apple Watch hardware and control code is typically CPU and network intensive. 

• The iPhone’s battery is enormous compared to the watch's, and aside from lighting the display, control and network logic are some of the most battery-intensive operations that can be performed. Apple chose to push these to the phone to make battery life better.

• The watch app typically needs to communicate with the iPhone app, and instead of having to use a Bluetooth connection for this communication, Apple chose to have the communication be local. Once the WatchKit extension knows what should be rendered, it then passes a minimal amount of data over BLE to the watch to render the display.

After reading this description, you may wonder how difficult all of the communication over BLE is to the developer. Fortunately for application developers, all of this communication between the Watch App and the WatchKit extension is handled behind the scenes; you simply interact with storyboard elements the same way you would for native iOS by using the Outlet pattern and the magic happens behind the scenes to render your view. Very simple. 

Glances

Think of glances in a similar fashion as you do Apple’s Notification Center; they exist only to provide the quickest look at the most relevant and recent data that your app wishes to provide for the user. They are a quick, lightweight view of your app as a whole and can be used to drive users into the full watch app, but they solely provide read-only data.

Glances are accessed when the user swipes down on the face of the watch. The user then gets a swipable view of all glances for each app; the usage pattern is similar to the way a user swipes through photos on Facebook. Each glance can then be tapped to launch the full watch app and take further user action on the data provided by the glance. 

In order to keep things simple, glances have a few restrictions imposed on designers and developers:

1. Glances are template-based, which restricts custom design a bit. XCode provides canned templates for the upper and lower portions of the screen for a glance, and customization beyond this point is not yet supported.

2. Glances are not scrollable; all content must fit on the watch face.

3. Glances can only support a single action. Tapping on your glance will launch your app to a specific screen, but multiple tap actions depending on which portion of the glance a user taps are not yet supported.

Another important point to keep in mind is that glances are optional. If the usability patterns of your app do not call for a glance, then I would not recommend implementing one. Simply having another way for a user to launch your app is not a good reason to implement a glance.

Notifications

To me, notifications are the key piece of the Apple Watch that makes it valuable to have on your wrist. Although it supports these features, I believe that users won’t often be seen texting, tweeting, or taking phone calls from the watch. It’s simply not very usable, and texting and emailing requires use of speech-to-text, which is not yet advanced enough to always get things right. 

Where the watch really shines is allowing a user to quickly view an incoming notification with the raise of a wrist. For this reason, I believe that harnessing the power of notifications and thinking of usage scenarios where watch notifications can enhance the usability of your existing iPhone app will be absolutely critical when developing Apple Watch apps.

Like other areas of Apple Watch development, incorporating simple notifications is very easy on the developer. A watch application developed to pair with an iPhone app that already supports notifications requires minimal effort to get them onto the watch as well; most of your effort should be geared towards designing the best user experience and taking advantage of the two types of interfaces provided by Apple Watch notifications:

1. The Short-Look Interface: This interface is displayed when the user first looks at the notification, and, like Glances, is template-based, read-only and non-scrollable. The system simply displays the title of the notification along with the app icon and name. As of the first version of WatchKit SDK, this interface cannot be customized.

2. The Long-Look Interface: This is where the magic happens and where you can really drive value into your watch app. This interface appears when the user continues viewing the Short-Look Interface and is scrollable, customizable, and actionable, meaning that there are a lot of possibilities for designing a very useful interactive notification that sits on the wrist of your user. 

Since the Short-Look Interface is not customizable at this point, let’s focus on how you can develop with the Long-Look Interface. It is divided into three areas:

1. The sash: This area contains your app icon and name with a banner that is of a customizable color.

2. The content: This area contains a scrollable view meant for detailed information about the notification; for example, an iMessage notification contains a scrollable view to see every message that a user has sent you since you’ve dismissed the notification.

3. The interaction area: This area contains your actionable buttons along with a dismiss button. In the previous iMessage example, it contains dismiss to get rid of the notification and a Reply button that allows a user to reply on the fly with several canned messages or use speech-to-text to reply with a customized message by authoring with speech. The action button types, titles, handlers, etc. can be configured within the iPhone app’s notification settings in the same manner as you’d do for a standalone iPhone app. Actions can be handled in the foreground of the watch or in the background using the iPhone app to process the action in the background and then interact with the watch app. See Apple’s Local and Remote Notification Programming Guide for more details.

Notifications could be a blog series of their own, so I’m hopeful that the information above provides enough of an overview to get you excited about how powerful these can be for the watch. Outside of fitness tracking scenarios, I believe that actions triggered by notifications will end up being the main use case of the watch moving forward. We’ve already thought of many applications for this functionality for some apps that we currently have in development and will share more details closer to the release dates of the apps. 

Some Thoughts on Hybrid Development

If you are familiar with PointSource, then you know that we are big believers in harnessing the power and efficiency of hybrid development. By utilizing HTML5 combined with cutting-edge JavaScript frameworks like AngularJS and Foundation for Apps, we are able to design and develop world-class mobile applications that work across all platforms by using a singular codebase. For more information on hybrid development, see Rapid Application Development with Hybrid. 

All current hybrid development centers around the concept of harnessing a web view within the app to perform HTML interactions and making it transparent to the app user that a web view is actually being used. As mentioned, the current WatchKit SDK is fairly limited in functionality in order to keep things simple, and, as you might have imagined, WatchKit does not contain a web view element. Since the watch does not support web views (yet) and web views are essential for building hybrid apps, where does this leave us? 

Fortunately for hybrid developers, the open source community reacts quickly and has created technologies that can assist in communications between your Cordova-based hybrid iPhone app and your new Apple Watch app. You’ll still need to create the native views that live on the watch in XCode, but all of the heavy-lifting that is done within the app that runs on the user’s iPhone can still be done using Cordova. Messages can be passed directly from the iPhone app to the WatchKit extension via Cordova extensions, and the WatchKit extension can contain a thin layer of code charged with rendering the app’s view appropriately.

Summary

We’ve covered some of the high-level topics for developing apps for the Apple Watch, but there is clearly much more content than can be covered within a single blog post, or even a series for that matter. In the second part of this series, I’ll talk more about how to lay out views and controls on the Apple Watch interface, improvements made to areas like tables and segues, and other advanced topics related to the API. If there’s anything you’d like to see addressed specifically, don’t hesitate to reach out via email or Twitter.