3 ways designing for the Apple Watch is unlike anything else

Although the Apple Watch isn’t set to ship until April 24, Apple released the WatchKit SDK to select developers in November, and I’ve been working side-by-side with customers building production Apple Watch apps.

One of the biggest lessons to keep in mind when building for the Apple Watch is that it isn’t about replicating an existing mobile experience onto a smaller screen. It’s about finding innovative ways to extend the functionality of an app.

There are exciting use cases for Apple Watch extensions, like being able to control more and more of our environments thanks to the Internet of Things and getting notifications much more conveniently on our wrists. There are also limitations.

It will be interesting to see what lands in the Apple App Store on Day One — and how well these initial concepts will fare.

Having experimented with WatchKit for a few months now, and working with large brands to navigate this new frontier as they develop their first Apple Watch apps, I want to share some key takeaways from my experiences.

1. We’re not in Cupertino anymore

Designing apps for the Apple Watch is significantly different than designing for the iPhone.

The tiny screen size means that you can’t fit much text into your notifications. For instance, on the smaller watch there are some situations where only 3-4 characters for a screen title fit on the watch face.

Also, you won’t be using UIKit, as Watch apps are a separate UI in the storyboard. Application logic is executed on the iPhone, rather than on the watch itself, in order to save battery life. Because of this, you’ll need to become familiar with the new layout engine that was developed to streamline building Watch apps.

This different toolkit will likely involve a learning curve for most developers, but despite these challenges, I found the new layout engine to be fun to work with. I would love to have seen Apple implement something like this sooner and hope to see a similar option for other Apple products in the future.

2. Communication, animation, and navigation

The thing that is crucial for developers to consider during development is that nothing is running locally on the Watch.

Extensions are small apps that add functionality to the operating system or other apps. If you haven’t done anything with extensions yet, they work differently than a regular iOS app. The Watch extension isn’t your app — it runs in its own sandbox, which makes sharing data between the iPhone app and the Watch app a little tricky. It can take some time to figure out how to use app groups to share data between the two, but there are libraries that exist to aid in this.

Ultimately, at this stage, the Apple Watch is acting as a projector screen: It can only show what it’s told to and send some feedback back to the iPhone.

Addressing these issues of communication isn’t the only adaptation developers will have to make. Although iOS is known for encouraging detailed, beautiful animations within apps, such imagery won’t be possible on the Apple Watch. The much smaller screen will drive developers to be smarter about the way we deploy animations, as given size limitations mean that every animation will require a specific purpose.

Navigation is also different in WatchKit. Apple offers two built-in navigation approaches for developers: swiping to the next page or tapping to the next page. In iOS, you can mix and match between the two in one app. However, WatchKit only allows you to leverage one at a time in an app, pushing developers to be purposeful in their design and to create simpler but more functional navigation.

One of the creative ways to address the aforementioned navigation limitations is through Siri, which Apple is making available to developers for the first time in the WatchKit SDK. Instead of just relying on touch input, WatchKit apps can take verbal input to add items to a list in the app, for example, or audibly access information known only to the app.

3. Not every iOS app needs a Watch app

The main question a developer should be asking is, with such a small area, what aspects of an app are going to fit with the screen size and still be useful and meaningful?

The Apple Watch will be great for apps with functionality that benefits from a brief display — for instance, a light switch display connected to a smart house app that uses geolocation technology or notifications that can be responded to with “yes” or “no.”

Anything that requires scrolling, reading, or too many taps is going to be a frustrating experience on the Watch, and frustrating experiences typically lead to app failure.

Unfortunately, at this point developers won’t have access to the heart rate data points and other exciting HealthKit features, leaving fitness apps with less potential. But I do see some awesome features possible in the future if Apple gives us access to these APIs. For instance, music apps might be able to sync to the appropriate music based on your heart rate.

Conclusion

We’re sure to see many interesting Apple Watch apps come out over the next few months and it will be interesting to watch the ecosystem grow.

Gaming, for instance, is one of the most lucrative markets for an iOS developer and I’m excited to see how game developers attempt to innovate their way around some of the Watch’s limitations around animations. I’m really hoping we see much more than just the use of push notifications in two-player games.

With this new form factor, there is no substitute for hands-on trial and error; the only way to really understand the potential of the Apple Watch is to start building. Adjusting to the layout engine, changes in navigation and animation, and understanding whether or not an idea will work is only possible through downloading the SDK and exploring. Many Xamarin developers are already developing with our Apple WatchKit SDK support just to see if a Watch extension is relevant for their apps.

Soon enough we’ll see exactly how apps are able to flourish on this new interface.

James Clancey is Senior Mobile Developer at Xamarin.