Looking over the project

We'll take a moment to have a look at the project, which will differ in some ways to projects you have created just for the iPhone.

Three apps?

The first thing to notice is that you have more source code files than you are accustomed to seeing when you first create a purely iOS app. These are rather conveniently organized into groups in the Navigator pane as follows:

iOS app

In the group named HelloWatch (assuming you used that name when creating the project) you will find the list of source code, xcasset, and info.plist files with which you are already familiar, and these files all make up the iOS app that will run on the iPhone. Remember, watchKit apps for watchOS need a companion iPhone app, however much the Watch app may be your focus, and possibly your user's.

There is little to add at this stage, and in this chapter we will not be changing any of the files in this group.

WatchKit app

The group named HelloWatch WatchKit App contains the Storyboard (and an empty xcassets file) that you will use on the Watch itself. Notice too, the info.plist file, which performs the same function as that of the iOS app, though we won't be editing it yet.

Strangely, perhaps, the WatchKit App group is entirely devoid of any source code. To see anything that looks like Swift, we need to look at the third group created by the template we chose when setting up the project.

WatchKit extension

In the WatchKit Extension group, we finally get to see some source code that will actually run on the watch, and it is in this group that you will want to save the custom classes that you will be creating throughout this book. Now that you have, in effect, three apps to maintain, keeping your code well organized in this fashion has become even more important than it was already. But then, you were totally organized anyway, right?

In addition to source code, this group contains further xcasset resources, and again, a separate info.plist file.

It is the WatchKit Extension that communicates with the iOS app. This is where you will soon be writing code for the Watch.

Note

Why the separation?

In the original incarnation of watchOS, the WatchKit Extension resided not on the watch itself but on the phone, and from there it communicated with the watch (in a sometimes infuriatingly limited and sluggish manner). With watchOS 2, the extension was moved onto the watch itself, where it could run WatchKit code natively, and communication between the phone and watch was completely overhauled, thus enabling a more responsive UI, faster app launches, and improved battery life by reducing the amount of data transfer between the two devices—just one of a multitude of improvements to the platform as a whole.

Keeping this three-way structure meant that it was easy to migrate watchOS 1 apps to the new version, so the trio of apps has, for the time being at least, been retained.

Three targets

Analogous to the three apps, we now have three Targets, each of which has its own build settings (if you have been looking through the source files you might need to select the top level project file in the navigator to see them). You might like to click through the various tabs of each target and compare them, but if any of it seems a little overwhelming, rest assured that we won't be doing much work here for a while yet. Do, however, bear in mind that these multiple targets mean that running and debugging the watchOS and iOS code necessitates the use of the separate schemes we have used already to run the app(s).

Two storyboards

Two gadgets, two Storyboards. The Watch app and Phone Storyboards are entirely separate.