NFurness-esristaff

Building Apps for Apple Watch

Blog Post created by NFurness-esristaff Employee on Oct 13, 2015

This post is based on a talk I gave at the 2015 Esri User Conference about Building Geospatial apps for the Apple Watch (slides). Many of the concepts are applicable to wearables in general, but I’ll be focusing on how Apple have consciously decided to implement these concepts.

 

Big, medium and small

Desktop software has many luxuries, not only in the resources available to it (CPU, RAM, Storage and Network) but also in user attention. When you sit at your laptop, you could be about to engage in work that’ll take a few hours, although it may be more like tens of minutes.

 

In contrast, when you pick up your phone, interactions take seconds or minutes. There’s limited CPU and RAM. Network speed and even availability is always a concern. And you need to be easy on the battery.

 

Now comes the watch. There is little space for interaction (which has serious implications for mapping apps) and short battery life. And a user’s attention is seconds at most. Even 3 seconds is often too long.

 

Apple’s take

These are early days for Apple Watch developers, and Apple wants their users to have a good experience, so here’s some key advice:

 

  • Be ready: Have your information waiting for the user. Don’t make them raise their wrist then wait for something to load.
  • Be specific: Space is at a premium. Don’t include things the user doesn’t want or need to see.
  • Be helpful: This is a philosophy intertwined with “Be ready” and “Be specific”. The user will appreciate it.
  • Do not annoy: While implied by the above, it’s critical on its own. A nagging app will get deleted from your wrist quicker than anything.

 

You need to be really conscious of your user then, with a clear focus on what they want. Get your data early, even before the user wants it, and use a really clean UI.

 

Apple’s recognition of these limitations is codified very carefully into these components of any installed app:

 

Notifications: You alert your user with a Notification. Initially, it’s a short-look notification. If the user decides they can deal with it later, they drop their wrist and carry on with their day. But if they keep looking, you provide a long-look notification with custom UI and optional response buttons. Tapping on either type of notification will open the app.

 

Glances: If the user instead wants to request information, there are “Glances”. These are available with a swipe from the watch face and provide a summary of your app data. E.g. GPS location, current scores, flight status. Glances are not interactive. They’re a single-page billboard of information. Tapping one will open the app.

 

Apps: The interactive part. An app can do almost anything, but the UI is limited by screen-size and battery considerations.

 

Complications: These are tiny pieces of information integrated into the watch face itself (the term comes from the traditional watch industry, and I don’t like it). In watchOS 2, you create your own complications and the user may not even need to swipe to see your app’s Glance.

 

Architecture

In watchOS 1, Apple Watch Apps run on the phone while the UI is on the watch. This means they’re dependent on the phone being nearby, but it also means there’s a lot of chatter over Bluetooth between the interface on the watch and the interface controller on the phone. This can lead to poor app experiences but save battery.

 

With watchOS 2, you are able to write apps that run fully on the watch (I suspect Apple wanted real-world battery usage metrics before they allowed this). A new framework is provided to communicate to the phone should you still need to (and to use the ArcGIS Runtime, you will).

 

This gives you:

 

  • More responsive UI
  • Phone-independent execution
  • Access to watch hardware (Heartrate monitor, accelerometer, microphone, etc.)

 

watchOS1-2.png

 

Limitations

Not all iOS frameworks have made it over to the watch (e.g. OpenGL, so there’s no ArcGIS Runtime SDK for Apple Watch). Some frameworks have come over in limited form (e.g. CoreLocation).

 

This means, for example, that to use the ArcGIS Runtime SDK you still need to communicate with a component of the app running on the phone. It's worth considering how and when you do this, and whether you need frequent access to the Runtime once you've done some work. That depends on the nature of your app and whether it needs to be able to operate without the paired phone nearby, and many apps don't need that. For example, if your watch app depends on point in polygon tests, an ArcGIS Polygon could be represented as a UIBezierPath.

 

Even though Apple Watch doesn't have a power-hungry GPS unit, it does have WiFi and with watchOS 2 it can geolocate itself with limited accuracy and frequency using WiFi triangulation, without contacting the paired phone. There are so many caveats involved that testing in the field is the only way to know if this will be good enough for your app.

 

Think different® strikes again

So at last we get to what this all means for a mapping/geo/location app on the watch.

 

More than anything else, it means you probably have to rethink what your app does for the user. Displaying a map on the watch is of limited use. Interacting with it is even trickier since fingers are always in the way.

 

Crimeglance.pngThe first step is to ask whether you need a map at all. What problem are you solving for the user? Perhaps “TURN LEFT AHEAD”, “3 Indian Restaurants close by”, “You’ve walked 2 miles”, or “High risk of mugging ahead” are more appropriate to present than a map. Or maybe a chart based off the user's location would be useful.

 

Even if you're not using a map, you might still need to do some spatial work. You might be calculating routes or buffers, performing proximity searches, figuring out drive-times. Using the Runtime, as I've already mentioned, means those have to happen on the iPhone (and that's unlikely to be a problem), but if you can think about your work ahead of time then hand off enough information to the watch to monitor progress, then you can build a largely decoupled app. For example, your home's location doesn't change often, nor do locations of restaurants. So if that data is relevant to your app, one set of analyzed data loaded to the watch is probably valid for at least a week and your watch app can function with minimal or no communication to the iPhone in that time.

 

Then consider what subset of your iPhone app’s functionality it makes sense to use a watch for. It’s unlikely to be all of it. Maybe there are only a couple of use-cases out of many that your app covers. Entering an address probably doesn’t make sense. But picking from that list of 3 Indian Restaurants and selecting a time to book a table might.

 

Be personal and personable

Another consideration is what Apple refer to a lot as “intimacy”. You should make efforts to ensure your app feels natural to use. Don’t say something is 47 seconds away, but say it’s “close” or “coming up”. Instead of saying “There are 43 Indian Restaurants within 5 miles” perhaps say “There are lots of Indian Restaurants close by”. And use context sensibly too. The wearer of the watch may be walking, not driving, and while 5 miles might be “close by” in a car, half a mile might be more suitable for walking, so adjust appropriately to “There are 3 Indian Restaurants close by”.

 

Fuzziness is a key component to this. Half a mile might be a sensible threshold for a search, but if there are another 6 restaurants only another minute’s walk further, you’re not giving the user the best answer. Your app might notice this and instead say “There are 9 Indian Restaurants within walking distance”.

 

Lastly you should be prepared for what the user wants to know. Remember, they won’t wait, staring at their watch while you load some information to show them. Try to know ahead of time what information will be useful to them, and have it ready. This might involve you reconsidering some workflows and usecases, but it’s for a good cause, right?

 

Another way to look at that is that a really good Watch App is passive. It trundles along in the background, making sure it's on top of things so that it can show the user what they want to see when they want to see it, and very occasionally tapping them gently on the wrist to tell them what they need to know but haven't thought to look for. In fact, the more the user can avoid thinking, the more they'll appreciate the app telling them something relevant at the right time. Earning the user's trust is also a very personal behavior.

 

Feeding back to the iPhone app

What’s perhaps most interesting about the demands made of you as a Watch App developer are the things it forces you to understand about your iPhone app. Many of the above examples would be well served making their way back to the phone, even if there is still a map involved.

 

But the clearest takeaway to me is that to make a successful app for the watch, you need to take a deep breath, take a step back, and take another look at how your app helps someone with their day.

 

There are early days for building apps for wearables, full of exciting opportunities.

 

Further reading

Read up on WatchKit and what's new in watchOS 2.

 

Check out the following videos from Apple's 2015 WWDC:

 


Think Different is a trademark of Apple Inc.

Outcomes