Communication

Since each app’s WatchKit extension is now running natively on the Apple Watch, significant considerations need to be made in regard to how often the extensions refresh their content, how requests for those refreshes are handled, and how the content is delivered from somewhere out there on the Internet to the WatchKit extension to the WatchKit app, where the user can see it. Battery must be conserved at every level, because getting usable apps at the price of the hard-won all day battery life would be an unacceptable trade-off.

Apple’s answers to these questions are the WatchConnectivity framework and the NSURLSession foundation class. The latter has already existed in Apple’s Core Foundation framework, but now has been adapted to work on the Apple Watch in watchOS 2.

WatchConnectivity is a brand new framework with far-reaching and powerful capabilities. The main features of WatchConnectivity are that it allows for transfers of information to occur in the background, and it facilitates any real-time interactive messaging between the phone and the Watch.

NSURLSession, on the other hand, is used to link the Apple Watch app to sources of data that are in the cloud rather than on the iPhone. NSURLSession and WatchConnectivity can and should be used side by side to create foreground and background communications between the Watch, the phone, and the cloud. Together, these break the Watch out of its old “dumb display” role, and bring it to life as a true “smartwatch.”

WatchConnectivity

WatchConnectivity is now the main connective layer between the iOS app running on the iPhone, and the WatchKit extension running on the Apple Watch. This framework will be called upon when new content needs to be delivered to the the data store on either device, and is in charge of choosing the “opportune moment” to make these transfers. At its most idealistic, the goal of WatchConnectivity is to have all content delivered in the background and updated so that every time a user interacts with their Watch, the information is always up to date and they are never forced to wait as content reloads and refreshes. Obviously, such a goal is not currently possible, but WatchConnectivity does a good a job of working within its constraints to get close.

WatchConnectivity depends on a few core ideas that Apple has determined in order to conserve battery life as much as it possibly can. These are important to understand because they could lead to extended loading times at (hopefully) irregular intervals. This trade-off seems reasonable to me given the goal that they are in pursuit of. There’s no point worrying about load times on a dead Watch, so battery life should remain the number one concern even as Apple seeks to irradiate unreasonable latency.

First, the framework depends on the idea that when the user isn’t using a particular Watch app, the content for that app is not needed immediately. This sounds like (and is) a good assumption, but it also means that if you activate your Watch’s screen and try to go to an app right away, you might experience a slow loading time if it hadn’t gotten around to making its latest data transfer yet.

Next, as I mentioned earlier, the system will wait for the “opportune moment” to make transfers. This phrase is mostly a black box from research I’ve been able to dig up on it, but I did find mentioned that the system will base its estimation of opportune conditions at least partially on power, performance, and when the user is using the Apple Watch.

When the conditions are right, content will be transferred across the platforms. However, even though the data has now bridged the gap to its destination platform, it will still not yet be loaded by the app. Rather, it is queued up to be delivered to the app the next time it is launched.

This is the final piece of the puzzle. When the user launches the receiving app, then and only then will the content be delivered and the app be able to update its state. While this will definitely lead to slightly slower than real-time loading of apps, as they will frequently need to update their state on load, the data that they need to do so will now already be on the device (assuming everything has worked as designed). Loading data from onboard memory is way faster than having to load that same data from the iPhone over Bluetooth every time an app is launched.

To recap, WatchConnectivity deals with transfers of data between iOS and watchOS in the following series of steps: first, new data will come in on the iOS side, either from launching the iOS app or through a background refresh. WatchConnectivity will receive that data from iOS, and assuming the user is not already currently using the Watch app, will queue it up and then hold it while it waits for an “opportune moment” to make the transfer ⁸. Once the transfer is made, watchOS still holds the data at a system level, only delivering it to its final destination when the corresponding app is launched. This is a key battery life saver because it means that watchOS never needs to fire up any third-party apps in the background in order to push them their data ⁹. Third-party apps are only active when the user is actively using them, and this is the greatest battery life saver of all.

At some point in the future I’m sure technology will allow for strong enough Apple Watch battery life to finish off the transfer process without waiting for apps to be launched. In the meantime, I think this implementation creates a good enough balance between performance and battery life. It’s not nearly perfect, but it’s an order of magnitude better than the way things were in watchOS 1.

Another point to factor in is that this is only referring to load times with data waiting to be delivered. In my experience, once I’ve launched a watchOS 2 app for the first time in a while, subsequent launches are way faster, almost immediate, as the app doesn’t have anything to do except load up its interface.

Background Transfers

So now we’ve gone over how the background transfer process works, but what kinds of data can be transferred? WatchConnectivity supports three different types of data transfers back and forth between watchOS and iOS apps. All three types of data are transferred using the methods described above.

The first type of data transfer, and the one that Apple expects (and encourages) to be the most popular, is called “application context.” An application context transfer is a single set of the most interesting info that an app needs to display to its users. Each time an Apple Watch app is launched, it will accept a single application context update. As you might expect, this will be a refresh of the app’s content so that it can display the most up to date information right away.

Since only one application context update is stored at any given time, these updates have an overwriting behavior. As a tribute to the well thought out implementation of these background transfers, developers don’t need to do anything to handle the possibility of more than one application context being sent before an earlier one has been received. It is entirely handled by the system. Even if the iOS side gets another update before an earlier one has been delivered, it can send the next one right away without needing to perform any checks at all.

Once the WatchConnectivity framework has hold of the application context transfer, it will overwrite any other such transfers waiting to be delivered as soon as the two run into each other. If there is an application context transfer from a particular app waiting to make the jump to the Apple Watch when another is pushed, it will be overwritten and only the new one will go to the Watch. If the old one has already been pushed to the Watch and is waiting for the app to be launched, then the new one will overwrite it as soon as an opportune moment arrives for it to transfer Watchside.

Application context transfers are particularly fitting for glances, as they already maintain the property that the application context transfer type is based on: older information is now irrelevant, and only the newest, most current information matters. We can read into Apple pushing application context transfers as the main type of background transfer as a subtle reminder that this is a principle on which most Apple Watch apps should be based.

The Apple Watch is not about what’s old. It’s about what’s new, fresh, and most relevant right now. This is not an idea created by Apple, but one that’s been an implicit underlying principle of every watch ever made. Nobody wants to know what time it was five minutes ago. Developers of Apple Watch apps should not take this lightly.

Despite the above, some apps will need to store more than one batch of information at once. For these, WatchConnectivity supports “user info transfers”. This second type of data transfer allows apps to send dictionaries of information back and forth. If the iOS app sends over a user info transfer dictionary, and then later sends another one, both of them will be entered into a queue to be delivered to the Apple Watch app. When the Watch app is activated, it can choose to pull in and handle the entire queue, or it can query the items in the queue and decide which ones it needs to use more selectively.

The final type of data transfer is the file transfer. This is as self explanatory as you would expect. Everything works in exactly the same way as user info transfers do, the content in question is just made up of files rather than dictionaries. Each file can also include an optional dictionary of metadata so that the receiving side can get some more context and information to display. The biggest issue to consider with file transfers is of course that they will take significantly longer to complete than the other transfer types. This in turn could lead to greater load times and worse performance by the Apple Watch app if you try to use it while files are still being transferred.

Interactive Messaging

Interactive messaging is used for live transfers of data between the iPhone and the Watch. This is only possible when the app doing the transfers is open on both devices, or when the Watch needs to trigger something directly on the iPhone (such as accessing location services).

Interactive messaging employs a parameter named Reachability (nope, not that Reachability) to determine whether the other device is available for interactive messaging. For the Apple Watch to be considered “reachable” by the iPhone, the devices must (obviously) be connected, and the Watch app must be currently running in the foreground. Continuing their mission to never let Apple Watch apps be active in the background, interactive messaging can under no circumstances work with a backgrounded Apple Watch app.

From the Watch side, iPhone apps are considered reachable on less strict parameters. Of course the Apple Watch app must be running in the foreground, but from there, as long as the devices are connected, the Apple Watch is able to call on the iOS app to be launched in the background. Once it is running in the background, communication can continue. Interact messaging is the only excuse that Watch apps have to explicitly tell their iOS app counterpart to launch in the background at a specified time.

Once the interactive messaging connection has been established, communication can take the form of sending and receiving dictionaries back and forth, or sending and receiving data in the form of a developer’s own serialization structure. When data has been sent in either direction, the receiving end can optionally send a reply confirming successful reception.

So what’s the point of all this? Interactive messaging could be used for a wide variety of different use cases. In one WWDC keynote session that gave an overview of the technique, the given example was one of an Apple Watch game sending data over to the iPhone after a successfully completed level. The iPhone could then display graphs and stats from the completed level in real time.

Interactive messaging is an intriguing feature, opening up the idea of using the Apple Watch’s tiny screen alongside its more spacious iPhone counterpart. I’m curious to see what ideas developers can dream up to make use of the new ability.

NSURLSession

NSURLSession ¹⁰ is a foundation class that has already existed on Apple’s other development platforms for years. I bring it up because it is now newly available for use on Apple Watch with watchOS 2. NSURLSession on Apple Watch allows Watch apps to connect to known Wi-Fi networks and make HTTP requests. This opens up a world of new possibilities for the Apple Watch.

The headline feature made possible by NSURLSession is Tetherless Wi-Fi. With Tetherless Wi-Fi, your Apple Watch can access any Wi-Fi hotspots that you have connected to on your iPhone. The upshot here: if your iPhone and your Apple Watch are out of Bluetooth range, the Apple Watch can remain connected via the Wi-Fi network. While you may not get all of your notifications when the Watch and phone are in this state of separation, any apps that have implemented NSURLSession will still be able to communicate with their servers to send and receive data ¹¹.

Speaking of servers, another feature of NSURLSession is that it allows Apple Watch apps to communicate with any HTTP server, sending and receiving data independently from their iOS app. This means that your Watch apps can actually get new data before even their iOS counterparts have downloaded it.

Just like through WatchConnectivity from the iOS app, servers can be set up to push new content to the Watch in the background as well. This works the same way as when the data comes from the iPhone: it is stored on the Watch at the OS level until your app is launched and can accept it.

NSURLSession can work in tandem with WatchConnectivity to keep load times for Apple Watch apps as quick as possible. Oftentimes, when the Watch app is launched it will want to pull the latest data from cloud servers. However, the iOS app may have already pulled data a short time ago. By implementing the previously discussed WatchConnectivity features, developers can have their iOS apps transfer data across to their Watches so that at least something is waiting when the Watch app is opened. That way, while the Watch may still pull the most up to date information from the cloud after it has been launched, the user will still be able to browse the slightly older data from the iOS app instead of waiting on a blank screen until the cloud data transfer is completed. Once again, not a perfect solution, but it seems like an okay compromise to keep that battery life vs performance equation fairly balanced.

Sensors, I/O, and System Access

Stepping back a bit from nitty gritty implementation details, another huge advantage of native Apple Watch apps is access to Apple Watch hardware. This includes the Digital Crown, Taptic Engine, accelerometer, heart rate sensor, speaker, and microphone. watchOS 2 has also added several other new system level doors for Watch apps to open up and play with.

Access to the Digital Crown is not unrestrained, but rather restricted to a new picker interface which has four different types of layouts to choose from. Similarly to how the iOS date picker always looks more or less the same across apps, this Apple Watch picker will look familiar no matter what app it is found in.

Of the four possible layouts, list, stack, image sequence, and coordinated image sequence, the two most intriguing are the image sequence interfaces. The standard image sequence picker UI will scroll through a series of images without any transitions between them. If developers pick these images well, the result can look like scrolling through a little animation scene.

As an example, the Apple Watch’s proprietary animated emoji use this type of picker. When scrolling through those emoji, you are actually just scrolling through a series of still images, but the lack of transitions and the closeness of each frame makes the faces, hands, and hearts seem like an animation whose timeline is controlled by spinning the Digital Crown.

The image sequence picker actually has a further option as well: a coordinated image sequence. This variation is a lot more powerful than its name might suggest. A coordinated image sequence takes a series of images which might previously have been set up as a different UI element, and instead coordinates them with one of the picker interfaces. As the picker scrolls, the images changes along with it.

This is basically a combination between the list and image sequence interfaces, and if you’ve used an Apple Watch then you’ve probably already come into contact with one of them. One of the most notable examples is the Timer app, which has a list picker in the center that scrolls through numbers from 0 to 59. Surrounding the picker is a circular, numbered dial with an orange ring representing how many minutes the timer will be set for when you start it. This is a coordinated image picker. The dial and color ring are a series of images coordinated with the central picker. When you press start on the timer, and picker interface is dismissed and the value chosen is passed to the actual timer to count down from.

Although the image sequences make the possibilities pretty limitless, perhaps some developers will wish for the freedom to experiment with the Digital Crown outside of various pickers. I’m not surprised Apple hasn’t allowed this yet though, as the familiarity of the interface across apps will result in a more cohesive experience for users.

Apple put a lot of money on the Digital Crown being a breakthrough input mechanism, so it’s probably a good idea to keep the number of places where it can be used narrow at first. This will give new users a chance to better adjust to the idea of manipulating the UI with a spin rather than a tap.

Speaking of Apple restricting features in an effort to foster a cohesive experience, the watchOS 2 app access to the Taptic Engine is similarly regulated. If you were hoping to get custom taps from different apps, or be able to set up your own vibration patterns like you can on iPhone, you’re out of luck this time around. Instead of giving developers free reign over setting off random tap sequences, Apple allows third-party apps to make use of a set of nine different tap patterns. Furthermore, they even dictate under what circumstances each of these patterns should be used.

While I’m generally in favor of allowing more adventurous development, I’m actually a big fan of the decision here. The nine haptic patterns, which are named to describe the circumstances in which each should be used, are as follows: Notification, DirectionUp, DirectionDown, Success, Failure, Retry, Start, Stop, and Click.

If developers take advantage of this access and implement each of those patterns in all of the places where they are meant to go, I think the result could strongly bind each unique haptic to its corresponding circumstance in the minds of Apple Watch users. The effect of this idea is amazingly powerful: users who are able to tell the results of their various interactions with the Apple Watch without even needing to look at the screen. If an action you trigger results in success, you know instantly from the tap on your wrist; if it fails, you know that, too.

This kind of unseen, unheard, yet fully understood personal interaction has never before been possible on a digital device. I can imagine a future in which far more than nine of these haptic patterns exist, and users can navigate the interfaces of their Watches more quickly and with fewer interruptions by never needing to wait to see unnecessary interface elements or dialogue boxes.

Moving on to more new hardware controls, watchOS 2 also grants developers access to the speaker and microphone on the Apple Watch. These allowances include audio recording, and audio and video playback. During playback of longer audio content, users are able to leave the Watch app playing the content without stopping it. Similarly to how Control Center on iOS can play and pause content that might be sourced from any third-party app, the Now Playing glance on watchOS will be able to send play, pause, and skip commands to long-form content being played from third-party apps on the Watch.

Another nice feature here, if playback is directed through the Watch rather than the iPhone and no Bluetooth headphones are paired, the content will play out of the Watch’s speaker. One thing I find quite odd (and annoying) is that Apple’s own Music app does not seem to support this feature yet. Every time I try to divert playback through the Apple Watch when listening to music in the Music app, I get an error telling me to connect some Bluetooth headphones. Maybe a third-party developer will release an app from which I can play my music library through my Watch’s speaker.

Next up: activity sensors. watchOS 2 grants third-party developers access to live data from the heart rate sensor and the accelerometer. The Core Motion and Core Location frameworks can also be used by third-parties (once they’ve been given permission to access the data) to make use of all movement and location-change data. These frameworks record all motion and location movement at all times, and then package up and give this data to Apple Watch apps when they are launched.

If this sounds familiar to you, it’s probably because iOS has been doing this exact same thing using their M-series motion coprocessors to record, package, and deliver movement information to apps since the iPhone 5S.

All of the HealthKit frameworks available on iOS can now be accessed by watchOS 2 apps as well, so third-party apps can gather and manipulate data as it comes in live from sensors, then send it off to the Health app when they’re done.

A small thing to note on the subject of permissions: watchOS apps share all permissions with their iOS app counterparts. This means you’ll never need to confirm those pesky (though important) access request alerts on both your iPhone and your Watch. The first time you use an app that requires access to something it needs to request, it will display an alert asking you to grant said access. If the first time you’re using the app is on the Watch, you’ll only ever see the alert there ¹². Same thing for apps that you use of the first time on your iPhone. If you need to go back and edit these permissions later, you only need to look in the main iOS Settings app for them – no need to go looking for permissions in the Apple Watch iOS app as well.

Other noteworthy new integration and APIs include the following: a new MapKit API allows third-parties to start and stop directions, including transit directions, or open an address in the Maps app. A new workout API lets third-parties begin workouts on the Apple Watch, and as long as a workout is running, the app that started it will return to the foreground every time the user raises their wrist (instead of the watch face). A new PassKit framework gives access to all passes from the Wallet app on your iPhone, allowing you to add or remove passes directly from your Apple Watch. A new animation API will let developers built cool layouts and animations, which could be quite interesting for seeing the first line of cool and truly functional Apple Watch games. A new Contacts framework lets Watch apps access the user’s address book (the permissions thing applies here, too). The EventKit framework allows access to and manipulation of the user’s calendar (after they’re granted permi— oh, you get the point). Finally, a basic openSystemURL API allows for launching the Phone and Messages apps with commands using URL schemes. Alas, URL schemes are, for now at least, not supported for app extensions (all Apple Watch apps are considered app extensions).

First-party Apps in watchOS 2

The updates in watchOS 2 are definitely more geared toward performance through system level changes and third-parties, but Apple’s own first-party apps have received a few notable changes as well.

In the long look notification for Apple’s Mail app, there is now a new button to reply back to a new message directly the notification. I’m not really sure why this wasn’t there in the first place (long look Messages notifications have always had this), but it’s there now if that’s something you want to do. Of course, you’ll still need to scroll all the way to the bottom of the message before you can reach the buttons, since Apple still won’t truncate long Mail messages in the notification view ¹³.

The Friends view on watchOS 2, still inexplicably tied to the “side button” ¹⁴, now allows you to create multiple pages of friends if you can’t fit them all on the first page ¹⁵. You can add friends to a new page at any time via the Watch by swiping to the side from the last page you have set up and then tapping on the plus buttons in the circles to bring up your contacts list. Don’t accidentally pick the wrong contact though, because once you’ve added a friend there’s no way to delete them except to go to the Friends section of the Apple Watch iOS app.

I’m not a big user of rewards cards, so I haven’t tested this feature, but apparently you can add rewards cards for a variety of different stores to the Apple Pay section on your Watch, too.

Siri has also learned some new tricks in watchOS 2. While she sadly is not able to make use of the sweet new “remind me about this” feature that iOS 9 Siri can do, watchOS Siri is now able to start workouts, open glances, get transit information, look up words, and calculate tips. Among other things, I’m sure. Just don’t bother asking her to give you a hint.

For those of you with friends who also own Apple Watches, you can now send them sketches drawn in a variety of different colors, rather than being limited to one color per sketch. When you’re sketching your drawing in the Digital Touch interface, just tap the colored circle in the top right corner. A wheel of color choices will spin out, and you can select different ones to add some spice to all your drawings of flowers, trees, stick figures, and the word “hi”.

While I’m not actually sure if this is a new feature on watchOS 2 or if it’s been there the whole time and I just didn’t notice it (probably the latter; it’s in a weird place), I recently discovered the ability to transfer live phone calls from my iPhone over to my Apple Watch. It’s always been easy to transfer from the Watch to the phone, but going the other direction requires you to open the Phone app on your Apple Watch, press the big green button at the top (which only exists while you’re on a live phone call, so don’t bother looking for it right now), then scroll all the way down to the bottom to find the “Apple Watch” AirPlay button. This feature has been a great discovery for me. When my mom called the other day and I picked it up on my iPhone, I was able to transfer the call to my Watch so that I could finish my game of darts while we talked. We had a great conversation and I beat my record in Around the World, so it was a win-win.

I don’t know what stopped Apple from including Activation Lock in watchOS 1, but their excellent anti-theft feature is finally™ making its way onto their highest-priced platform. Now, while Activation Lock is active (which it is by default as long as you have a passcode on your iPhone), activating your Apple Watch requires your Apple ID and password. Hopefully this will make the Watch much less of an enticing target to thieves, although I guess they could still wear it as a fashion item or sell it for its raw gold.

There’s a useful new Nightstand mode feature in watchOS 2 as well. Its June announcement was a shame for early adopters of some of the upright oriented Apple Watch stands, a group which I sadly find myself a part of ¹⁶. However, I’ve managed to make the stand work with my Watch placed sideways, and while it’s a bit precarious, it’s been good enough for me to test Nightstand mode.

The new mode activates automatically when you attach your Apple Watch to its charger and place it on its side so that its two buttons face up toward the ceiling. Simply tap the screen to make the display light up and show you a large green digital time and icons for battery charge and alarms set. If you set an alarm on your Watch, then when it goes off in the morning you can press the side button to turn it off, or the Digital Crown to snooze it. Rotating your Apple Watch to a different orientation or removing it from its charger disables Nightstand mode automatically as well.

A few other miscellaneous changes I’ve noticed: the passcode buttons on the Apple Watch have been completely redesigned to be much bigger, filling the available space completely. In watchOS 1 I mistapped on those button constantly, but with the new watchOS 2 design, I rarely do so.

Pressing the Digital Crown while on the app honeycomb screen now takes you directly back into the Watch face no matter where you are zoomed or panned around to. In watchOS 1 this action would first recenter you on the clock face, forcing you to then spin the Digital Crown or press it again to enter the Clock.

Finally, an option that I’m pretty sure wasn’t around in watchOS 1 (it’s hard to tell for some of these things because there’s no way to downgrade my Watch to check) is a setting to specify the amount of time for the Apple Watch to keep its display on when it is activated by you tapping it. The default here leaves the display on for 15 seconds, but the option that I believe to be new allows you to change that to 70 seconds. Again, this only corresponds to when you turn the screen on by tapping it, and if you lower your wrist after doing so the screen will turn itself off regardless. You can find this setting on the Apple Watch by going to Settings > General > Wake Screen > On Tap.

Ready for the Future

watchOS 1 was an incomplete operating system. Its implementation of third-party apps was deeply flawed. It lacked some of the barest essentials, such as Activation Lock and Tetherless Wi-Fi. Without the connection to its iPhone, it lost the vast majority of its functionality.

Apple’s work with watchOS 2 has laid the foundation for the future of watchOS. While the update is not a full solution to nearly any of these problems, it creates a solid base for almost all of them. A base which, in classic Apple style, can then be iterated on for years to come.

Third-party apps can now load quickly enough to actually be useful. They can access the hardware sensors and new system APIs to begin building themselves into real mini applications, rather than the sad shells they were previously. They can include complications, to get their data in front of users in new and interesting ways. They can talk to cloud servers, function on Wi-Fi untherered from their iPhones, and transfer data in the background without destroying battery life.

The first-party apps didn’t get much love this year, only receiving minor updates at best. But there were more important things to do. I’m excited to see where Apple starts going with their own Watch apps, as their offerings are fairly sparse at the moment (where’s the Notes app? Reminders? News? Podcasts?). Interesting things could be coming our way as they move more and more of their now fairly extensive line of apps from iOS to watchOS.

Apple isn’t afraid to try new things with the Watch, and I think that’s the most exciting part. Nightstand mode and Time Travel make use of aspects of a Watch that just aren’t available to other devices. Universal action-specific haptic feedback patterns show a peek into an intriguing future of interacting with a device through a combination of sight and feeling, rather than the usual of just sight.

As Apple continues to work within the confines of the Apple Watch’s young hardware, hopefully their decision to take their time with shipping major features like WatchConnectivity and NSURLSession pays off. As the hardware and software mature, they’ll need their foundation to stay strong and functional so that they don’t need to waste time each year reinventing the wheel.

There’s a lot still to wish for in watchOS. Plenty of low-hanging fruit for Apple to pick features from for years to come. Third-party watch faces, granular notification control, custom haptic feedback for notifications, the Music app playing via the speaker, Siri support for “this” commands (that feature just seems built for the Watch), buttons on glances, and so, so much more.

The future seems bright, and limitless for watchOS. A brand new platform with a strong foundation, lots of obvious new features to choose from, and $200 billion at its back.

Tim Cook said the Watch was the next chapter in Apple’s story.

watchOS is the language that chapter will be written in.