Developing an Apple Watch App

At a recent Seattle Xcoders Meetup, Curt Clifton, software engineer at The Omni Group, described what developing for the Apple Watch is like. He discussed a watch app conceptual model, data communication between the phone and the watch, and a few challenges.

Conceptual Model

The first thing that should be considered, says Clifton, is that in WatchKit 1.0, your code runs in an extension bundled with an iPhone app.

The watch itself will not run any code, other than Apple’s, but it can host image assets and compiled storyboards. Images can also be generated dynamically and piped over to the watch, which has 20MB of cache available for them, but this is slow and unreliable, says Clifton.

The WatchKit framework is still pretty small, remarks Clifton and is mostly made of proxies classes for views on the watch. Furthermore, those class will mostly offer exclusively setter methods, no getters.

Sync Options

Since an iOS extension runs in a separate process from the app that hosts it, syncing data between the two is key. Clifton thus reviews the different sync mechanisms that are available:

• NSFileCoordinator: this has been unfortunately ruled out for app↔extension coordination by an Apple technical note
• Groups entitlement and user defaults: pretty easy to setup and use, but it will not notify about changes.
• Shared CoreData/SQLite database: a good enough mechanism, says Clifton.
• Seed file and callbacks: the solution that Clifton used in his sample app and that he describes in more detail.
  • The iPhone host app writes a seed file to the shared app container with, e.g., a JSON payload.
  • The watch extension reads the data seed file and then, when it is ready to send some user action back to the parent app, will call a openParentApplication:reply: method that is able to wake up the host app in the background. The parent app receives a reply block that it will call when it is ready.
  • The host app can update the data to the seed file and then run the reply block, which can be used to pass the new data to the extension.
  • The Watch extension does not need to read the seed file anymore, it just updates in memory the data it received through the reply block.

The next part of the presentation is dedicated to a walkthrough of Clifton’s sample app source code and a demo of how it can be debugged in Xcode, which is a process similar to that for debugging any iOS 8 app extension.

Challenges

The last part of the talk is dedicated to discussing challenges that developers will find.

• As we mentioned, WatchKit only offers setters, so a first challenge is sending commands to non-active controls. This could lead to data inconsistencies and is dealt with by having each class keep track of its control status, whether active or inactive. This approach is implemented in the sample app through the _updateDisplay* set of methods.
• Shared frameworks between the host app and the watch extension can be used, provided the framework is copied over in a Xcode copy phase.
• Auto-layout is not supported and is replaced by groups that you can fill from left to right and top to bottom; you can add groups inside of groups, and build pretty complex UIs, but it is a completely different model.
• Finally, it is not known yet what the watch interface for notification will look like, and it is not still clear how to deal with notifications coming from the watch.

Clifton’s sample app is available on GitHub.