If you’re developing and testing mobile apps for the enterprise market, where will Apple Watch fit into your plans? We took a close look at Apple’s WatchKit and have written a small sample app – and we discovered a few things and can offer some “best practices” if you’re thinking of incorporating Apple Watch into your plans.
Tether, Tether, Tether
The first thing to know about writing apps for Apple Watch is that the user must have a paired iPhone 5 or later within Bluetooth range; non-Apple apps run on the mobile phone, not on the watch. A WatchKit app uses the iPhone’s CPU and is a sandboxed extension of an existing iOS app. On the watch, a WatchKit app contains only resources (storyboards, UI objects, images, text, etc.). To set text on the watch, for example, you call a method in your extension app on the phone.
Battery, Battery, Battery
A careful read of the WatchKit documentation shows a very definite emphasis on conserving power. For example, Apple emphasizes the importance of caching images to save power.
Interface Controller Types
Interface Controllers running on iPhone manage the watch screen’s interface objects; Glance Interface controllers manage a read-only, single-screen presentation of information; tapping on the “glance” opens the WatchKit app. A Notification Interface controller manages notifications that have UI actions. A plain Interface Controller is the workhorse for most watch interaction.
In addition to the glance interface, a storyboard can implement page-based or hierarchical navigation. The latter is more complex, requiring a root controller with controls that summon other pages. A page-based interface consists of two or more pages that can be changed with a swipe. Below is a screenshot of the storyboard we created for a simple two-page display:
The basic UI objects the watch can manage include tables, images, separators, buttons, switches, sliders, static text, date and time, count down/up timers, menus, and maps.
Updating the Display
We updated text labels on our main page in a couple of ways. When the extension is about to go active, iOS calls its awakeWithContext method. We set a global toggle and set the text of a label to mark the execution of the method.
iOS calls the willActivate method just before the interface becomes visible to the user. We set the text to “Demo Watch App.” We also established a two-second timer so that we could change the text of the bottom label every two seconds:
Finally, we completed our sample app with code invoked by the timer:
Setting up the extension to an existing iOS app was very straightforward, and we used the Assistant editor to drag from our UI elements in the storyboard to the controller interface include file to connect elements to our code.
Here is a brief video where we built the app and ran it on the simulator.
Where Does that Leave App Design and Testing?
There are relatively few interface actions available, and without the ability to run code on the device, the Watch may feel to the developer more like a connected terminal than a computer running a program. The challenge will be to keep the user from knowing or caring.
The above diagram is from the WatchKit documentation and shows how a WatchKit app is at arm’s length from the WatchKit extension that supports it. Note the lack of code on the watch side and the messaging interface between the two.
For development and testing purposes, app functions are likely to be the same whether the app is interacting with the iPhone user on its screen or sending results or subsets of results to the watch for presentation to the user. I think that’s what Apple means when it says apps should “always provide users with a full-app experience.”
Apple has clearly laid out a three-tier architecture described as follows:
“A WatchKit app acts as the public face of your app but it works in tandem with your WatchKit extension, which is the brains of the operation.”
But those brains are limited:
“The WatchKit extension contains the code for managing content, responding
to user interactions, and updating your user interface.”
“[The extension] can coordinate with your iOS app as needed to perform more sophisticated tasks.”
Developers and testers, when they automate testing, should focus on the business logic and data accuracy of the main app as always; the WatchKit extension and WatchKit app are likely to be simple and straightforward data displays and responses. So the development and testing emphasis on WatchKit apps will remain on the robustness of the architecture (performance, reliability) and the accuracy of the information presented.
- Activities requiring user permission (like location) may fail because the user has to answer a prompt on the iPhone, which may be buried in purse or pocket.
- Background execution modes are prohibited except in the main iOS app.
- Keep in mind the three-tier architecture; since Apple Watch is a limited display, think of it as a place to show already-validated results.
- The subset of functions or data updates should match functions the user can perform with the full iOS app.
- Consider focusing on the most-frequently-used functions. There may not really be more than a very small number of key interactions that make sense.
- User interaction with Watch is momentary and all heavy lifting must be done by the main iOS app, not the WatchKit extension.
- Plan on spending the majority of testing and development resources where you spend today, on what Apple calls “the full-app experience.” That means automating and testing the full UI that drives the long-running or background tasks of your main iOS app. As Apple advises, “the iPhone app should do most of the work.”
- Consider automating the testing of data to be sent to the watch by displaying it on screens or sections in your main iOS app; once you know the business logic is right and you have the right data, then sending that data to the (relatively) simple UI of watch is very straightforward.
- Be prepared for the WatchKit extension to be deactivated and suspended at any time. Apple provides the “didDeactivate” method where you can save app state data and the “willActivate” method where you can restore it.
- Note that animation, as you may be used to, is not available on watch. Apple suggests using a series of cached images.