Our first installment on WatchKit, How To Make Sense of the WatchKit for Apple Watch, focused on the design and UX elements of Apple's forthcoming wearable, Apple Watch. We will now transition to the architectural aspects of working with the WatchKit SDK, and provide some insight from a coding perspective into how everything fits together.
The Watch App Architecture
Apple Watch, expected to make its official debut in April, requires the active presence of an iPhone, paired, to run third-party apps that you develop. While the actual Watch App runs on the wearable, the WatchKit extension runs on the iPhone.
The Watch App is composed of the visual aspects of the app, the design-time storyboards and resourcef files (images, XML files, etc.) that are loaded onto the watch; the WatchKit extension hooks in via delegates to handle and respond to user interactions, such as selecting buttons, and is composed of the actual run-time code.
Glances are read-only and optional interfaces, and are made up of static images and assets. Notifications are more customized, allowing you to pass in contextually relevant and timely information, from the iPhone to the watch.
Watch apps are bundled and packaged together with the iOS app. The reason they are not separate is that the Watch App can be thought of as an extension of an existing iOS app, rather than an individual app. You design an Apple Watch app to complement an existing app, adding precise functionality that requires minimal interaction and information real estate for the best user experience. In this model, when users with a wearable install an iOS app, they will be presented with a prompt to install the wearable app, as well.
The Interaction Workflow
When a user interacts with the Watch App, the appropriate design-time storyboard is displayed, based on the state or mode the app is in (whether the app’s main interface is required, or a notification or glance is displayed). Depending on the scene selected, Apple Watch then notifies the paired iPhone to launch the WatchKit extension, along with the appropriate run-time objects from the code base, on the iPhone.
During the launch sequence, WatchKit automatically creates the appropriate interface controller for the current interaction. If the user is displaying your app’s glance, it creates the interface controller associated with the glance. If the user launched your app directly, it loads the initial interface controller from your app’s main storyboard file. In each case, your WatchKit extension provides a WKInterfaceController subclass for managing the corresponding interface. (Source: Apple)
The following illustration further explains the interaction, from app to extension via the wearable to the iPhone:
There’s a lot more to the lifecycle of WatchKit--more than we can cover in this article. If you are interested in learning more, please refer to the programming guide, available at the WatchKit Programming Guide.
Setting up your Xcode Project
Let’s set up our Xcode project and environment. First, make sure you have the latest Xcode beta, which supports Apple Watch. For this tutorial, we are going to assume that you already have an iOS project. If not, download a simple iOS project that can be extended to support Apple Watch.
This tutorial is making use of the sample code provided by Apple, which can be downloaded at developer.apple.com
In your opened project, create a new target by going to File -> New -> Target, and select Apple Watch. The Apple Watch extension, as we mentioned earlier, is bundled with your existing iOS app.
When you select the Apple Watch target, you will be prompted for various options, such as whether to include glance or custom notifications. For this tutorial, select both. After you are done, Xcode will conveniently generate the required target, files and derived bundle IDs (such as com.yourcompany.yourapp.watchapp and com.yourcompany.yourapp.watchextension, respectively).