[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York and L.A. bid on iOS developers, providing them with salary and equity upfront. The average iOS developer gets an average of 5-15 introductory offers and an average salary offer of $130,000/year. Users can either accept an offer and go right into interviewing with a company or deny them without any continuing obligations. It’s totally free for users, and when you're hired they also give you a $2,000 signing bonus as a thank you for using them. But if you use the iPhreaks link, you’ll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them on Hired and get a $1,337 bonus as thanks after the job. Go sign up at Hired.com/iphreaks]
CHUCK:
Hey everybody and welcome to episode 135 of the iPhreaks Show. This week on our panel. We have Andrew Madsen.
ANDREW:
Hello, from Salt Lake City.
CHUCK:
Jaim Zuber.
JAIM:
Hello!
CHUCK:
I’m Charles Max Wood from Devchat.tv. I know this is an iOS show but I am putting on a JavaScript conference and a freelancing conference – January and February next year so go check those out. I’m also doing an iOS conference in April; call for proposals is open so you could go to allrecoteconfs.com and then just scroll down and click on iOS Remote Conf. I’m hoping to have iosremoteconf.com pointed to the right place by the time this goes live, but if that doesn’t work, then just go check out allremoteconfs. Go check it out; I’d love to see some proposals on that conference. We’re just getting started with putting it together. Lots of people who listen to this show have been asking for it so I’m doing it.
We also have a special guest this week and that’s Jeff Kelley.
JEFF:
Hello, from Missouri.
CHUCK:
Yay for a name I can pronounce! You want to introduce yourself?
JEFF:
Sure. My name’s Jeff Kelley. I’ve been making iOS apps pretty much since the beginning and I’m working now at Detroit Labs in Detroit, Michigan and finishing up the beta of the second edition of my book, Developing for Apple Watch.
CHUCK:
Very nice. I’m a budding author myself so I want to ask you before we get in to Apple Watch really quick - what publishing platform are you using to put that out there?
JEFF:
It’s being published through The Pragmatic Bookshelf.
CHUCK:
Okay.
JEFF:
They’ve got a lot of cool books out there and they have their own in-house publishing platform that’s pretty amazing.
CHUCK:
Cool! So you’ve been talking to Dave and Andy or somebody that works for them?
JEFF:
Yeah. They have a staff of editor’s that’s my day to day contact.
CHUCK:
Very cool.
JEFF:
But they’re assistant’s very nice; I just checked my code – not my code but I checked the book into a repository and it has continuous integration, a built server and it goes.
CHUCK:
Sweet. Well, we did bring you on today to talk about Apple Watch. Do you want to really quickly – I’m pretty sure that everybody here is familiar with the Apple Watch and what it is and what it does, but can you just give us a quick overview of what the device is and what it’s about.
JEFF:
Sure. It’s kind of – you can think of it as just a companion for an iPhone, so you need to have an iPhone to install apps on it, to get your data on to it. You can think of it as a second screen for the iPhone so where into comes to writing apps for it, now with watchOS 2, the apps can run natively on the watch but you still have to embed it inside of an iPhone application.
I just think of it as the watch’s companion to the phone with the watch app as a companion to the phone app just to get it that much closer to the user and have things at your wrist.
CHUCK:
So then, how do people decide if they need a watch app?
JEFF:
It’s a good question. You start out with your phone app; it has a certain set of features and not all of it makes sense. If you're making – I like the [inaudible] of the example of an RSS reader. I use RSS readers, I love RSS readers but I don’t want to read my RSS feeds in a tiny live screen. I don’t think that’s a good experience, I don’t think may people so. So you have to figure out what is it that I can do in the app on the order of seconds and not minutes, anytime you have an app where you want to check on the status of something or make quick changes. A good example is an airline app; I want to see what gate I’m on if my flight is delayed. That’s the kind of thing I can achieve in a couple of seconds, just flip my wrist up, tap the icon, see the current status or something.
So that thing where you have timely information that can be accessed quickly, that’s the kind of thing that you want to put in a watch app, or quick interactions like sending an emoticon to somebody – not really long form text – archiving something and saying ‘yes, I saw that’. A good example is the Deliveries app. I use it all the time, especially this time of the year for Christmas shopping. I can see on my wrist which packages have been delivered to my house.
CHUCK:
It seems like some of the notification stuff would be a good candidate for the watch but I know that Apple Watch integrates notifications from your phone to your watch and you can decide which ones you want to see on the watch.
JEFF:
Yup.
CHUCK:
So should you be encouraging your users to just enable the notifications on the watch, or do you want to actually push something to an Apple Watch app that gives them a specialized notification?
JEFF:
Yeah. It depends on what the type of notification is. If you can encapsulate the entirety of the interaction in two or three buttons with small labels – Mark as Unread or Archive – if that’s all you're doing with a notification, then you can probably just get by with your phone apps and any other application. But if you want to have any kind of custom UI with that notification, maybe there’s a picture attached to it or you want to have more of just a standard layout of buttons. That’s when you're going to want to actually make your own app.
In the example of Deliveries, when I see that the package is delivered, I can tap on it and see it in an actual map of where the delivery happened. So things like that, features where you want to give more information to the user on their wrist, that’s when the actual native live [inaudible] comes in handy.
JAIM:
Let’s talk a little bit about the simple case – how do you wire up a notification from your app? So you’ve got an iPhone app but you're not creating a watch app. How much control do we have over the notifications that come out just from your app without dealing with the whole process of setting up a watch app?
JEFF:
Basically none. So all the user – all the control, rather, is given to the user. So would you set up notifications to the phone assuming that the user has enabled it? All notifications go to the watch when your phone is locked and the display is off, and when your watch is unlocked. So if you use any of the notification actions in iOS, those same actions will get shown on the watch notification as buttons.
A lot of apps do this where you could give a couple of actions with a notification, and then the user can just, on the iPhone screen, kind of swipe to take an action from the locked screen. Those same actions will show up on the watch.
JAIM:
Okay. So these re the built-in actions you would do with any notification to your app but they're displayed on the watch?
JEFF:
Yup. Including now, you can reply with text and it’ll also work on the watch [inaudible] dictation.
CHUCK:
It seems like a lot of these interactions are pretty simple mainly because you don’t have a keyboard, you don’t have the screen space to put one on the screen. So what ways can you interact with an Apple Watch?
JEFF:
Aside from poking around at the screen and using the digital crown to scroll up and down or select items from a list in a picker, some of the coolest interactions come from the sensors on the watch. Not so much the accelerometer; you can use the accelerometer; it’ll sample up the moves of [inaudible] around the screen with gravity with the accelerometer. But really, it comes to its own with the health sensors and the heart rate monitor.
One really cool way to interact with the watch is just to wear it while you work out and that experience is pretty much what it’s tailored to. So if the first time you write an app and you see your calorie burn live on the screen, that’s pretty cool.
ANDREW:
Seems like there are three ways you can deliver – I don’t know how to put this, but three experiences you can give people on the watch. There are notifications that you’ve already talked about a little bit, then there are Glances which are not a full app but they're still quick to get to but you can do more with them than a notification; then of course, there are actual apps.
On my own watch, I find myself using things in about that order. Mostly, notifications are the big thing then I use Glances a fair amount. It’s actually rare that I go to the home screen and launch an app. I wonder if that’s true of most people and it also make me wonder how that might inform deciding how you're going to design things for users.
JEFF:
It’s definitely true for me as well. I don’t really use Glances a whole ton but the primary thing that I do on my watch is definitely see and respond to notifications like Twitter notifications. Also, there’s complications so – I haven’t really talked about that yet. Basically, little widgets that you could add to the watch face, and those I use several times an hour or if not, minute. Whether it’s just looking at the weather or my activity rings or – I have my calendar on my watch right now. So on my wrist, it says ‘recording iPhreaks’. That is invaluable and it’s – for an app to make a good complication and get on someone’s watch face is a competitive landscape where you want to be a thing that your user wants to look at every time they lift their wrist.
JAIM:
So what are examples of useful complications other than the temperature which I use all the time?
JEFF:
For that, I’m using Dark Sky which is like the weather app but also gives you notifications for upcoming rain. I’m using Pedometer++ by David Smith to track my steps throughout the day. That one’s pretty cool because it automatically syncs up the watch steps and your phone steps.
I mentioned your calendar in there. There are a lot of cool demos at WWDC with things like home automation, alarms. I use timers a lot with my watch, especially it’s kind of a parenting aid. Being able to set a timer saying, “Okay, we’ll play at the park for five more minutes,” I just look at the watch and see in real time that timer. That’s extremely useful.
JAIM:
What’s the process like for creating an application?
JEFF:
The API can get complicated – no pun intended [chuckles].
JAIM:
It’s the most confusing word ever.
JEFF:
Yeah.
JAIM:
All the programmers hate it. Why do you call it a complication?
JEFF:
It’s this old watch-making term for a thing on a watch face that’s not the time. So you might have an actual watch that does diving distance or something like that and they kept it for the Apple Watch. I don’t know if that’s the best idea because it’s definitely – when you're talking to it, you tell your project manager, “Okay. Next up, we have to add some complications to the app,” they get nervous. So I like the word ‘widget’ a little bit better and people know what a widget is. But to set one up, you basically create what’s called a complication data source.
You set up this complication data source and the system will call you back at certain times and say, “It’s time to update.” You only have so much of a power budget throughout the day. You have to be, very quickly, get the data and give it to the system. You do that by picking one of the built-in complication templates, treating your data into it and then giving it to the system. And if your data is different overtime, you can give the system a timeline of entries; ‘here’s my data now’, ‘here’s my data in five minutes’, ‘here’s my data in an hour’. As time progresses, the system will automatically transition.
So you don’t have to write the code to change the calendar complication from one event to the next; you just tell the system ‘here’s this event’, ‘here’s this event’ and it’s smart enough to tell you when you lift your wrist what the current event is and that’s also how the time travel feature works.
So as the user moves the digital crown up and down, it’ll go into the future and into the past. If you have everything set up in a timeline, you don’t have to do anything special to get that to work; it’ll just look at your calendar or whatever the app is and automatically show the user the relevant information from that time period.
JAIM:
So how much control do you have over how the complication looks? Is it limited to text? Can we do images, graphics, moving?
JEFF:
It depends on the template that you choose. Some of them are two lines of text, some of them are one line of text; some of them are an image in text, some of them are just an image. So you have that combination of things to choose from as progress rings that fill up along the outside with either an image or text.
Aside from that, you can also choose tint colors. Not every watch face will honor those so I typically keep mine at a specific color, but you can also instead of choosing color for your watch face, you can choose multi-color; whatever color the developers chose will be used as the tint color.
To me it looks kind of bad, for lack of a better term, to have all kinds of different colors. I use the module watch face, so I’ll stick to a specific color. But if you have a brand color, you can definitely set that up. It also depends on which watch face the user selected. Modular has the biggest range of templates but if they're using one of the other watch faces without so many things like utility, you're really limited to lines of text or an image in the corner. You have a whole ton of room for your complication.
JAIM:
Okay. So if you create an image complication and they're using a face that doesn’t support it, it’s just not going to be available to pick from that?
JEFF:
Yes. Either it’ll be unavailable or it’ll be just in one of the corners; pretty small. If you think of a hierarchy of where these templates are – every watch face has a set of, for lack of a better term, sockets that you could put a complication into. The template’s available to you depending on the size of that socket; the small ones are on the corner, pretty much all of the support. The modular has the big one in the center, utility has one long one at the bottom so on and so forth.
You tell the system ‘here are all of the types of complications I support’ then it will, for all those types, you’ll be in the list of apps the user can choose from. When they choose your complication, the system will start asking you for data.
JAIM:
Very cool. So with Watch 2.0, there are a lot of changes to how people are building their apps. Can you walk us through what the difference is between the watch extension and the watch app? It causes a lot of confusion for developers.
JEFF:
The watchOS 1 came out with WatchKit, and the way that Watch apps work was that there was a WatchKit extension in your iPhone app that would run on the phone. Then on the watch face, you’d see all the viewer UI elements and interaction will go back and forth between the phone and the watch all over Bluetooth. As you can imagine, watchOS 1 was not too responsive. They tried to do things to help it out but at the end of the day, Bluetooth is only so fast. So the original watch apps have a reputation for being pretty slow and it was pretty deserved.
With watchOS 2, you still have that same WatchKit extension. Now, when you install a watch app, that extension is copied to the watch and the code actually runs on the watch processor. So it’s not as fast as your phone to process but the communication with the UI layer is pretty instantaneous as opposed to going over Bluetooth.
You can still communicate with the phone if you need to but for many apps, you don’t. Now you’ve got this tiny little device running your code and there’s still a layer of separation between the watch app and the WatchKit extension but now that barrier is just on the same device.
So for things like copying image, whereas before you would set an image on the UI and then wait for that image to copy over before it’s displayed, now it’s the same device so it’ll display immediately.
The nice thing about that is that it forces you to adopt the MVC paradigm. You can’t have views that know too much about your models or do too much with your models because you don’t really have direct access to the views and you can’t read data back off with them. So I can set the text on a label but I can’t read the text through a label, so that prohibits me from doing bad programming things like performing an action based on the text of a label as opposed to some internal state that I should be keeping track of.
JAIM:
So where would the model of an MVC live? Is that in the extension [crosstalk] or in the app?
JEFF:
Yes.
JAIM:
Okay.
JEFF:
So your model and your controller classes are all going to live in the WatchKit extension. Then the view would be in the watch app; that’s also where your storyboard lives so it’s interesting. All of your interface controller subclasses – that’s the replacement for a view controller – all those classes are in the WatchKit extension but the storyboard, which is where all the outlets are set, is in the watch app so they're entirely different bundles.
JAIM:
If you want to share a code between the two areas, is it possible?
JEFF:
Yeah, absolutely. You can – you make shared framework. We have a framework for the app I’m working on now that compiles for both iOS and watchOS. It’s a little tricky to set up because you can’t have one target in Xcode that has multiple platforms so you have to have one target for the framework for each platform but you can share files between them. There aren’t really too many portability concerns because it’s all based off of iOS so you can use the same foundation classes.
Even parts of the UI kit are in watchOS, just not things like UI view controller for instance.
JAIM:
Do you spend any effort keeping things compatible with the first version watch or is that just gone away at this point.
JEFF:
You can. We haven’t so we figured that most of the people who bought the Apple Watch early on are the early adopter type. Every Apple Watch can update to watchOS 2 so it’s pretty safe to assume that everybody who is enthusiastic about the watch will be updating to watchOS 2 if they haven’t already.
The group of people that have an Apple Watch but haven’t updated it, they probably are the same group of people that isn’t really using their watch so it doesn’t really make sense to cater to their needs. They're probably never going to see your app.
You basically need to maintain two apps at that point. You have your WatchKit 1 app and your WatchKit 2 app and the system is smart enough to install the newest one. I personally think it’s worth the effort to keep watchOS 1 app active.
There are some times where you might have a watchOS 1 app. Overcast is a good example where the paradigm worked much better for Overcast on watchOS 1 app where all the data lands on the phone and it interacts directly with the phone to play your [inaudible] podcast. There isn’t an Overcast watchOS 2.0 app because that app will have to answer the question ‘what do I do when the phone isn’t present; how can I be an independent app’. So if your app is completely dependent on the phone, it might make sense to just keep shipping a watchOS 1 app until such a time as you can make one that truly is native and runs on its own.
JAIM:
That makes sense. So in your book, you spend a lot of time talking about HealthKit. When I’m using my watch app, a lot of the apps I’m using are the workout apps or I’m timing things and getting heart rate information. Can you walk us through how developing is for that?
JEFF:
Sure. If you ever use HealthKit before, you're going to learn to love types because HealthKit has a lot of different types. You might have a quantity type to represent calories burned or a quantity type to represent distance that you’ve run. It’s a very formalized API were everything is typed in such a way as you really know exactly what data you're putting in.
For instance, one of the things we do in the book is go for a run. So we know – the distance says that you’ve run in a given time. We know the calories you’ve burned from the watch and those are all saved the same way as samples, so it’s kind of more scientific way of looking at it. Then you create a workout; in this case, it’s a workout with the activity type of running. You give it a start date, you give it an end date then you save it to what’s called a health store. The health store is your interaction between your app and HealthKit.
Once you’ve created this workout object and you saved it, then you can associate samples with it. This is how you do things like contribute to the activity ranks on the watch. You save the calories burned with the workout so it knows to put your app on the list. Once you’ve done that, everything is all good to go, you're saved on the watch as well as [inaudible] with the phone.
One of the interesting things is that all the health data lives on the phone and not all of it can come back to the watch. One of the first things I tried to do was write a complication that would look at one of the new HealthKit categories in iOS 9 is water consumption. I just wanted to make that complication to see how much water have I consumed to day compared to a goal of – I don’t know what you recommend – eight cups a day. It turns out, a WatchKit app can’t directly access that HealthKit data; you have to go to the phone but the phone can only access health data when it’s unlocked.
It’s a very secure API as well. You have to ask for permission before you do everything and the user has to approve down to the individual level. So a user could approve that your app can read and write calorie data but can’t write diet data so it’s a very fine-grained set of permissions as well. With the microphone on iOS, it’s like a yes or no. do I have permission to use the microphone? HealthKit is much more fine-grained than that.
JAIM:
Now, this app we’re talking about, will you input diet information from the watch or is that just part of the whole system that would be down through the phone?
JEFF:
Yes. You can input pretty much from anything. You can add data from HealthKit to the watch even at times you can’t read it. That’s kind of interesting.
JAIM:
So if you're tracking heart rate trying to make your own running app, does it need to be running the foreground? Or does it still operates – you still get readings in the background?
JEFF:
Yes. One of the cool things you can do is you can start a workout session, and this is a way to keep your app running even though you're not necessarily in the foreground. Not only can it be running on the watch where you can get reading on the watch in the background, now you’ve set up what‘s called a query.
In my code, I have a query that runs that’s continually getting new samples of the user’s heart rate. As those samples build up, HealthKit will call into your app and execute a handler that you give to this query.
It doesn’t necessarily run it every single time a new sample comes in so it will call you with maybe four or five samples at a time. But you do have the ability to keep running in the background, get new samples as is appropriate for a power consumption and then process them. Then when you have an active workout session, you’ll notice there’s a little running person at the top of the device to indicate that there’s a workout going on and also the heart rate monitor will be active so you’ll be getting a lot more heart rate samples than the watch collects at resting time.
So you have this workout session, you start it, you start collecting data, you save all of your data to a workout and then you can end the workout session and then update the workout with all the data you collected.
It’s a laborious process; it’s very verbose. Your class is going to be pretty long dealing with HealthKit stuff. You have to spell everything out but once you do it and once you get all the pieces together, it works really well.
All the issues I’ve had so far with HealthKit are just along the lines of ‘I wish I could do this but it’s not allowed’. I haven’t really seen any straight up bugs with it yet.
JAIM:
What new things were released with Watch 2.1? That just came out, right?
JEFF:
Yeah. That was a surprise; we didn’t really get any betas of it or anything. One of the new things is you can have right to left languages. This was interesting to me because none of the watchOS APIs at that time supported that, so now there’s a new API that will cover how to handle using the right to left language. So for a specific control, it might make sense if the example they gave is fast forward and reverse. Sometimes it makes sense for your control to just follow the language of the text, sometimes it doesn’t so you can give that, as part of your UI settings, to the device which will automatically do the right thing for right to left language.
I’m really happy that this came out now because I haven’t yet written a chapter on localization so I get to start with that and if I had started already, then I’ll be going back and do a lot of revision.
Localization is one of the challenging issues with the watch because of just the limited amount of space. The old joke is that German is twice as long as the US when it comes to laying out buttons and labels but it’s true. A small device like a 38mm watch, you really got to be careful that your localized strings all work and that you can split things into multiple lines if you need to.
JAIM:
Give me that one word that wraps three times. [Crosstalk] Yes.
JEFF:
Yeah. One of the things I noticed is that even when displaying an alert, watchOS is a very aggressive about hyphenation. Just take it as many words on screen as possible. It’s a challenge; it’s such a small device to fit things.
JAIM:
That’s why we have emojis, right? [Laughter]
JEFF:
Yeah. Then, there are text settings so you have accessibility settings on the watch where I can go in and increase the text size to the maximum. Combine that with a super long, translated word and you’ve got a challenge for any designer.
ANDREW:
What do you have to do to make sure your app works well on – because there are two sizes of watch, right? One is 38mm and the 42mm? They actually have different screen resolutions if I remember right?
JEFF:
Yup.
ANDREW:
So do you have to go out of your way to make sure things work well on both sizes?
JEFF:
It’s interesting because the difference in screen sizes is 4mm. on any other device, that would not be a huge difference but because it’s a larger proportion of the screen, it does make sense to have different UIs. Most of the time, one UI will work great for both but the way that you get around it is you can – for an instance for an image, you can specify different images for the different screen sizes so have a larger one for the 42mm. You have different font sizes, but also when you're laying things out, you could have an off-set for a specific screen size. It’s like size classes on iOS, only that it’s just two to choose from.
If I have a label, I can come in to Xcode; for its alignment, I can be aligned to the bottom on the 38mm but to the center on the 42. Pretty much any setting that you’ll do on the UI in the storyboard, you can specify either an alternate value for one of the screens or an adjustment to a value for one of the screens.
Then in Xcode, if you have a certain screen selected in your storyboard, there’s a preview in the assistant editor where you can see both watch faces – watch sizes side by side to make sure that it’s going to look good on both.
ANDREW:
Alright. So they’ve given you tools to make that. Not such a painful thing. And I know from – [crosstalk].
JEFF:
There are things in the system displaying alert controller or things like that where you're invoking system UI where the system will just take care of taking that text and wrapping it as is appropriate.
For those situations, you should always test the smaller values to make sure you don’t cut anything off that you don’t want to.
ANDREW:
A lot of iOS developers end up with a collection of devices to test on because, for whatever reason, we don’t want to just rely on the simulator. I wonder – does it actually make any sense to have more than one watch if you're really serious about this? I hope not because I don’t want to buy one. [Chuckles]
JEFF:
I would say, if you are one developer and you're making a watch app, you can get by with just one physical device. The UI is going to be the same from the simulator to the actual watch. The reason you want to have an actual physical device to test on is more for performance, that kind of thing. The two watch sizes are pretty close, if not the same, for all the performance specs so I wouldn’t worry about getting a second watch just to test apps on.
One thing we did notice here though was that we had an image with a gradient. The Apple Watch Sport versus just the Apple Watch with the stainless steel, they have different screens slightly. The Sport has a glass cover whereas the steel one has a sapphire cover. I think there might be even different display technologies slightly because we noticed that the same image would look just slightly different on the two watches, enough that it was the kind of thing where the client would tell us ‘this doesn’t look like’. We were like, “What are you talking about? That’s great,” but we were looking at it on my watch and they had a different model of watch.
I still don’t think it’s enough of a difference to buy a second watch but if you have a friend who has a second watch with a different size or a different screen, I might make sense to throw them a test play invite and have them run on the watch and make sure everything is good.
JAIM:
I have seen developers wear two watches at once because they're using one for testing.
ANDREW:
I think Steve Wozniak wears five or six all the time.
JEFF:
Yeah. I definitely – when we got the test device, I had one on each wrist just for a little while just to play with it.
CHUCK:
Do you get twice as much time that way?
JEFF:
You do, it turns out. And you can go forward and backward at a time at the same time.
CHUCK:
Sweet!
JAIM:
You’re a workout machine. [Chuckles]
JEFF:
Yeah, double the calories for free.
ANDREW:
It seems like when WatchKit 1 first came out, one of the big problems was that everything was super slow. Just launching an app was slow, tapping a button in an app was slow and usually just stared at that spinner. I wonder how – well, I think that’s gotten somewhat better with watchOS 2 but I also wonder how, as an app developer, you can take steps to minimize those delays because for me, as a user, they're the most frustrating part of the watch and they sometimes make me feel like it’s not even worth using.
JEFF:
Absolutely. For that, there’s nothing you can do about the spinner that shows up the first time your app is launched. There’s just some work that the watch is doing. I’m not sure exactly what it’s doing but the first time an app is launched, it’s just going to take longer. Once it is launched, one of the key things is to always be doing something. What it [inaudible] showing some kind of image to say that you're loading or you're having something bouncing back and forth. You don’t want your user just looking at an empty screen. Even if it is taking a while to do something, if you have animation going, I can get the illusion of it being more responsive than it is.
Typical things from iOS still apply so you're drilling down into a hierarchy of data. You don’t want the user to tap on something and then have to wait for, say, a network request to finish before you go to the next screen, you want to go to the next screen now, start at the network request immediately and update that screen when the new data comes in. The more things like that you can do, the more responsive your app will feel.
One of the things you can do with your iOS app, there’s a framework on each OS – so on watchOS and iOS – called watch connectivity. When you have a watch app, it’s installed and repaired, you can transfer data from one side to the other.
One useful technique is anytime your phone app loads data even in the background, you have – it’s called an application content. So you can save a dictionary of data to the watch even while your app isn’t running. So instead of your watch app relying on the network every time, you can send little pieces of updates in the background as you get them on iOS then they're already there ready to go on the watch so the user doesn’t have to wait for them.
CHUCK:
One thing that I’m wondering about now is – let’s say that I have an existing iOS app and I decided that I have something that I want to put on the watch. Is there a good starting place for that and are there good courses – obviously there’s your book but are there other resources that give people a good introduction to this?
JEFF:
Yeah. There’s my book, there’s a few other books as well and tutorial sites. I would say some of the best materials for beginners are WWDC videos. It obviously depends on what type of learning is best for you. I’ve always found videos to be extremely helpful. Even when I was first learning iOS, one of the first things I did was I bought a video course. There’s a lot of great stuff in WWDC videos for this year especially on the design side. So if you're going to be developing and designing an app at the same time, it’s very useful to see how to use animation in an app, see some of the design concepts behind watchOS.
You can start there; maybe get a book or two, read through those and then whatever suites your learning style the best. For me, it’s – let’s make a sample app and start poking your element and see what we can do. For others, it might be more studying, what they can read in the documentation.
CHUCK:
And to get that sample app, is it a separate app in Xcode or is it part of your iOS app in Xcode?
JEFF:
If it’s going to be a part of that app, it will be a different target in that same Xcode project. So you have your iOS target and then you actually need two more targets; you need one for the watch app and one for the WatchKit extension. Xcode will make all that for you so if you just do a new target in Xcode, one of the options on the left is watch OS application and that will do everything you need to do to get set up.
One of the cool things about – there’d be two more targets is if you're not using a wildcard app ID for your provisioning, you need to have two more provisioning profiles for each app. It’ll be all love for visioning profiles.
CHUCK:
Yay, provisioning profiles! [Chuckles]
JEFF:
Yeah, it’s one of those things we have to deal with. Hopefully, if you're using something like Fastlane – I just listened to that episode – that would help provisioning [inaudible] provisioning is.
JAIM:
WatchOS 2.0 came out, development for it, at least the initial was pretty painful. I knew [inaudible] – did a Watch 2.0 app and want to get released, it was pretty painless. Has that gotten better with new Xcode releases?
JEFF:
It’s gotten better – a little bit. So there are definitely some pain points. You can sit there and wait and wait for –. First, Xcode has to copy the iPhone app to your phone, then your phone copies the watch bundle to the watch. Once that’s copied, now you can finally start a debug session and launch the app.
JAIM:
At that point, your phone has – your watch has gone to sleep and turned on its display [crosstalk] and then start over.
JEFF:
Yup. It can definitely be frustrating when you have to sit there and wait, especially when you're using Swift at all because not only do you need to copy all of the Swift libraries to your iOS app but also to your watchOS app. That’s like 30-50 megs of overheard right there just because you're using Swift.
Once it’s all copied, sometimes Xcode will just fail to launch the app. It’ll say ‘finished running device’ and you look at your device and it’s still [inaudible] a watch face and nothing happens. It’s installed but you really wanted to launch it in the debugger and that could be frustrating.
One of the things I’ve learned is to lock your phone, run it in Xcode, it’ll copy everything over but then Xcode will prompt you to unlock your phone to continue debugging. When you do that, at that point, everything is copied and ready to go so it’s a lot faster to start. I’ve had a lot better success locking my phone every time.
JAIM:
Ah. That was the tip I need.
JEFF:
Yeah. Even in the simulator, sometimes the watch app will just fail to install. So when you're in a pretty intense debugging phase, I developed a reflex of – go into the device’s minute Xcode, deleting the simulator device entirely and then just creating a new one with the watch device on it just to have a more reliable first launch of the app as opposed to waiting on it to install and having to fail.
Thankfully, things have been getting better with every Xcode release. It’s nowhere near slow as it used to be. On that front, things are looking up.
JAIM:
That’s good. One other thing I have trouble debugging with on the watch app I was working on was trouble with the communication between the watch and the actual phone, trying to see that things are getting created and debugging both sides of it. Do you have any tricks for that?
JEFF:
Yeah. It is actually possible in Xcode to attach the debugger to both the watch portion and the phone portion. What you can do is you can start the WatchKit app and then in Xcode, you select debug and then attach to process and you’ll see the iPhone process there as well. You can have two debuggers going at once which is really useful for just adding additional logging to all the process or setting break points in both apps.
If you're trying to debug on the phone, one thing you might know – on the device, rather, is you might notice that you send something to the watch, you send something to the phone and it’s batched and it’s not sent immediately.
One of the things you can do to help that process along is to perform some action that is sent immediately. One of the easiest is to go do the watch app on your phone and just adjust the layout of your app icons. That’ll get sent over immediately and also because the [inaudible] get kick on, it’ll do all that synchronization of data.
If you're using the WatchConnectivity WC session to synchronize data back and forth, whether it’s your application context or just one of user info dictionaries, because those aren’t sent immediately, that can trigger them to be sent now; then you’ll see the effect on the other side.
There’s another API in Watch Connectivity which is send message with a reply handler and that is more instantaneous. That will get sent, if it can, immediately. On the other hand, that will also fail if the devices can’t reach each other. So if it’s something where you don’t care how long it takes to get there, doing some of the other methods to share more data might make more sense but from the watch to the phone, that’s always assumed to work if the phone is present so it’ll link up your app in the background if it needs to. From the watch to the phone, you can use the send message API to get a more or less immediate response from the phone. That API actually replaces how all communication with the iOS app work in watchOS 1.
There was an open parent application call where you could open the iOS app with a dictionary and get a dictionary in response. That’s how send message works that just moved that away from. It was the interface controller first and it really didn’t really make sense.
CHUCK:
Yeah, I like the approach, too, just because in my experience, most of the problems that I run into are at the edges of the different applications. Where, in this instance, the watch has to talk to the phone, the phone has to talk to the watch; the right stuff gets in to the right place and does the right thing is probably we’re more likely to have the problem as opposed to where everything’s in the same code base. I can just run some tests against it even if it’s some end to end interaction test and just know that it did the right thing in the first place.
JEFF:
Right. So you just mentioned testing. [Crosstalk]
CHUCK:
Oh no, I opened the can of worms.
JEFF:
Oh you did, I suppose. One of the things to make this frustrating is that you can’t really unit test, or you live test any watchOS app you can have shared code that is unit tested, so if you have a library shared between the two, that library can have unit test. But it’s impossible without a storyboard to create any interface objects on watchOS, so you can’t create an interface controller on a scratch; you have to create it from a storyboard. Until such a time as Apple has awaited – has a test target for watchOS, there’s just a lot of code that you're not going to be able to test effectively.
That can be frustrating in these situations where you're relying on a device to communicate with another device over Bluetooth to test your code and you just wish that you could make some more advanced test harness to get everything [inaudible] away.
It might be possible to really hack something together but the Xcode tools, as they are, don’t currently have a lot of support for watchOS. It would also be nice to have UI testing support that’s gotten better for iOS in recent days; hopefully that comes to the watch as well.
We’re disconcerted to see that the tvOS did get I testing support and has unit testing support I think because it’s closer to iOS than watchOS is but still nothing on watchOS.
JAIM:
TV gets all the cool stuff.
JEFF:
Tell me about it.
CHUCK:
I know, right? I want to be on TV. What are the gotchas that you run into when you start writing for watchOS that you just don’t see when you're writing iOS apps?
JEFF:
One of the things that really hit me was, the thing I mentioned before, with HealthKit where you can’t access some of the data from the watch. This just kind of a recurring theme where you’ll try to do something, realize you have to use the phone for some feature and then suddenly writing code to bridge data back and forth between the two.
The watch is pretty limited in the feature set in terms of backgrounding. If you don’t touch the display for about seven seconds, it turns off and there’s nothing you can do about that. You really don’t have a lot of time for processing. Anything you do need for longer processing – I might go to an example here – is mining a bitcoin. That should really happen on the phone, not the watch. It can be an exercise in figuring out how far can I get before I need to drop it to the phone? Luckily, there are pretty good APIs around talking to the phone and sharing data back and forth which I think is essential to writing the kinds of apps that we need to write.
CHUCK:
Nice. Are there any memory constraints or performance constraints that we haven’t talked about that you need to be aware of with the watch?
JEFF:
Yeah. It is a bit like going back to traditional few iPhones where memory’s pretty constrained, performance is pretty slow. With modern conveniences like Arc, it’s not quite as bad as the usual iPhone but you definitely still need to test on device.
If not enough to do the same later, the difference between the iPhone performance and the watch performance is kind of like the difference between the assimilator and the phone.
CHUCK:
Alright. I think we’ve exhausted all of our brain power on this so we’ll go ahead and go to the picks.
Jaim, do you want to start us of with picks?
JAIM:
Yeah, I’ve got a pick. I’ve got one pick today. I was looking for some podcasts that weren’t so technical, code-heavy podcast. The people that I play music with introduced me to The Song Exploder Podcast where they have musicians come on and deconstruct the songs, the different parts, how they're inspired. Pretty sure they're not super long but if you're into that type of thing, it’s cool. Some pretty famous artists – U2’s on there, Wilco and more recent stuff but if you're interested to see how songs and music comes together, it’s definitely worth to listen to. Check out The Song Exploder Podcast.
CHUCK:
Alright. Andrew, what are your picks?
ANDREW:
I’ve got three picks today. My first one is – I hope I say her name right but Erica Sadun’s blog. She’s a long time iOS developer that has been quite involved with Swift since it came out. With the release of Swift as open source, she just had a really good run of posts including these round-ups of what’s going on the Swift evolution mailing list where the community is discussing changes to Swift.
She’s actually the first person outside of Apple to have a proposal accepted for Swift which is cool. Her blog post is my first pick – her blog is my first pick.
My next pick, again regarding open source Swift. I’ve been working on a rewrite of one of my pen source libraries in Swift, from Objective-C to Swift. Part of the reason I’m doing that is so I can add support for Linux to it. If you're doing Swift on Linux, of course you don’t have Xcode, but there’s a guy that has figured out how to make a – basically make a plugin for Atom which is GitHub’s text editor to integrate the Swift package manager and the Swift debugger. This is cool because it gives you not a full ID but something a little closer to a Swift ID that’ll run on Linux and probably even Windows.
My last pick is an app that I’ve started using a couple of weeks ago called Authy and it’s a twofactor authentication app. One of the reasons I really liked it is they have a good watch app. So when you're signing into a website, you have two-factor authentication set up on which I have for a lot of places now. Instead of having to pull out your phone, you can just fire up the app on your watch and see the code that you have to enter in so it makes things a little smoother and it’s kind of cool and they’ve done a good job with it. Those are my picks.
CHUCK:
Now Authy is the Twilio thing, right? It’s built and run by Twilio?
ANDREW:
Yup, it’s from Twilio.
CHUCK:
Alright. I’ve got a couple of picks. Jai mentioned podcasts that he listen to that aren’t necessarily technical. There’s a podcast that I listen to last year that I was really hoping would come out with the season 2 and they did.
Serial is back. They're talking about the – what’s his name – Bowe Bergdahl. So they get his version of the story in the first episode which was really fascinating. I’m hoping just to see how deep they get into it but they got pretty deep on the last one with Adnan and that murder case. I’m really curious to see how this goes and what they dig up and how it all comes down, especially since now, he is actually facing a court martial for desertion and endangering fellow officers or fellow soldiers.
I’m also curious to see whether or not a podcast actually plays into an actual court case in this case. Anyway, definitely a pick for that. That’s about all I’ve got this week. Jeff, what are your picks?
JEFF:
I came prepared with three picks. The first is a game I’ve been playing especially on Apple TV called Badland. I have a three year old who’s become obsessed with this game. It’s basically a Flappy Bird meets World of Goo so if you liked either of those games, I would check that out.
The next is the aforementioned swift-evolution Mailing List. If you want to see how the sausage is being made and things like Erica’s first proposal, that’s where it’s all happening. It’s pretty high volume right now; I’m hoping it’ll all calm down. As the language gets older and people get over the initial rush of holy cows which is open source, it should be more manageable in terms of value. It’s been really cool to see.
Last is a local Detroit company called Rocket Fiber. Obviously, very few people who listen to this would be able to take advantage but they [inaudible] the world’s fastest internet with 100GB per second speeds. I’m coming to you now over a 1GB line on them. It’s just been amazing. It’s a cool thing to have the world’s fastest internet just across the street from us here.
ANDREW:
How much do they charge for their 100GB service?
JEFF:
The 100GB is one of those kinds of things where you have to call and ask. There’s no public praise for it but they're doing a 1GB residential for 70 a month. [Inaudible]
ANDREW:
Oh, 10GB. Wow.
JEFF:
Yeah.
ANDREW:
So 100GB, if you have to ask, you can’t afford it.
JEFF:
Well, if you wanted to open up a new data center, it’s that kind of thing.
CHUCK:
I thought you sounded a whole lot more bandwidth to [inaudible] the rest of us.
JEFF:
Well, that’s why.
CHUCK:
Yup. Alright, well if people want to find out more about you, how to get the book – all of that stuff, lay it on us.
JEFF:
Sure. I’m pretty active on Twitter. My Twitter name since 8th grade, my username has always been @slaunchaman. S-launch-a-man. You can also find me at jeffkelley.org – that’s Kelley. I have two very hard to spell things for you. You can get the book at pragprog.com. It’s one of the first things on the page there. Detroit Labs is just at detroitlabs.com.
CHUCK:
Super. Thanks for coming. It was a lot of fun to explore some of the capabilities and approaches to writing watch apps.
JEFF:
Yeah. Thanks for having me on.
ANDREW:
Thanks Jeff.
[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit cachefly.com to learn more.]