On November 18th Apple released the much anticipated Apple Watch software development kit, called WatchKit. Few in the iOS development community knew what to expect or what capabilities would be available. With this information we now know what constraints are imposed by the SDK which leads to a better understanding of some of the problems that need to be solved before enterprises can build and deploy watch apps. These problems are present whether you're writing an app for internal use or an app for consumer use.
The WatchKit SDK places major limitations on what can be done on the watch. I believe the best way to think about a watch app is to consider it a smart display extension for your iPhone app. Watch apps do not have any access to the hardware sensors on the watch and cannot put any non-display logic on the watch to be executed. Apple is taking a prudently conservative approach to the first version of the SDK for their watches. If they follow past patterns, they will gradually allow deeper access to the device with future versions of iOS.
A watch app is comprised of a set of views, view data, and view assets that are displayed by the watch and send user interaction messages back to the app extension on the phone. The app extension can then direct the watch to transition to other screens or take some action on the phone, like send a network request. The phone side of a watch app is an iOS 8 app extension. This means that the watch app must be developed alongside the corresponding iPhone app and that they can share code via Xcode frameworks.
Because of the technical constraints of a watch app there are several problems that need to be addressed when embarking on a watch project.
First, what are the appropriate tasks or data to expose on a watch? Given that the average interaction time with a watch app will be very short, probably in the single digit number of seconds, what valuable action can the user take or data can they receive in this time. These actions shouldn't require more than a tap or two to complete and should probably not flow into multiple screens. Keep in mind that they have already tapped once or twice on the watch just to get into your app. By the time they get there, half their patience is used up.
Second, given that a short time to completion is critical for a watch app, what are the highest priority tasks that the users may want to complete on a watch. Given the extremely limited UI and input methods, it would be imprudent to try to replicate all of your iPhone app features on a watch. The user interface would quickly become an endless set of screens that the user must navigate to get to the information they actually want. Identify the most important tasks for the user and limit the number of watch tasks to a very small handful.
Third, given that space within your app is limited, how can you leverage glances and notifications to deliver information to your users and to receive input from the user. These nano-apps can enhance your iPhone app while providing the user a greater connection to your company. Keep in mind, that you shouldn't abuse notifications by spamming the user. They'll just disable notifications from your app; defeating your goals.
Fourth, if you're dealing with sensitive data that normally requires a login on the phone, you'll need to develop a system in which the phone app remains authenticated to your backend systems for an extended period so that it can retrieve and deliver confidential information to the watch anytime the watch user requests it. The user may login to the iPhone app and then days later use the watch to retrieve information. They view the watch as a small portal into all that the iPhone knows. Many institutions are hesitant to provide a means by which a device can bypass human provided credentials, but if you require authentication from a watch app it will quickly be abandoned by your users.
Fifth, what's the best way to convey your brand on a very limited screen. Apple strongly recommends against showing your company's logo on the watch because the users already know what app they are using and are perturbed by constant ‘in-your-face' self-promotion. Users will see your logo when the launch the watch app and probably don't need to be reminded continually, especially since the session is so short. The colors, types, and verbiage of the app need to be enough to convey your brand.
Sixth, decide whether to deprecate iOS 7 support to support watch apps in early 2015. Many enterprises have a practice of supporting two versions of iOS, the current version and one older. To develop an Apple Watch app you'll need to adopt app extensions which preclude iOS 7 support. Is your organization ready to move ahead with only supporting iOS 8, or should it wait to deploy an Apple Watch app until iOS 9 is released and iOS 7 is deprecated?
Most of these questions will need to be answered for any enterprise wearable application. The expected market success and user adoption of the Apple Watch will probably force a decision on whether you should add wearables to your app ecosystem.