Introducing WatchKit and watchOS 2

Watch development now has three new frameworks, WatchKit, ClockKit and Watch Connectivity.

WatchKit

As I mentioned before the WatchKit extension now runs on the watch but apart from the architectural changes the extension primarily stays the same. There’s a few implications on how you develop your WatchKit extension.

You must implement your extension using the watchOS SDK instead of the iOS SDK. If a API isn’t available in the watchOS then you’ll need to rely on your iPhone app to perform the task. It’s very surprising but the API available on the watch is very large, ClockKit, Contacts, CoreData, HomeKit, CoreGraphics, CoreLocation, CoreMotion, EventKit, HealthKit, Watch Connectivity.

Your extension now stores files and data on the Apple Watch, but any data that’s not a part of your Watch app or WatchKit extension bundle must be fetched from the network or companion iOS app running on the iPhone. You cannot rely on a shared group container to exchange files with your iOS app.

WatchKit now has support for Networking via the NSURLSession object, with full access to the NSURLSession capabilities include the ability to download files in the background. While I think this is very cool it also scares me how much this can be abused by app developers and dramatically reduce the battery life on the watch.

One more thing to note is that WatchKit extensions not longer have direct access to iCloud technologies.

ClockKit and Complications

A complication is a small UI element that displays custom information on the clock face of Apple Watch. Like your app’s glance, complications are a way to display your app’s most important information to the user quickly. Your complications can be displayed alongside system complications for displaying the current date, moon phases, sunrise times, user activity, and many other types of information.

There’s a few different methods to update complications in your apps, if you’re complication data is known from now and into the future then you can send all the data for the timelines up to the complication, this also allows your complication to support the Time Travel feature. Other options to update data include scheduled updates and certain types of push notifications.

All apps the support a complication must have a class that implements the CLKComplicationDataSource and all methods must be implemented, to register this in your app add the key CLKComplicationsPrincipalClass into your Info.plist.

ClockKit manages the life cycle of your complication, launching your extension at appropriate times, creating your data source object, and asking it for data. Complications run on an update cycle, which your able to configure via getNextRequestedUpdateDateWithHandler. You provide the ClockKit with data from the past, present and future data. It’s recommended to provide enough data for hours and not minutes, then if your data changes you can invalidate the data using CLKComplicationServer.

To display the UI for your complication you use a placeholder template, ClockKit only ask for your placeholder templates once after your app is installed on the device. It caches the data your provide and does not refresh unless your app is reinstalled or updated. Templates seem to support Images and Text must support the different shapes, ring, small and large.

Connectivity

The WatchConnectivity framework provide a two way communication between an iOS app and Watch app and basically we can use it to pass data back and forth between the phone and watch, live communication is possible when both apps are active otherwise data is sent in the background.

The new framework consists of just a few classes, WCSession, WCSessionFile, WCSessionFileTransfer, WCSessionUserInfoTransfer and finally the WCSessionDelegate.

The WCSession (and it’s delegate) is the primary facilitator of communication between the Watch and Phone. The WatchKit extension and the iOS app must configure their own session objects, activating the session opens a channel that allows each app to communicate with its counterpart.

When both apps are active you can send data directly using sendMessage otherwise you can send messages in the background using transferUserInfo or transferFile. All messages are delivered in the same order that they are sent.

The transferCurrentComplicationUserInfo on the WCSession allows iOS Apps to directly send data to the WatchApps and update the complication.

Custom Interfaces for Notifications

Yippee, Watch apps now have support for Actionable notifications introduced in iOS 8, which is a way to add buttons to your notification interface. This is something I’ve been waiting for as currently I find Notifications on the Watch aren’t amazingly useful. Apple Watch automatically adds the button to the notification, as developers we just need to handle the action the user selects.

Notifications have a short look that cannot be customised and the long look which can be customised. The long look also contains any action buttons that you support.

Summary

Apple has really thought about how developers can build awesome user experiences with the Apple Watch and they’ve opened up a lot more than I would have expected. Well it looks like us app developers have our work cut out, there’s a lot to learn about Watch development, and Apple is betting big on the Watch.

Current none of these APIs are supported by Xamarin and I’m sure it wouldn’t too far away, except they do have a bit of work cut out for them.