How to build a Compelling Watch App
Evoking user interest in a 5-10 second Apple Watch interaction
I'm super excited to be here today to talk to you about how to build a compelling Watch app. Now, just before I get started, a little bit about myself. Hi, I'm Kristina, I am a software developer at Intuit and I've been there for about three years now. Primarily, I work as an iOS developer building shared libraries and frameworks that get used across all of Intuit's apps. So we're primarily a financial software company, and so I personally work on building out components that can be used to help read financial data or display it more visually, so charts, for example, is a really big category for us. For those of you that may know me elsewhere, I actually do a lot. I've been really passionate about developing for the Apple Watch, and I have been doing so since, I think, pretty much beta 2 came out, so almost a year now. I write tutorials and post them on my blog just to teach other people how to develop for the watch itself. My other fun fact is that I follow more animals on Instagram than I do people, so my entire feed is pretty much cats, dogs, and bunnies.
How do you build a compelling Watch app that you'll only interact with for five to ten seconds?
01:25: Okay, so back to the topic at hand, how to build a compelling Watch app. So how to build a Watch app, that's the fairly straightforward part, right? But we have this word in here, compelling. What exactly does this mean? Now, I looked it up on Google and it essentially means evoking interest, attention, or admiration in a powerfully irresistible way. Now Apple guidelines stipulate that your interaction with your Watch app should be about five to ten seconds long. Now, this almost sounds impossible, right? How do you build a compelling Watch app that you'll only interact with for five to ten seconds? It's a little bit of a mind-twister there, and I'm hoping that by the end today, you'll be able to walk away with some suggestions and tips on how you can actually incorporate irresistible things into your own app. Now the first one, of course, probably seems like a no-brainer, but it's kind of interesting how many apps out there don't actually follow this, it’s about finding a good use case, or you just should not build one at all. Yeah, I think that second one's a little hard for some people to follow. I know...
So when the Watch first came out, everyone was super excited about it, right? It was a completely brand new platform and I don't know if you can tell, I'm pretty young. I wasn't really around when the iPhone first came out, and there was that huge explosion of tech excitement for that, but to me, when the Watch came out, that was kind of the iPhone experience for me, that very first iPhone experience.
Now, I think Steve Kovach put it best, essentially these are like diet versions of their full smartphone apps, and some of them just didn't make sense on the Watch at all.
03:08: So, I was very excited to do this, and to develop for it, and I'm sure a lot of other companies were too. So, Apple actually launched with the Watch with over 3,500 apps, that first launch in the App Store, and that was amazing. But some of the apps tended to not... Some of the apps were great, and some of the apps were a little bit more interesting. Now, I think Steve Kovach put it best, essentially these are like diet versions of their full smartphone apps, and some of them just didn't make sense on the Watch at all. It's a lot easier for you to look at things like your Twitter feed on your full-sized screen phone than it is to be holding your wrist up like this and then having the screen turn off in 30 seconds and then having to tap it again and scroll more through your Twitter feed, right? So essentially, I want to convey the fact that you need to find a good customer use case for this rather than just taking parts of your app and putting it back onto the Watch. It doesn't really make sense for that. The caveat to that, I would say, is something like Swarm, for example. They literally just made their Watch app their main functionality of their check-in, and that's great, it's a very quick access. So, you really have to look and see which experience makes the most sense on the Watch, and when people can actually use it.
Now, first impressions really do matter. So when I first got my Watch and I was installing apps on it just to check them out, if I noticed an app really didn't work out for me or there was nothing useful in it, I uninstalled it immediately, because look at this little honeycomb thing. It's big on this screen, but it's tiny on my 38-millimeter Watch, right? So it's already hard enough to find the apps that I really want on here and if I uninstall your app, I'm probably never gonna look at it again, no matter what. Maybe if you put out a crazy, new, brand new release, but that's... I actually keep up with the apps that come out. A bunch of people don't even turn on auto-update for their apps, so think of it this way: First impressions really do matter.
First impressions really do matter.
Now, the second thing I wanna talk about is using animations. So if you look at Watch layouts in particular, they seem fairly simple. It's usually, mostly black screen with a little splash of colour. So their layouts are very simplified and you don't wanna clutter it up too much because then, users won't be able to read anything. So, the way that you can bring your apps to life is to actually use animations when you're transitioning between screens or between flows.
05:57: So here's a little animation that I pulled up: So essentially, you can see we have this little Foursquare text flying in from the right side and I can show you what this looks like on the underlying storyboard. So, what we have here is the image with the Foursquare logo but then, we also have a group essentially acting as a spacer. So, this group is an invisible thing that will display in the storyboard like this and then, what you can't see here is that I actually have a label on the far right side of that group. So, that label is actually in the storyboard but you can't see it at all. What you have to do is, within the code, you just modify the width of that spacerGroup and then this actually will bring in the label, itself, all the way in. So, you can see here we have animateWithDuration, here, and so I just set the spacerGroup width to zero, and then this actually does that animation fly-in for you.
One thing to notice though, I don't know if you remember from the video, but essentially, when I did the reset and reset the width to 100, it didn't actually animate that. So, one thing to keep in mind is that the width will animate one way but not the other. Now, the opposite is kind of true for the height here. So, you can actually have elements flying up and down on your screen too. With this, we actually are able to see that animation up and down. It's a very, very similar process. Whatever constraint you want to animate, you put it within this animateWithDuration block and then set the heights accordingly.
...if text input or user input is really important to you and your Watch app, then I would highly suggest using Dictation.
07:51: Okay, next is Dictation. So, I don't know about you, but Dictation was probably the biggest surprise to me that I would actually use on my Watch. I always felt like it would be super awkward to be talking to my wrist in public, or even just by myself at home. I kinda felt like Inspector Gadget, but it actually was super surprising how much it's used. Ian Moore did this amazing survey of 8000 Watch users, and I really wanna call out specifically... Like you can see the percentages for communication is really high, and specifically, this one on the right, 99% of users will send and receive messages. Now, that's pretty compelling, right? That's something that a user will actually go and send and receive messages from their watch almost 100% of the time. So if text input or user input is really important to you and your Watch app, then I would highly suggest using Dictation. Now, there's a... It's actually fairly simple to do. That's the greatest part of this. So, here you can see a pop-up with some text suggestions, but you can also see here, down here, there's also a little microphone. When you tap that, it actually pulls up Siri to take input from the user. So unfortunately, we don't have access to any of the Siri APIs, maybe someday, Apple, but I can show you what this little interface looks like.
So, if you want to add in suggestions for your app, then you just create an array with those suggestions, up here. So, we have ["Hello", "Swift", "Summit"]. From there, you just call the presentTextInputControllerWithSuggestions, and so, you throw in the suggestions here. You put what kind of input mode you'd like. So, in this particular case, I allow emoji cause emojis are awesome. And then from there, within the completion block, completion handler, then you can do whatever you want to do with the dictated input. Now, if it doesn't make sense for your app to actually have pre-canned suggestions, then you can also just go straight to the Siri dictation view here. So, the only really big change is that you're passing a Nil for the suggestions, and I just changed the input mode to Plain 'cause I'm not quite sure how you can dictate emojis, but if you can, let me know 'cause that's awesome.
Apple introduced a new framework called Watch Connectivity, and this allows you to communicate between your parent app and your Watch app.
10:17: Okay, next we have device-to-device communication, and this is probably the biggest thing that I'll talk about today. With watchOS 2, since now our apps are stored separately and now our Watch app is native, we actually have two different data stores between your companion iOS app and your Watch app. So, Apple introduced a new framework called Watch Connectivity, and this allows you to communicate between your parent app and your Watch app. So, Watch Connectivity is kind of an interesting beast in itself. Before, with watchOS 1, we only had, basically, one API that allowed you to send data and that was called Open Parent Application, and it literally just opened up your iOS app in the background and was able to send a dictionary with any data that you wanted through it. But with Watch Connectivity, you now have a ridiculous amount of APIs and it's kind of hard to figure out how to use them. So, I'll go through and walk through this.
So, the first thing that you have to do to set up Watch Connectivity is you need to set up a WCSession, and so what this session does is it acts as a bridge between your extension and your Watch and your companion iOS app. It's only one single session that's created and you'll have to set it up on both devices. So, the way to set up watch WCSession configuration is to import it and set the delegate for either the view controller or the interface controller that you're putting it in. Then, you'll want to actually declare the WCSession. And so, if WCSession is supported, then you'll set it as that default session. So remember, there's only one session available. Then to activate it, you can do this within the init function for your view controller or interface controller. The other thing you can do if you're using Watch Connectivity and sending data in multiple places in your Watch and iOS apps, you can actually also set it up within the AppDelegate and configure the session there 'cause then you'll be able to have it from the very start of launch, and you'll be able to use it across your entire app without having to re-declare WCSession in every single view controller.
So from the Watch to the phone, and from the phone to the Watch, it uses the same exact API, so you can keep those straight.
12:43: So after you've set up your session, now you can actually send and receive data. So, there's multiple different APIs and it really depends on when you need the information and what type of data you're trying to send. But all of them kinda have the same premise. You have a sender and receiver on both devices. So I'll go through and walk through this. So you'll have some sort of application data that you'll wanna send. So we're starting on the Watch in this particular example. From here, our application data actually gets put into our sender. So here, we're sending it through transferUserInfo, and then on the opposite side, once it's actually sent over to the phone, it's received in didReceiveUserInfo. So every single category will have its own sender and receiver. What's cool about this is that you can actually do this vice-versa. So from the Watch to the phone, and from the phone to the Watch, it uses the same exact API, so you can keep those straight. Like I said before, there's lots of different categories on how you can communicate. So primarily this depends on when exactly you needed that information.
Now, the first thing is background transfers. So this is generally for information that's not needed immediately. You're not necessarily interacting with both apps at the same time, and you'll leave it up to the operating system to determine when is the most optimal time to send that information over. All the content is cued in order of when you create it to send it over. The other side of that is interactive messaging. So say you need that information immediately, and you need to have your data synced immediately between both of your devices, then you can use interactive messaging. The extra thing with this is that it also requires reachable state, which differs a little bit between, depending on if you're on the Watch or the phone. If you're on the Watch and you're trying to do reachable state on the phone, then the phone just needs to be active in the background. But if you're on the phone and trying to send it to the Watch, then the Watch app actually needs to be open.
What's interesting about this is it actually overrides all the latest data.
14:56: So with background transfers, like I said before, there's multiple different APIs that you can call depending on what kind of data you're sending. So the first one, we have ApplicationContext, which essentially lets you send a dictionary of information. What's interesting about this is it actually overrides all the latest data. So say, for example, you have user preferences, like user settings that you need to set, and generally, you wanna go with what the latest settings are as opposed to every single setting that they have set before that, right? So you can use application context to just overwrite all the dictionaries you may have sent before, and use that latest one only.
Next, we have dictionary, but in transferUserInfo, we actually keep all the data. So say for example, you're setting up a Watch game, you wanna keep all of your users' player scores, so this would be more useful in that case. Then, last but not least, we also have File where you can also send a dictionary of metadata. So this can be used for images and any other type of file that you're trying to send. Similarly with interactive messaging, we also can send the same things. You have a dictionary which you can call sendMessage and didReceiveMessage as the receiver. In this case, we only have one type for dictionary because interactive messaging assumes that you'll need every single bit of information that's being sent over. Similarly, instead of viewing File, you can use NSdata here, and send and receive that within interactive messaging.
...if you're trying to build a compelling Watch app and 15% of the world's population can't use it, then what does that say about your app?
16:44: The last point that I wanna touch on is accessibility, and I feel like this one is kind of understated a lot, especially for people that don't have to deal with it in their everyday lives. If you think about it, if you look at the actual statistic, 15% of the world's population lives with some form of disability, and disabilities can range in their interpretation and their definition, but this is a pretty significant number. So if you're trying to build a compelling Watch app and 15% of the world's population can't use it, then what does that say about your app? That's not compelling at all. It's not irresistible at all if they can't use it, right? So in order to create an app that actually includes everyone, you'll need to include accessibility on it.
I really loved this tweet. This tweet kind of blew my mind actually. So essentially, what David Storey is saying here is that by designing for someone with a permanent disability, someone with a situational disability can also benefit. So what does that mean? I think this little comic here illustrates it super well. So you have someone with a one arm disability, and you can compare that to someone that also has an arm injury that will heal in like six months, right? But then, you also think of the other case where you're a brand new parent and you're holding your child and you only have one arm available. I remember my co-worker was telling me that apparently most new moms, they have to get elastic waistband pants because they have to do the shimmy and pull-up the pants dance so that they can hold their child and put clothes on. So if you think about it this way, by designing for the 15% of the population with the disability, you're also helping out way more people that you can even count.
Luckily for us, if you've done accessibility work before, it's actually pretty much the same as in iOS.
18:39: Luckily for us, as if you've done accessibility work before, it's actually pretty much the same as in iOS. So with an Interface Builder, all you'll have to do is click on the element that you're trying to set, and you can set the hint and the label within the sidebar itself. Or what you can do also is, you can also set it in the code, too. So whenever you're creating... Like, you usually do in viewDidLoad or on the Watch with awakeWithContext, you can actually set the accessibility hints and labels programmatically too, if you need it there. I have some additional references of course, and you'll be able to see these after. Thanks.
Q1: Great talk. Thank you very much. I was just wondering, aside from the company that you work with, what's probably the most compelling app that you've seen in the marketplace so far, for the Watch?
Kristina: I really do like Swarm. That's probably one of my favourites. So this is probably more of a selfish thing, but I just got a brand new car. It's a BMW i3. So it's my very first electric car, and... Yeah, I'm very San Francisco. But the most amazing thing for me is that I can actually unlock and lock my car from my watch. I can see exactly when it's charged. It notifies me when it's done charging. Like all that stuff is kind of crazy with my wrist. I think Tesla does the same thing. They have a Tesla app where you can do everything like that, too. So, kind of a home connectivity with your Watch, that's pretty awesome to me.
Q2: Hi there. Thanks for the talk. So I tend to find... I don't know if it's the same for everyone else, but when it comes to Watch apps, I don't actually use any of the Watch apps. I just use it for notifications. What are your thoughts on how people interact with the Watch, and how we should design just notifications? 'Cause I tend to find something like Swarm, for example, the only time when I use it is when it tells me to check in, and I check in and it's like, "Oh, it's great." But I would never actually open the Swarm app in the Watch. So what are your thoughts on that?
Kristina: Yeah, that's really interesting 'cause I actually go and open up the glance and check in myself, but maybe I'm more obsessive with checking everywhere I go. But yeah, it totally makes sense. I think that I haven't seen... Like I was just talking to Nick about this earlier. We haven't seen a lot of complications out there, like third party complications, and I think that will be something that's very useful.
Kind of going back to that home connectivity thing, we also got a security system installed and sometimes you walk out the door, you forget to actually arm that alarm, and you can see... And I came up with this idea where you could actually see whether or not your alarm status is set by just a little complication on your Watch. So, there are certain things where I feel like it will make it just more convenient for the user in order to check statuses and do things like that, straight from their wrist or just on their clock face. So particularly, I think complications will be kind of the next big step but it doesn't seem like a lot of developers have really looked in that area yet. I think the only complication that I have is the Panera Bread app and I don't know what I'd really use that for.