watchOS 2: The MacStories Review

On September 9th, 2014, Apple CEO Tim Cook took the stage at the Flint Center for the Performing Arts in Cupertino. This was the very same stage on which, 30 years earlier, a young Steve Jobs had introduced the original Macintosh to the world. The Apple of 2014 was a very different company. Loved and hated, famous and infamous, indomitable and doomed. The only statement about the tech giant that might avoid contestation was that it could not be ignored.

The 9th would be a rubicon for Tim Cook. The late Steve Jobs had helmed the company through every one of its unparalleled series of epochal products. This was the day on which Cook would announce the first new product to come out of Apple since Jobs’ passing. A product that media pundits everywhere were sure to use as a scapegoat to prove or disprove the quality of his leadership.

The words “One More Thing…” overtook the screen, met by raucous applause from the expectant audience. Uncontrolled excitement burst through Cook’s normally calm demeanor as he presented the introduction to his hard work. “It is the next chapter in Apple’s story,” Cook boldly stated before leaving the stage. The ensuing video gave the world its first look at the Apple Watch.

Throughout the next hour, Apple would weave the story that they wanted to tell about the Apple Watch. They called it the most personal device they had ever made. Three different lines were revealed: one aluminum, one stainless steel, and one 18-karat gold. A series of beautiful bands were announced in a variety of colors and materials. Every millimeter of the hardware was described in lavish detail.

They also discussed software. The hardware and software on the Apple Watch were developed together, with full knowledge of each other. The tight integration between them was designed to blur the lines between the two paradigms. Spin the Digital Crown and see the software move in tandem with your turns. Just like an iPhone, you can touch the display to move and tap on content, but push the display on Apple Watch and the content will shrink back as if you pushed the software itself.

Software defines the Apple Watch as much, if not more so, than the hardware which embodies it. But as well designed and integrated as the first iteration of the Apple Watch’s software (aptly named, though questionably capitalized, watchOS) was, it wasn’t perfect. Some might argue it wasn’t even acceptable. Third-party apps were underpowered and massively handicapped by long load times; when disconnected from its iPhone, the Watch was rendered useless for almost anything except telling the time; and with no Activation Lock, stolen Watches could be reset and resold with ease.

Enter, watchOS 2.

Apple announced this new version of the Apple Watch operating system a mere two months after the device was first released to consumers in April. To many, this underscored the belief that the Watch’s initial offerings had not been ready. Maybe this is true, as many of the changes in the update seem like the way things should have been from the start. Regardless, they’re here now, and they’ll be all that the vast majority of Apple Watch users will ever know.

watchOS 2 brings no dramatic visual change from its short-lived predecessor. The platform remains young, and has a long way to go before it reaches any significant modicum of “maturity”. Questionable choices such as the honeycomb Home screen layout, assignment of the hardware side button to the Friends interface, and lack of support for third-party watch faces all remain. But under the hood, in the areas of connectivity, performance, power, and system and hardware level access, watchOS 2 makes major leaps forward.

While the operating system may remain in its infancy, many of the changes introduced in watchOS 2 are beginning to look precocious.

Table of Contents

Introduction

Interaction

The Watch Face and Complications

Time Travel

Glances

Notifications

Apps

Third-Party Apps in watchOS 2

Communication

WatchConnectivity

Background Transfers

Interactive Messaging

NSURLSession

Sensor, I/O, and System Access

First-party Apps in watchOS 2

Conclusion

Interaction

The Apple Watch is a completely different category of device than those that we are used to dealing with every day. Smartphones, tablets, TVs, and PCs are all pieces of technology which constantly jostle for our time and attention. They are sirens, tearing us away from our physical lives for the seductive impunity of our digital ones.

Time and attention are the two most precious resources in the world today, and of all of the devices in our technological ensembles, the Apple Watch is the only one which seeks to return them to us. Perhaps such a lofty goal betrays hubris, but let’s face it, Apple has been accused of less fitting hamartia.

This intention is reiterated in the Apple Watch Human Interface Guidelines:

Apple Watch was designed for quick interactions that make the most of the display and its position on the user’s wrist. Information is quick and easy to access and dismiss. The best apps support fast interactions and focus on the content that users care about the most.

These interactions can be categorized into four main interfaces, all of which are now available to third-party apps on the Apple Watch. Each progressive type of interaction requires slightly more of the user’s time and attention, though none of them should seek to take up a significant amount of either. Organized from least-to-most attention seeking, these are: the watch face (for third-parties, complications), glances, notifications, and apps.

The Watch Face

The watch face is the most important visual aspect of the Apple Watch. It is the first thing users see every time they raise their wrists 1. Prior to watchOS 2, the watch face was also the most locked down part of the Apple Watch.

While this iteration of the OS still does not allow for third-party watch faces, it does open up the space more than it previously was by introducing third-party complications. Complications are extra interface elements incorporated into certain watch face designs alongside each face’s depiction of the time. These connect to apps loaded onto the Watch – or to servers in the cloud – to display content.

In watchOS 1, the only complications were those made by Apple. These included the current weather at your location, your next upcoming calendar event, the time in various cities, and more. With the update, third-party developers have access to these frameworks as well, and while they are still limited to a fairly small set of complication layouts, the power comes from the now unlimited sources for a complication’s content. In demos, Apple has exemplified complications which display the current scores in live sports events, weather forecasts from third-party weather apps, and in/outbound flight times, among others.

Recently, I’ve been testing out a great new app called Streaks. The iOS 9 update for Streaks also includes a watchOS 2 complication that I’ve been enjoying, and is a great example of the new possibilities created by third-party complications.

Streaks is a “to-do list that helps you form good habits.” Basically, you can create up to six “habits” in the Streaks app on your iPhone. These are things that you want to do every week, and you can specify how many times per week you want to perform each task. For instance, I’ve set up a habit in Streaks to write at least four days out of each week. Each day, the circle for my writing habit starts unhighlighted. If I do any writing that day, I can open the Streaks app and tap and hold on that icon to mark that I’ve written. I can then look back at my stats later to see how well I’ve been doing, what my best “streak” of regularly performing each habit is, etc.

The biggest problem faced by an app like Streaks is in getting users to remember its existence. I’ve tried a lot of todo list apps and I always seem to try them for a few days and then forget about them.

Most such apps, Streaks included, have ways of reminding you to check back in. This generally comes in the form of red badges on their app icons, or push notifications at regular intervals. I find both of these modes of “gentle reminders” to be anything but, and generally turn them off immediately. Not surprisingly, I then quickly forget about the app and never come back. Eventually it might get deleted, or just shuffled off into the multi-page “Utilities” folder to never be seen nor heard from again.

I have been astounded at how using the Streaks watchOS 2 complication has solved this problem for me. Streaks’ complication is an exceedingly simple grid of dots. Each dot represents one of my streaks, and will be gray if the Streak has not yet been completed that day, or white once it has been. The tiny complication sits in a corner of my Apple Watch. When I complete a streak, those little white dots glow triumphantly the whole rest of the day. Uncompleted streaks remain dormant. They’re not at all bothersome, but rather, the first truly gentle reminder that I have experienced on a digital device.

While you can’t interact with complications directly on the watch face, every complication acts as a button to open its app. In this case, when I’m ready to complete a streak for the day, I tap on the tiny dots on my Watch to launch the Streaks app, choose the streak I’ve completed, then force touch to bring up the “complete” button 2. Upon returning to the Watch face, another little dot glows happily.

If you’ve ever been a college student, you’ll understand why “eat 3 meals a day” is a streak I’m trying to maintain.

While third-party complications are objectively a win for developers, the true pipe dream for many still lies in designing an entire custom watch face. No one outside Apple knows if they will ever allow this, though I’d bet a lot of money that if they ever do, those custom faces will go through extensive review before being allowed into the wild. The reasoning for this is fairly obvious: these designs are quite literally the face of Apple Watch. As we discussed earlier, Apple has taken great effort to merge the hardware and the software of the Apple Watch into one cohesive unit. They highlight this directly in the aforelinked Apple Watch HIG:

Apple Watch was designed to blur the boundaries between device and software. For example, Force Touch and the Digital Crown let users interact seamlessly with onscreen content. Your own apps should enhance the user’s perception that hardware and software are indistinguishable.

Poorly designed watch faces would be an excellent way to break that seamlessness, as well as to widen the possibility of any bystanders who see Apple Watches in the wild to form a negative opinion of them. Sure, on an infinite timescale it’s hard to imagine Apple not eventually making the feature available to all developers, but I bet they’ll hold out on making that feature truly open for as long as they feel they reasonably can.

Developers may have had a momentary rush of excitement when Apple’s design partnership with fashion company Hermés, announced last week, included a custom Hermés watch face. Unfortunately, this line from the Apple Watch Hermés page on Apple.com probably killed that buzz (emphasis mine):

With leather straps handmade by Hermès artisans in France and an Hermès watch face reinterpreted by Apple designers in California, Apple Watch Hermès is a product of elegant, artful simplicity — the ultimate tool for modern life.

Apple doesn’t even trust a high profile fashion brand to do any more than inspire their watch faces.

Looking on the brighter side of this topic, Apple does at least seem committed to regularly bringing new watch faces into the mix of options. With watchOS 2, we’ll be seeing a series of photographic watch faces join the ranks. These include a time-lapse watch face with six different time-lapse images to choose from, a customizable watch face which will display a digital time and date on top of any photo in your Favorites album, or the same time and date overlay while the entire Favorites album shuffles through in the background (the image will change each time the watch face sleeps and then wakes again).

The time-lapse faces have a nice touch in that they show different time-lapses based on the time of day that it currently is in your area. When you look at your Watch at night you’ll see a corresponding nighttime time-lapse of Hong Kong, London, Paris, Mack Lake, New York, or Shanghai. If you look during the day, the time-lapse will be of the same chosen area during daylight hours.

What disappoints me most about the new photographic watch faces, is that not one of them has support for any complications. I understand that overlaying complications on top of pictures would be problematic since you wouldn’t be sure what color would show up underneath, and that making the images square and leaving blank space at the top and bottom to fit the complications could look ugly. Still, I feel that they could have found some way to make a customizable photo face that is both well designed, and that supports complications. It’s a shame that there is not a single photographic watch face with that option.

If you’re not sold by the design argument, think about this: Apple is listing complications as one of the four main avenues of interaction with the Apple Watch, and yet a full 50% of the available watch faces do not support any complications at all 3. Why are they forcing users to choose between some of the most beautiful watch faces and the powerful utility of the complication interface?

If you’ll allow me to teeter on the edge of nitpicking for a moment, the subject of complication layout and availability is an even wider point of contention for me. I find the seemingly arbitrary variation, and complete lack of customization for the layout and number of complications amongst even the watch faces which do support them to be quite frustrating as well.

For instance, my favorite watch face, design-wise, is the Utility face. However, I much prefer the four-complication layout of the Simple watch face over the three-complication layout of Utility 4. These two faces have the exact same proportions for their timekeeping sections, so it baffles me why there isn’t one further page of options in the Customize section for these watch faces that allows me to change the layout of their complications.

This would only need to show layouts that fit inside of the chosen watch face (it wouldn’t make sense to give the option for the giant complications of Modular on the far more space-constrained Utility), but that could still surface enough of a variety to make the extra page of options worthwhile. As an example, Utility could have the option of a four-complication layout with one in each corner, a three-complication layout with the Large Flat complication at the bottom (this is its current layout), a three-complication layout with the Large Flat at the top, and even an option to have no complications for those who might just want a clean watch face (someone in Cupertino is designing all those complication-free watch faces, so I have to assume there are some people who aren’t interested in them).

Stepping back from my criticisms, the new addition of third-party complications to the watchOS platform is indeed a great step in the right direction. I guess we’ll have to wait to get some photographic and complication-laden watch faces (here’s to hoping it’s in watchOS 3). In mean time, I’ll be sticking with my three-complication Utility face.

Time Travel

Speaking of the watch face, watchOS 2 introduces another cool new watch face-related feature, which Apple is calling “Time Travel.” Time Travel can be activated at any time by simply spinning the Digital Crown on a watch face that supports it 5. Time Travel allows you to peek forward and backward to see what complications will/would have been showing at different times other than the present. The depiction of the time on the watch face will move forward and backward as you spin, along with a little pop-up box displaying how many hours in the future or the past you have “time traveled to”.

For some complications, Time Travel doesn’t make sense. Or maybe it only makes sense in one direction. For instance, Time Traveling a live sports score complication isn’t going to show you what the scores will be in the future, but it can show you all the score changes that have occurred within the last half hour, including the order of those events. The Calendar complication, on the other hand, can be very useful when Time Traveled to show you what item is on your calendar at a certain time later in the day. When you’re Time Traveling in a direction that a complication on your watch face doesn’t support, that complication will just be grayed out until you return to the present time by either pressing the Digital Crown or lowering your wrist to turn the screen off.

Time Travel, and in fact just the general reality of existing front and center on the watch face, has an interesting impact on the implementation of complications for developers. In order to give a good user experience, the state of a complication needs to be shown with absolutely no latency at all times. The moment a user raises their wrist, which could happen at any moment, the complication should be ready with relevant and valid information.

Apple’s answer to this problem is to have complications be created in the form of timelines of information. Apps which have fairly predictable past and future timelines (such as a calendar complication) can present this data pushed out a whole day into the future. That way not only is the complication always up to date for the present time whenever the user looks at it, but when Time Travel is activated the complication can show its state at any time in the past or future without making the user wait for that data to load.

Developers will have two options when it comes to pushing updates to the timelines of their complications. They can either use a scheduled update to get refreshed data at various scheduled times throughout the day, or a high priority push notification which will be delivered immediately to the Apple Watch so that the complication can update its state.

Scheduled notifications are recommended for Apple Watch apps that can predict the timing of updates, such as a weather complication which may only need to refresh its data once per hour. It’s important for developers to know that their requested intervals are only considered a “hint” to the system, not a guarantee. If the system is busy or the power conditions are determined not to be ideal, a scheduled update might be delayed.

For users, this means that their complications may sometimes end up with stale data, or no data at all. Hopefully they won’t give developers too much grief if their complications not updated at all times, because that behavior is probably outside the developer’s hands.

With that caveat in mind, I’ve been running watchOS 2 for months now, and there have only been a handful of times when I’ve glanced at my weather complication to see a “–˚” rather than the actual temperature. Users will likely see this kind of behavior sometimes, but they should not expect to see it often enough to affect their average interactions with a complication.

The other way to update complications, using a high priority push notification, is for apps that cannot predict the frequency of updates. The best example of this is the sports score complication I mentioned earlier. Every time there is a change to the scoreboard in a live game, the Apple Watch complication should be updated immediately. I haven’t been able to test any apps that use this method of updating, but I would expect it to work pretty reliably, as this is basically the only situation in which third-party data updates are allowed interrupt the system at will (more on this later).

All in all, I think the implementation of complications is definitely far past the “good enough” line while Apple is still fighting to balance performance and battery life so carefully on its first-generation hardware. I’m excited to see what developers come up with to make use of all the features at their fingertips with their new access to the watch face through complications.

Glances

Glances didn’t get much love in watchOS 2, but it seems apt to mention them since they’re another of the four main mediums of interaction with the Apple Watch.

From what I can tell, the only noticeable change to glances is an update to the UI of the Now Playing glance. This first-party glance continues to do incredibly useful things which completely break the rules that all third-party glances are forced to follow. Namely, this is the inclusion of tappable buttons on the glance (these can also be found on Apple’s battery and Settings glances).

Apple’s Now Playing glance, in fact, has seven buttons. The top third of the glance acts as a launcher to open the Music app on the Apple Watch. The center third has a large pause button, flanked on one side by a skip backward button, and on the other by a skip forward button. In the bottom third are three more buttons, the left one to “love” a song that is playing, and the right one to add a song to your iCloud Music Library. The bottom center button, when tapped, actually expands out to create a volume slider with two more buttons, for volume up/down. The volume slider can also be controlled by the Digital Crown, and has a nice new circular interface which shows how high the volume is based on how filled in the circumference of the circle is (note that the Now Playing glance lays out differently depending on the content that you’re playing, so if you’re listening to a podcast then you’ll be seeing the old interface still).

I don’t know why Apple is only allowing its Now Playing app to have access to these awesome features. The Now Playing app is virtually the only glance that I ever use, and that is because all of its buttons and volume slider make it extremely useful. I’m intrigued by what ideas third-party developers could come up with to create dynamic glances like this one. It’s too bad Apple isn’t allowing them that opportunity.

Perhaps the new connectivity changes in watchOS 2 (more on those later) will enable even the current implementation of glances, which can only have one button (the entire glance is a button) to be more useful. All of the watchOS 1 glances I’ve used thus far have consistently been unbearably slow to load their content. The only watchOS 2 glance I’ve tested so far is that of Agile Tortoise’s Drafts, which doesn’t actually display any data. As such, I can’t speak with absolute certainty here, but if we assume that Apple delivers on the promises it made with watchOS 2, then the new glances should be far faster. This will be because, most of the time, they will have loaded their content in the background before you even open them to look.

Speaking of Agile Tortoise’s Drafts, it supports an Apple Watch glance which I’ve found quite useful and different than most others. Drafts embraces the fact that the glance is just a giant button to launch the app. The Drafts glance consists simply of a large, pulsating “Capture” button. Tapping the button not only launches the Drafts app on the Apple Watch, but also then automatically activates the Capture interface. This uses the microphone to let you dictate text which is then saved as a new draft when you tap “Done.” A great idea which in my experience has worked super quickly and reliably on watchOS 2. (If you don’t have it already, you can download Drafts on the App Store.) 6

Notifications

The third of the Big Four, notifications are the only Apple Watch interface to be given the ability to interrupt you at will. A simple tap on the wrist from the Apple Watch’s Taptic Engine lets you know that content is waiting. Raise your wrist or touch your screen within a few seconds of the tap and the notification will pop into view.

Notifications on the Apple Watch have two stages: the short look and the long look. The short look is that initial view that you see pop up as soon as you activate the screen after being tapped. Short looks are meant to quickly convey the sending app and the notification’s subject. If you determine that you aren’t interested in viewing the notification at that moment, simply put your wrist back down and the notification will be dismissed.

Keep your wrist raised, and the short look will move out of the way to reveal a long look. Long looks provide the rest of the details from the notification. If it was a message, the long look might display the content (or at least some of it, depending on how the notification was configured by its app’s developer). If it was an event, the long look might show the date, time, and sender. Long looks can also contain up to four custom buttons to immediately allow the user to act on the notification.

While notifications may seem to be the most disruptive of interactions between user and watch, I would actually argue that they are the number one way in which the Apple Watch comes through on its objective to return some of our time and attention rather than consume more of it.

It starts with the tap. If you haven’t felt it before, the Apple Watch’s signature tap is one of the device’s most unique and interesting capabilities. Gone are the phone vibrations that have bothered us all for years, alternating inexplicably between so noisy that everyone around notices, and so subtle that we don’t even feel the movement in our pockets.

A tap is subtle, yet unmistakable. It’s a feeling which conveys an idea that everyone implicitly understands. Taps are not urgent. They simply say, “if you have time right now, I have something you might be interested in.” This is what the Apple Watch offers us – a physical interface to let us know that we’ve received a notification.

If you can’t look at the moment (maybe you’re in a meeting; maybe you’re on a date; maybe you’re with your family), then no one is the wiser that you ever even considered it. If you can, simply raise your wrist to get the short look. It will instantly let you know if this is something you feel like worrying about right now. If not, a drop of the wrist and the notification is gone. But if so, then hold for a moment (or just tap the short look) to open the long look.

In the long look you get the details of the notification. This is where most of the updates to notifications in watchOS 2 are manifested. Up to four buttons can be displayed beneath the notification’s text, along with a dismiss button to send the notification away without taking any action on it (you can also dismiss a long look straight from the top by simply swiping it downward when it pops up). As of watchOS 2, one of these actions buttons for third-party apps can activate the quick reply sheet, allowing users to dictate a text response for the notification to reply with. If the app supports it, you can even use this sheet to reply with the Apple Watch’s custom animated emoji, which send as gifs.

A quick aside: those animated emoji have actually received a significant update themselves. You can now pick from even more of them, including a sick emoji, emoji wearing various styles of sunglasses, emoji that are confused, surprised, frightened, heartbroken, knocked out, injured, sleeping, and more. There are also some new two-handed animated emoji in the third page of options. These include a fist bump, clapping, and raising the roof. It really is quite an update. Particularly with some of those emotions that are hard to express quite right with the standard Unicode emoji, these Apple Watch animated characters could actually start to fill a more useful role. I still don’t understand why the only color options are yellow or bright red, though.

Getting back to the main topic here, long looks in notifications can have entirely custom UIs designed by the developers of their corresponding apps (though these interfaces do have a maximum capacity of four action buttons). Long looks can allow you to quickly deal with notifications which may previously have sucked you into an iPhone app to distract you even more. With each new notification, you can choose to deal with it right away via an action button, or dismiss it to send it to the notification queue (accessed by swiping down from anywhere on the watch face).

Between the subtle Taptic Engine, quick short looks, and actionable long looks, the Apple Watch notification layer in watchOS 2 provides a great arsenal of weapons to either fend off or quickly dispatch digital interruptions without letting them suck us into our devices. We can live our lives; the Apple Watch neither needs nor wants our attention.

Apps

To be frank, third-party Apple Watch apps on watchOS 1 haven’t been good. This is no fault of developers, who have written some interesting and intriguing Watch apps which I would love to have been enjoying for the last several months. Instead, third-party Watch apps have been compromised by unbelievably long load times. Launch a third-party app on watchOS 1 and you will be greeted by a blank screen with a loading spinner. The little white dots circling around and around, often so long that the Apple Watch’s screen turns off. Sometimes they won’t load at all until you’ve tried several times.

Regardless of whether it takes thirty seconds or six seconds, if apps are, on average, still loading when the screen turns off, that is enough to be considered an unacceptably long load time. This problem has made third-party apps unusable to me. Sometimes they work alright, but the excruciating delays occur frequently enough that I rarely even bother trying anymore.

Third-party Apps in watchOS 2

All this changes with watchOS 2. The new OS features a major revision of the architecture of third-party apps, finally allowing them to run “natively” on the Apple Watch. This is a huge win for developers and users alike. Developers will get greater access to the system, including to hardware sensors and I/O mechanisms. Users will see apps open and run far faster, as well as gaining more powerful and useful features.

watchOS 2 apps do still need to have an iPhone app counterpart, and in fact the pieces of the apps behind the scenes are largely the same. The basic structure of a watchOS 1 app is as follows: a user interface constructed by a storyboard runs on the Apple Watch. Powering this user interface is a WatchKit extension, which runs on the iPhone (WatchKit is the framework on which all Apple Watch apps are built). The extension also has access to a data store to and from which it can store and draw whatever data is used by the app. The iPhone side of course runs the iOS app as well, which can also send and receive data to and from the data store.

With watchOS 2, this structure is shaken up. The WatchKit extension now runs directly on the Apple Watch (this is referred to as running “natively”) alongside the WatchKit app (the user interface). There is also a new data store that exists directly on Apple Watch for the extension to store and draw the app’s Watch-specific data to and from. This means that the iPhone side now only holds the iOS app counterpart, and the old data store used by the iOS app.

This structure is more easily shown graphically, so check out the images below from one of Apple’s WWDC presentations.

watchOS 1 App Architecture Vs watchOS 2 App Archietecture

The WatchKit extension is where all of the “brains” of the operation occur. It’s where the app actually runs code to perform the actions associated with the buttons that are tapped in the UI. Since the WatchKit extension is now running natively, every interaction with a watchOS app no longer needs to make a round trip to the iPhone to determine what you want the app to do, and how it needs to respond to that. This vastly improves the speed and responsiveness of apps, as well as allowing Apple to open up all the hardware features of the Watch to third-parties (previously third-party apps couldn’t utilize any of the hardware except taps and force touches, not even the Digital Crown).

So if all Apple did in watchOS 2 was move the WatchKit extension from the iPhone side to the Watch side, what was stopping them from doing that in the first place with watchOS 1? Well, “moving the extension from the iPhone to the Watch” is a deceptively simple way to phrase a much more complicated problem.

When the extension was running on the iPhone, it could always be assumed that an app’s data would be accessible. As long as the iPhone was in a state where the iOS app could access the requested data, the WatchKit extension could access that, too. Furthermore, the WatchKit extension was much more free from power considerations, as the iOS platform has had years of experience iterating on the best ways to run processes in the background to conserve battery life, not to mention that the iPhone’s battery has multiple orders of magnitude more juice than the battery on the Watch. In this scenario, the Watch itself is just a “dumb” display, doing nothing except showing the data that it was sent from the iPhone. That simplified the entire system immensely.

Moving the WatchKit extension over to the Watch means that it is now cut off from the source of its information. This meant that the way the extension interacts with the iPhone, and with the Watch itself, needed to be redesigned. I imagine that Apple probably could have done this in a simpler and more straightforward manner, leaving the way the extension works exactly the same and just making it snag its information through Bluetooth instead of directly from the iOS app and iPhone data store. However, not only would that approach have had much less of an effect on responsiveness (abstracting the latency to a different part of the Watch app process isn’t going to remove it), but it would also likely have had tremendously negative effects on Apple Watch battery life. The Apple Watch does not have nearly the same amount of power as the iPhone, so any processes running on it need to be completely reimagined to function within the tiny device’s power constraints.

If this sounds vaguely familiar, you might recall that Apple faced similar problems getting background processes to run on iOS devices while conserving battery several years ago. This is a problem which Apple is not only good at, but which I believe they probably relish. A brand new platform allows them to use everything they’ve learned from building their previous platforms to create their best visions of how to implement certain aspects on the new one. Apple could have rushed this new architecture out before it was ready, but this may be the only chance they ever get to design the layer of connectivity between the iPhone and the Watch without having to care about maintaining backwards compatibility with massive amounts of legacy code.

Apple took advantage of this same kind of opportunity when they first released the iOS App Store. Back then, Apple had very little control over Mac apps, because they could be sourced from anywhere around the entire Internet. The App Store made the new iOS platform a completely walled garden, entirely controlled by Apple. They could then, and still can, feel free to grip it with an iron fist, enforcing harsh guidelines and sometimes making inexplicable rejections. Since iOS has always been like this, there’s nothing anyone can do about it 7, and complaints can be easily ignored without backlash.

On the other hand, as we’ve seen in the ensuing years of the Mac App Store and Gatekeeper, when Apple attempts to make a fundamental change to a platform that started off another way, it’s a massive uphill battle. Sometimes they can pull it off, like in the transition from Power PC to Intel, but even then they generally have to do a lot of work to maintain some amount of compatibility with the legacy code (hence, why they had to build Rosetta.

With all that in mind, it’s no surprise that Apple wants to step carefully as they build out the infrastructure of the Apple Watch platform. Maybe they should have held back third-party apps entirely until a suitable solution had been developed. I’m sure that that was a hot point of debate internally before watchOS 1 was shipped. Regardless, my bet is that no one is going to care two months from now. New Watch owners will never know the difference, and the several million people who owned Apple Watches running watchOS 1 will move on and forget that third-party apps were ever as broken as they once were.

The only thing that’s certain is this: there was no way Apple was going to rush to ship the solution that they knew they really wanted until it was ready. This was the best opportunity they’ll ever have to freshly design the interface of connectivity between Watch, phone, and the internet. Apple wasn’t going to squander that, nor did they. Let’s dive into the truly sweet solution that they’ve developed for third-party apps on watchOS 2.

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 8. 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 9. 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 10 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 11.

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.

Apple Watch Timer App Coordinated Image Picker

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 12. 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 13.

The Friends view on watchOS 2, still inexplicably tied to the “side button” 14, now allows you to create multiple pages of friends if you can’t fit them all on the first page 15. 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 16. 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 HiRise Dock for Apple Watch by Twelve South

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.

Technically, this truth can be broken, but only by a few very specific exceptions. Mainly, incoming notifications and workouts. It can also be completely broken by changing the default behavior to wake the screen to whatever the previous activity was rather than to the watch face, but I predict very few users are going to enable that (it can be changed on the Watch via Settings > General > Wake Screen > Resume To, if you want to experiment with it). ↩

This interface is actually my main complaint with Streaks. I wish I could just tap on one of the six streaks in the grid view of the Apple Watch app and have it be completed. The touch targets are easily big enough, and a second tap could un-complete it if I had mistapped. Force touch for the sake of force touch is just a waste of time. That said, it's a minor complaint for how well I think the rest of the app's implementation is. ↩

Since no one has actually gotten their hands on the line of Hermés watch faces yet, I can’t tell for certain that they don’t have complications, but none of the product photos for those watch faces show any, and it appears to me that they did not leave big enough margins for any complications to fit. If the Hermés watch faces don’t have complications, then that’s even less than 50% of all watch faces that support them. ↩

Yes, I realize there's technically four complications on Utility, but the one in the middle can only be the date or nothing so I just count that as part of the watch face itself. ↩

None of the watch faces without complications support Time Travel. This does seem to make sense, seeing as how the main feature of Time Travel is to see the complications at different points in time, but it's still just another example of a headline feature that 50% of watch faces can't make use of. I could easily see at least an entertainment value, if not an informational one, in spinning the crown on complication-less watch faces and seeing a butterfly flap, a time-lapse change from day to night, or photos from an album quickly shuffled through in the background. ↩

Update: Unfortunately, Apple rejected Drafts' Glance because it did not show any information, which was exactly what I liked about it. Another example of Apple's excellent and always reasonable and fair App Store review guidelines. ↩

Of course, someone always eventually jailbreaks each iOS release, breaking the walled garden open "for the good of everyone," but jailbreaking will never be done by more than a tiny fraction of iOS users. ↩

Presumably, WatchConnectivity will aggregate content from a lot of different apps that all need to be refreshed, then when one of these "opportune moments" is reached, it will transfer the data from all of these over once. Apps that miss the transfer time will have to wait for the next moment. This is similar to how iOS handles background refreshes. Establishing the background connection takes more energy than maintaining it, so iOS wants as many apps as possible to pull their information while the connection is open, then it closes it and individual apps that want to pull afterward will have to wait for the next window. I imagine that the number of apps waiting to push data to the Watch probably factors into the opportune moment calculation as well. ↩

The one big exception to this rule is for complications. Since complications are on the watch face, and need to be updated in as close to real time as possible so that the user is never seeing stale data, new data pushes for complications will briefly launch the corresponding WatchKit extension in the background to handle the updates. These extensions will be closed after a short amount of slotted time whether the app has finished the update process or not, so developers should be careful to optimize the speed at which with complication updates go through. ↩

If you're not familiar with Apple's style of class names in their programming languages, the NS stands for "NeXTSTEP," the operating system that was the foundation for OS X. Then you have "URL" followed by "Session." Disregard the NS because they prefix almost all of their classes with that, which means "NSURLSession" is a way for developers to create a "URL Session" for their app. In this case, that means their Watch app can access the Internet directly. ↩

I might also mention that when your iPhone and Watch are out of Bluetooth range of each other like this, any apps that have been updated to run natively using watchOS 2 will still be accessible to you. In watchOS 1, when apps had to communicate with the iPhone for everything they did, they simply displayed a no-iPhone-connected image if you tried to open them in this state. ↩

Alerts now exist on the Apple Watch in watchOS 2. They look and work in pretty much the same way as their iOS counterparts. Third-parties can use trigger them too, although I'm not sure how much of a good thing that really is. ↩

Seriously, why doesn't Apple truncate these? While I haven't found replying to emails via Apple Watch very useful, I often want to delete useless emails that come in straight from the Apple Watch notification. If the email message is long though, the long look notification never truncates it, so I have to spin the Digital Crown over and over to get all the way to the bottom just to reach the Trash button. This doesn't make any sense to me: who wants to read long emails on the Apple Watch anyway? And if you do, wouldn't it be more convenient to truncate after ten lines or so and then just make users tap the message content if they want to read the whole thing? That way, for all the times when you do want to immediately delete or reply, you don't have to scroll endlessly first. ↩

Yes, the technical name of the button is actually "side button". ↩

I haven't quite made up my mind yet as to whether the fact that I still only have one friends page is more an indication that I have no friends, or that people who say they message more than twelve people on a regular enough basis to deserve spots on their Apple Watch favorites list are lying. I think I'm leaning more toward the idea that it doesn't even matter since no one presses that button anyway except to bring up Apple Pay. ↩

I'm not really sure why Apple couldn't have provided an option for Nightstand mode to be enabled in Watches that are reseting upright. There's an entire section in the Settings app for Nightstand mode, but the only thing in it is a single switch to turn Nightstand mode on and off. Why not add a second switch for people who want to use it with upright stands? This isn't just a complaint because I own an upright stand. I just find almost every upright stand I've come across to look better overall than the majority of the sideways stands. The Watch looks more regal when resting upright and higher in the air – more important. ↩