Nov 21

Things we expected:

  • WatchKit makes extensive use of existing technologies such as extensions and notifications.
  • The initial release of WatchKit was expected to be more limited in capability with full native apps only being possible later in 2015. That said, this release was more capable than we dared hope for.
  • You can use both Objective-C and Swift to develop apps for Apple Watch. Apple recommends that you use frameworks to share code between your container app and extensions. However, as far as I know in Xcode 6.1 it was not possible to create Swift frameworks for use in extensions. Maybe that has changed in this release.

Things that I thought were surprising:

  • All your code runs on the iPhone and not on the watch hardware. The watch basically acts like a remote terminal: the code on the iPhone sends commands to update the display and receives back messages of the user’s actions. This is a really clever way to limit the power consumed by the app on the watch. To further reduce the amount of communication needed between the watch and the iPhone, all your UI elements are packaged up in the watch app extension and sent to the watch when the app is deployed.
  • No auto layout. Apple has pushed auto layout hard for several years as a solution to dealing with different screen sizes. The Apple Watch seemed like a great test for this paradigm with its much smaller screen. But I’m guessing the reality of battery life won the argument in favor of something much simpler. I just wish the new system didn’t bring back those old memories from Java Swing…
  • Entirely new UI controls. Everything is new in WatchKit. Some things like labels and buttons have some resemblance to our dear friends UILabel and UIButton. But tables work in a totally different way from UITableView, for example. Nothing earthshattering, just more new API:s to learn.
  • Many new interaction methods. Nilay Patel at The Verge counted 15 different ways to interact with an Apple Watch. Many of them would be difficult to discover; you just have to know them. Of course Apple is building on the knowledge that watch owners already have acquired from their iPhones. It still behoves you to follow Apple’s conventions in your own apps so that your customers will know how to use them. Bow to the HIG.

What is the app business opportunity?

WatchKit as it stands today is clearly geared towards creating extensions to existing iPhone apps. (I’m intentionally specifying iPhone here as it does not appear that the Apple Watch will pair with an iPad. In terms of everyday use of the Apple Watch, that makes perfect sense. If the iPod touch will be supported is an open question.) So if you have an existing iPhone app that could benefit from displaying small and time relevant pieces of information on a watch, then you should definitely consider adding this fuctionality. Just like supporting the different screen sizes of the iPhone is necessary for high quality apps, adding Apple Watch support will soon be too. Imagine if an Apple Watch owner is choosing between your app and a competitor’s, and the latter supports Apple Watch but you don’t. Don’t make it this easy for your competitors to win over customers.

App developers with existing apps defintiely have an advantage in bringing Apple Watch extensions to market, since they can focus on just the Apple Watch extension part of development. But that doesn’t mean you should throw in the towel just because you don’t have an existing app that fits this mold. On the contrary. Existing apps will focus on their exising functionality and extending it to the watch as Apple recommends. This will lead to a lot of very similar Apple Watch extensions. This is a great opportunity to stand out by doing something different with an app that is concieved with the Apple Watch in mind. What is currently impractical to do on your iPhone, but would make a whole lot more sense in a watch or wearable context? Looking for some crazy ideas? Checkout the hackathon happening this weekend.

Games?

Games are a great business opportunity on the iPhone, so what about games on the Apple Watch? The current WatchKit APIs are clearly not designed for games, but never underestimate the ingenuity of developers.

You can for example preload images in the bundle that is deployed to the watch. (Apple does this in the Lister sample app where they include 360 separate images to show all the possible states of a progress circle.) The app can then very quickly display the appropriate image. Apple says you can cache about 20 MB of images in this way, which would lead to a game with at most a few thousand distinct pre-rendered UI states.

Another option might be to generate the image dynamically on the iPhone and then send the generated image to the watch. This would allow you to generate any image, but the bottleneck would instead be the speed at which the image can be sent to the watch. As far as I know Apple has not published any specs for this, and it’s something that’s impossible to test with the simulator. This reminds me of the early days of developing for the iPhone and iPad without being able to run your code on actual hardware. There will be many surprises when the soft bits hit the hard reality of resource constrained hardware.

App Review

When coming up with new and innovative app ideas you always have to consider App Review. Will they approve the app that you have spent months of development on? With a new platform like the Apple Watch there is no past history to use as guide. With iOS 8 extensions Apple did add several new review criteria at the very last minute. And there have even been changes after that, affecting apps that were already live on the App Store. That has made many developers unhappy, understandably so because they spent a lot of time developing extensions which Apple suddenly did not allow. I’ve seen developers asking in the forums about clear guidelines on this. If you are considering an idea that you think might fall in a grey zone. File another Radar requesting the app review guidelines for Apple Watch to be published sooner rather than later.

Can customers pay money for Apple Watch apps?

Let’s first look at the technical aspects of selling “Apple Watch apps”. In their current form apps for Apple Watch are extensions embedded in an iPhone app. This is very similar to how Today and Sharing Extensions are delivered. This means that you cannot sell and charge for your Apple Watch extension separately. It is always part of a container iPhone app, which is what your customers will find and download from the App Store. The Apple Watch extension will always be available to a customer who installs your app. You cannot control this by with an In-App Purchase. Also, you cannot make In-App Purchases from the Apple Watch. But since the Apple Watch App Extension can communicate with your container app, you could have an In-App Purchase feature in that app which will unlock and enhance functionality for the watch app. Some keyboard extensions employ a similar mechanism for payment.

The other side of this question is if Apple Watch owners are willing to pay for apps for their new toy. See my earlier blog post for my speculations on this.

Should you wait?

With all the limitations of the first version of WatchKit are you better off waiting for the opportunity to develop real native apps? I would say waiting is a wasted opportunity to gain experience. All third party developers have the same limitations, so your customers will not expect your app to be fully native at this point. Build what you can, learn and get feedback from customers. Iterate. When native apps are possible you’ll be in a much better position to take advantage of the new capabilities. If you have a million dollar idea that will reqire a native app to fully blossom, then you could use a different idea for your learning project lest you reveal too much of your idea too early. But as I’ve said here many times: ideas are nothing, execution is everything. And you only get better at executing by doing it.

The Future

The architecture of WatchKit seems to be heavily optimized for low battery usage on the watch. This is smart because poor battery life will be a product killer for consumers. But how are they going to transition to native apps running on the watch in 2015? Obviously there will be restrictions on what a native app can do, but still it seems that there will be orders of magnitude differences betwen the current WatchKit architecture and native app code running on the watch when it comes to resource usage. On the iPhone, Apple was able to rely on advances in hardware to make new software features possible. Multitasking is one example which was not possible on the earlier hardware generations. But it seems unlikely that Apple will release a second generation Apple Watch in 2015. Everybody knows that there will be new and improved models coming out over time. That’s how Apple makes their money. But if you buy an expensive 24K gold Apple Watch in the first quarter of 2015 it would be harsh to see a second generation with more software capabilities come out within six months.

What should you do next?

If you haven’t done so already, watch Apple’s Getting Started with WatchKit video, download all the related documentation and read it. Then it’s time to get the latest Xcode beta and start playing with the sample code. Note that if you are having issues with getting the Lister project to run, see the developer forums for some helpful advice.

While the Apple Watch simulator in Xcode is cool, it is very difficult to imagine what it will be like to wear that screen on your wrist. If you are serious about creating really imaginative apps for the Apple Watch then you should invest in some wearable hardware. It’s unlikely that you’ll score a prototype device from Apple, so you’ll have to make do with some of the not so good alternatives already on the market. I don’t think the exact features of the device(s) that you select matter that much. It’s more of a mindset and getting your body used to glancing at your wrist. Especially if you are like me and you haven’t worn a watch in decades. What type of information would you want to have glancable? What are some situations where you don’t want to pull out your iPhone? How large must the UI elements be in order to be glancable?

More reading

Apple’s WatchKit homepage
This should be your staring point. Begin with the Getting Started video. The pace is a bit slow at times, but it has great information. Then there are plenty of links at the bottom of the page to explore further.

iMore’s WatchKit Overview by Serenity Caldwell
A great summary of what consumer can expect from WatchKit apps.

Underscore David Smith has been seriously preparing for WatchKit for a while and as usual he documents his path and thought process.
Expectations for WatchKit
David Smith on WatchKit
Developing Perspective podcast #201: On Expedition.
Developing Perspective podcast #204: Delightfully Pragmatic.

Accidental Tech Podcast #92
Marco Arment, Casey Liss, and John Siracusa talk about WatchKit.

WatchKit: Initial Impressions by Ray Wenderlich
A good overview of the technical capabilities of WatchKit.

A day with WATCH
A deeper dive into the architecture and the classes of WatchKit.

written by Nick