Our current Hackaball prototype app is written in Objective-C so this will mean that for the application delegate class we will add an Objective-C method rather that Swift whilst the WatchKit extension, glance and notification will be Swift.

To add WatchKit support add a new 'Apple Watch' target. At this point additional schemes to support WatchKit will be created.

You will then be prompted to activate the WatchKit app scheme for your current iOS app. You don't have to activate the specific scheme as you can select these from the toolbar or product menu.

Next, you will be offered options for the new target. In this case we chose 'Swift' as the language and included notification and glance scenes. You don't have to have glance or notification scenes in your Watch app.

Once created you will see the additional WatchKit files in your project.

After the initial setup there were a number of errors to deal with. Currently it would appear that the version for the iOS deployment target must be 8.2 rather than the latest 8.3. Also the version number for your WatchKit app must be the same as your iOS app.

In order to run on real Apple Watch hardware you will need to enable provisioning in exactly the same way as you do for your other iOS devices. That means you add the unique UDID of the Watch to the list of devices on the developer portal and add the Watch to the list of supported devices in the development provisioning file.

When attempting to run I encountered the following error:

The solution appears to be to change all occurrences in "Build settings" of "Embeded content contains Swift Code" to "YES".

You should add a number of app icons for your Watch app. These include icons for the Watch itself and the iPhone companion app.

The first piece of code added is the application delegate method to respond to the paired WatchKit app. This method receives a NSDictionary from the WatchKit app and returns a NSDictionary to the WatchKit app. Given that this method will most likely be called while the iPhone app is in the background the task to respond should be run in the background to ensure it completes. This is shown in the following code snippet.

For this example the ball connectivity state and the list of all the currently available games for the ball are returned to the WatchKit app.

It is worth noting that when the project scheme for any part of the WatchKit is run, the debugger appears not to be available for the application delegate method.

The UI components that make up all parts of the WatchKit app are defined in a Storyboard. These are much simpler versions of those available to an iPhone app. The flow of the UI can be either horizontal or vertical but won't be wider than the watch. Components can be grouped with flow horizontal or vertical within the overall flow for greater flexibility.

You can set the app’s key colour by setting the global tint property in the file inspector for the Storyboard. You can also apply a colour to the sash that appears on the notifications, in the case below, a green colour.

For details about user interface design on the Watch check out the Apple Watch Human Interface Guidelines.

Now we move on to the main WatchKit interface. This contains a method that is called to wake the Watch app. In this method we add the call to the iPhone app for a NSDictionary. The method called is "openParentApplication" and this uses a block that's executed when the iPhone parent app replies to process the NSDictionary. In this case the ball state and the list of games. An important point to note is that you can’t send custom classes to the Watch app as they can’t be serialised so keep the objects you send in the NSDictionary simple. In the example here we have a string and an array of dictionaries.

Although notifications were added to the app we currently do nothing more than layout the UI. In the code below the only change made was to give the correct bundle ID for the app (shown with "?'s" in the code snippet below).

The notifications can however be tested in the simulator by selecting the notification scheme from the toolbar and running the target. If you see the following error

check that the correct notification (static or dynamic) has been selected in notification scheme.

Glances are simple one watch size views containing the most significant information. In the case of the example below we again call "openParentApplication" but unlike the full app we are only interested in the ball state. For further refinement, the dictionary sent to the iPhone app could contain a request of what is required thus reducing the size of the reply.

For the list of the games we have a simple row view that consists of a label. This is shown below.

When running in the iOS Simulator you will need to show the Watch. In order to do this select the "Hardware" menu, then "External Displays" and then either "Apple Watch - 38mm" or "Apple Watch - 42mm".

And finally the last step is to run on real hardware. With either the glance or app scheme selected and the relevant iPhone hardware attached the app will install on the Watch and run.

This app is by no means complete but does at least show the basics of putting together an Apple Watch app. More work is required to get the notifications to work on the hardware and it would also be nice to be able to select a game to run on the Hackaball from the app table view.

In this example we have also added Swift to an Objective-C project which in more detail is a topic for another blog post.

Useful links