Getting Started with WatchKit

I’ve spent the afternoon getting up to speed on WatchKit. It seems to be working pretty well so far so I figured I’d share my process here.

The three most important things to make sure you see are:

  • Overview video - Available towards the bottom of the WatchKit landing page. It feels like you’re sitting in the Presidio at WWDC. Start here.
  • Apple Watch Human Interface Guidelines - You can’t build for a platform you don’t understand. Here is Apple’s thesis on how an Apple Watch app should look and function.
  • WatchKit Programming Guide - Now that you understand what an Apple Watch app does, this outlines how you’d actually build it.

Once you’ve gotten through these three references then download Xcode 6.2 Beta and get started coding. Nothing teaches you a new framework better than actually building something.

Keep an eye on the Dev Forums it looks like the Developer Evangelists are active there answering questions about the platform.

David Smith




Initial Impressions for WatchKit

Today Apple unveiled WatchKit. I am very pleasantly surprised by how capable it is. In my Expectations for WatchKit article I outlined that I thought we’d see a two phase roll-out of the platform. Starting with pretty limited capabilities that would then be expanded at next year’s WWDC. It turns out that I was only half correct. It is two phase but the first phase is much more capable than I was expecting.

In the first phase we will be able to build Glances, Actionable Notifications and iPhone powered apps. The last of which has me most excited.

Apple took a clever approach to handling the extremely constrained power environment of the Watch (at least initially). To start with 3rd Party apps will run in a split mode. The Watch itself handling the UI parts of the app with an iPhone based app extension doing all the heavy lifting and computation. This is architected in such a way as to enhance interactivity (it isn’t just a streamed movie) while still keeping the Watch components very lightweight.

While I’d love to jump right in and start working on native apps for the Watch I expect the result wouldn’t be great for either customers or developers. I like this conservative approach.

Rather than just saying we only get Glances and Notifications, we get to build actual, useful watch apps. Those apps, however, are architected in such a way as to make them extremely battery conscious. I suspect the biggest power draw these apps will have is the networking between the iPhone and Watch. However, optimizing the Watch OS for efficient networking is much easier than building an entire, rich SDK that is similarly respectful.

Next year will likely bring a next generation Watch and an expansion of the capabilities available to 3rd Party developers. Both of which will be informed by actual, real-life experience with the device. Apple is keeping their options open for the future rather than over committing now and then tying their hands later on.

David Smith




Expectations for WatchKit

I’ve made no secret of how excited I am to get started working on Apple Watch apps. At the iPad event last month Tim Cook announced that WatchKit will be coming sometime in November. I’m trying hard to make sure I’m as ready for its release as possible.

So this morning I’ve been re-reading all the official, published information I can find about Apple Watch. While reading through it I noticed that Apple had actually been pretty clear about what developers can expect with the rollout of WatchKit. This has helped temper my expectations and make me more realistic about what will be possible to build at launch.

Rollout

Apple has said we can expect for there to be a two-phase rollout of the WatchKit APIs. The most concrete exposition of this is the Press Release announcing the Apple Watch (emphasis mine).

Apple introduces WatchKit, providing new tools and APIs for developers to create unique experiences designed for the wrist. With Apple Watch, developers can create WatchKit apps with actionable notifications and Glances that provide timely information. Starting later next year, developers will be able to create fully native apps for Apple Watch.

So to start with we will be given the ability to implement actionable notifications and Glances. This is what I believe we are getting with the SDK release this month.

It will only be later next year that full apps will be possible. It is not a stretch to think that later next year is code for WWDC next June. Likely along with WatchOS (or whatever they call it) version 2.0. There is a delightful symmetry with the history of iPhone OS, where we didn’t get a full SDK until 2.0 (though I’m sure people will similarly jailbreak to get a head-start).

This two phase rollout of capabilities makes a lot of sense. Building a fully native app for a device that you’ve never touched, with a radically new form-factor would be a perilous proposition. Doing that for the iPad was bad enough and that was ‘just a big iPod touch’.

First Phase

Reading between the lines a bit it isn’t an unreasonable guess that the two initial capabilities will be deployed on top of the Extensions frameworks added to iOS 8. They align pretty closely to the new Notification Actions and Today View Widgets.

Actionable Notifications

This looks almost identical in capability as the new notifications we find in iOS 8, and helps to explain some of the motivations behind the notification system overhaul it included. I expect we’ll be able to opt our apps into these and then be able to show text notifications on the Watch’s screen along with a handful of button options.

I think Apple is being very intentional with their choice of describing these as actionable rather than interactive. This is a single bounce between your app and the watch. You create a notification, send it, and then get sent back the action taken (if any) from the watch. While you could imagine horrific hacks with this to simulate a more fully featured, interactive native app my suspicion(hope) is that those wouldn’t get past App Review.

To learn more about the new structure Apple introduced in iOS 8 I’d recommend watching WWDC session 713. While the details will be slightly different with WatchKit, I’d be very surprised if the concepts varied greatly.

Glances

Glances look to be something vaguely like Today View Widgets, though with a few additional constraints and caveats. The examples we have seen so far come from the overview video [@ 2:22] and the iPad event’s preamble.


These eight examples in aggregate give us a few clues about what types of things could be possible to program here (though this is entirely speculation).

  • On-going: For the recipe example to be useful you’d expect the clock to count down. So the Glance has some sense of on-going computation, rather than simply being a static image. This could be done on your iPhone and then shipped over to the Watch or running locally.
  • Animatable/Custom: The fitness tracking example loads with the circles filling in progressively and has a layout completely unlike the others. My suspicion is that while these widgets will need to be very lightweight in construction, we’ll be able to define their appearance in a rich manner. Something similar to the Today Widget APIs where we get an NSExtensionContext to live within.
  • Minimally-interactive: Both the physical layout (as a collection of swipeable tiles) and contents of the examples suggest that these aren’t especially interactive. I’d suspect their purpose is primarily informational, acting as a second screen for their hosting apps running on the iPhone. Most interestingly though the Starwood Hotels Glance includes a single tappable link/button. I’d expect things like this to be the extent and type of interactivity permitted.

Second Phase

Next June at WWDC I then expect we will receive the tools necessary to build out more fully capable applications. Just like we have seen with iOS I’d guess this will be a progressive expansion of capability with each successive year. Just as early iPhone OS apps were severely constrained to save battery life, we’ll probably see strict limits on what types of apps we can build initially. We are essentially resetting the battery life equation with this new device. So no background processing or multitasking for a while (with the possible exception of music/audio playback).

Apple has indicated that a few “special partners” have received early access to WatchKit. This will probably also extend out to the Native Apps arena. Apps like Twitter and Facebook are probably going to have the ability to make richer experiences before developers at large. I do, however, hope that Apple doesn’t maintain this tiering for too long. I’d rather have a brutally strict App Review process open to all, than a two-tiered ecosystem.

Conclusions

I couldn’t be more excited to get started. Like I said yesterday I’m increasingly convinced that a device of this class will radically change how I interact with my iPhone. I have a long list of ideas for how I could enhance my existing portfolio with the first phase of capabilities (along with a few new ideas). Then an even longer list of ideas for what could be compelling native apps to build next summer.

David Smith




Understanding the Promise of the AppleWatch

Somewhat ironically before I bought a Microsoft Band I didn’t really understand the promise of the AppleWatch. Now that I’ve worn the Band for a week I can’t wait to get my hands on an AppleWatch.

At the introduction of the iPhone, Steve Jobs famously said (and history has confirmed) that the iPhone was five years ahead of the competition. With their entry into the wearable market Apple doesn’t appear to have the same head-start. The various entrants seem from the outside to be building from a similar cupboard of technologies. Instead of winning on features, Apple is instead leveraging the platform their iPhone lead has built.

Over the last few years there have been two very distinct families of wearable products.

On the one hand there are persistent sensors. Devices like the traditional FitBits and Jawbone UP fall into this category. These are devices you wear on your body and collect data about you all day. To extend their battery life they have generally featured very little in the way of connectivity and display. Their primary purpose is data collection.

On the other hand there are communicators. Devices like the Pebble and Google Wear would fall into this category. These are devices you wear on your wrist that piggy back on your iPhone to provide ready access to notifications, alerts and bite-sized information. To maximize their battery life they typically had very bursty use models, with long periods of idle with short periods of interaction.

It would seem that the base technologies that enable these devices have recently matured to a point that you can finally get a convergence device. Something that combines both persistent sensors with communication and interactivity.

I don’t think it is a coincidence that this last few months have seen an onslaught of devices of this type (FitBit Surge, Microsoft Band, AppleWatch to name a few). It seems we have recently crossed into technological territory where you can make a device capable of both long term measurement while still also interactive and connected.

It is in that context that I am now thinking about the AppleWatch. I bought a Microsoft Band because it is the closest device I could find to an AppleWatch that is currently for sale. Wearing it for a week has been incredibly enlightening. I must confess that when I saw the AppleWatch promos I was intrigued on a geeky level but wasn’t sure how useful I would actually find it. Having now used a device with similar goals I am now pretty confident I’ll love it.

The Microsoft Band does an admirable job at what it tries to do. The data collection it does seems on par with other fitness trackers I’ve used. The physical design is utilitarian but acceptable. Its integration with my iPhone is basic but still useful. But it is a fundamentally restrained device. It sits right at the cusp of being truly transformative for my daily activities.

Only a device that is deeply integrated with the operating system it connects with will be able to radically change my use patterns. I love seeing a text message from my wife on my wrist, but if I can’t reply to it that is only half useful. I love being alerted that a new episode of my favorite podcast is available but wish I could tell my iPhone to start playing to it. These types of actions are likely only possible when the two devices were designed and built with the other in mind.

Right now the Microsoft Band is simply pointing me back to my iPhone again and again. An AppleWatch will be capable of keeping my iPhone in my pocket.

I’m more excited to start developing apps for the AppleWatch than I have been for any platform that I can think of since the original iPhone SDK back six years ago. I really hope Apple allows 3rd Party developers to really take advantage of what a tightly integrated, wearable device could allow. So let’s get started.

David Smith




Invisible iOS Home Screen Icons

Since getting my iPhone 6 a few weeks ago I’ve been continuously trying to optimize the configuration of my home screen. The larger screen means that I now have an extra row of icons to fit onto the screen, but the physical size of device means that I can’t actually comfortably reach them.

Since you can’t arbitrarily place icons on your home screen this means the situation is actually worse. I now have to fill in the top row of icons with ‘stuff’ just so that I can easily reach my main icons without stretching.

I poked around at finding a better way and this was my solution. No weird hacks or jailbreak required.

Update: Yes, I know all about Reachability—but I don’t want to have to use an accessibility feature each and every time I launch an app on my home screen.

It requires that you use a black wallpaper (which I’ve always done anyway). If you don’t, here are two that I’ve prepared for you. Tap the appropriate size for your device and then long press on the image to Save Image.

The reason it requires that you use a black wallpaper is that iOS doesn’t allow you to have any transparency on home screen icons. Any thing with transparency is simply rendered as black.

You could theoretically create cut-outs of your wallpaper and then match them up perfectly on the grid but in reality this wouldn’t look good since the parallax effect on the screen would skew the alignment every time you moved your iPhone.

Once you’ve set your home screen wallpaper to black simply follow these steps to generate invisible icon blanks.

1) Visit this webpage (http://david-smith.org/blank.html) in Mobile Safari. Nothing super special about that page, it simply has a few header parameters set to specify how we want the icon to be rendered.

2) Tap the Action button on the toolbar.

3) Tap the Add to Home Screen button from the Share Sheet.

4) Tap the Add button from the Share Sheet. Do not touch the title field, it will be pre-filled with an invisible character so that nothing shows below the icon.

5) Repeat for however many blanks you want.

6) Now whenever you put your icons into Wiggle Mode you’ll be able to positing these invisible blanks wherever you want them. (Shown below against a contrasting background since, well, they are invisible otherwise).

Enjoy.

David Smith