watchOS – Rob Kerr

Developing Robot Runner.app for the Apple Watch

The news on Apple Watch ordering day when I rose at 6:30 US/Eastern was that the first production run had sold out — which I expected. Unexpected was that I found one (and only one!) style available for first wave delivery. The watch arrived April 24 (Friday) via UPS as promised.

Time to Code!

On Friday I enjoyed using the Apple Watch, and realized that this really is a product the world needs. But by Saturday the only thing on my mind was what to code for the Watch!

What’s Robot Runner?

Robot Runner is one of my internal test apps. I use it for working with Bluetooth techniques. It’s a fun app since it has sensors, animation and involves some hardware hacking with an Arduino module and breadboard.

Robot Runner is an iPhone app written with Swift in XCode that connects to an embedded controller (the Arduino board) using Bluetooth Low Energy (a BLE shield attached to the Arduino). The architecture of the app is in the diagram below.

The iPhone app starts and stops the robot, and reads temperature and ambient light intensity sensors on the robot. It’s a good hacking solution since it incorporates many different elements used in mobile connected device applications.

Robot Runner Apple Watch Design Objective

For the Watch project, the objective is to add a to the existing app the ability for the user to connect to the Robot using the Watch instead of the iPhone. This is a typical use case for the Apple Watch — giving the user the ability to use the core functions of the app from the watch. The final architecture will be as follows:

Currently, all 3rd-party apple Watch apps are built as extensions to iPhone apps. In the diagram above, it’s not (yet) possible to eliminate the iPhone entirely, but it is possible to leave the phone in standby (in a pocket or purse, or in the next room) and let the watch wearer still use the app functions.

The Watch app remains connected to the iPhone through a Bluetooth “umbilical cord”. In MVC terms, the Models and Controller are still resident in the phone, and only the View is resident on the watch. Maybe that will change in the future, but for now, it makes sense. Leaving the Controller on the iPhone certainly will conserve the watch’s battery and CPU.

Software Architecture

A significant part of Robot Runner is the code to scan for the Bluetooth devices, connect to them, and once connected send commands and read sensor values. In the current iPhone app (Robot Runner.app, in purple within the below diagram), all of the code used by the iPhone app is contained within the single iPhone app target.

The Watch app (Robot Runner WatchKit.app, in blue), won’t connect directly to the Arduino module’s Bluetooth interface, but will do so via the Robot Runner WatchKit Extension.app (green), which runs on the iPhone. So far so good. But there’s a wrinkle that requires some re-architecting.

Once the Apple Watch is added to the solution, the two Bluetooth modules (BTDiscoverySvc.swift and BTPeripheralSvc.swift) will need to be used by Robot Runner.app and Robot Runner Watchkit Extension.app. However, although these apps are installed together, they run in different sandboxes. So, we either need to compile and link the two Bluetooth swift modules into both targets, or break them out into a common framework. The framework is easier to maintain and reduces the runtime footprint, so I chose that path. This framework is called RobotRunner.framework.

This sandbox separation also restricts sharing of data between the Apple Watch and iPhone controllers. Specifically, the project needs to have a single app group with entitlements granted to both the iPhone app and Watch Extension targets. Using the app group, the iPhone app and watch extension can share data using flat files, Core Data/SQLite and/or NSUserDefaults. Robot Runner does’t need a shared data capability (yet), so this wasn’t a factor in this project.

Putting the pieces together

With the refactoring of common code into the framework, the rest of the development is straightforward. The logic to connect to and communicate with the Robot’s Bluetooth controller was expressed in the Robot Runner WatchKit Extension.app, and the UI was designed in the Robot Runner WatchKit.app.

I’m happy to report that no significant challenges were encountered. There are differences between UIKit used for the iPhone UI and WatchKit used for the Watch UI, and the controller lifecycle states are named differently (and there are fewer of them). So, certainly, there’s a learning curve for existing iOS developers.

I expected challenges with the Core Bluetooth modules and delegates (either because of the WatchKit controller or the re-factoring into the Framework), but I was pleasantly surprised not to encounter any unusual challenges. A little bit of change related to the framework refactoring, but overall all of the Core Bluetooth code worked as-is.

The Final Results

Here’s a side-by-side (or over/under if you’re on a phone device) comparison of the UI for the iPhone and Apple Watch versions of Robot Runner. Note that in moving from the 4.7″ iPhone screen to the 38mm-42mm watch screen there has been no loss of functionality.

All of the same information is displayed. The command button and sensor outputs are still on the same screen together. Even the animated Robot renders exactly the same using the same frame images (he runs when the robot is in a run state, and is stopped when the robot is in a stopped state).

Conclusions

Apple has done a great job of keeping the basic developer workflow relatively consistent with WatchKit. Learning WatchKit isn’t much more challenging than learning any unfamiliar framework. No doubt this relatively modest learning curve has something to do with the App Store having so many apps ready-to-go on the day the Watch first shipped (reports indicated there are already thousands!).

Originally published at rekerrsive.ghost.io on April 27, 2015.

Why do iPhone Apps need Apple Watch extensions?

How often do you look at your iPhone? As reported by The Daily Mail in 2004, Marketing agency Tecmark found the average user reaches for their smartphone an eye-popping 1,500 times per week! Other studies have reported similar statistics — the Kleiner Perkins Caufield and Byers 2013 Internet Trends Report found a similar statistic — smartphone users may use their phones 150 times per day!

What does this have to do with the Apple Watch? Or any other connected smart watch for that matter?

Simply this: much of this repeated device usage is “glancing”. How often do you grab your smartphone only to glance at it? Maybe to check the time. Maybe to check if the push notification you noticed is important enough to read immediately.

I don’t “stare” at my iPhone 150 times/day. You probably don’t either. But do I “glance” at it 150 times a day? Probably. You might too (even if you don’t realize it).

The point?

Many who fail to see value in the smartwatch concept rightly conclude that a wristwatch is a poor replacement for a 4–5 inch smart phone screen. No doubt this is true.

But the question isn’t whether smartphone users will replace their phone with a smart watch (they won’t!). The question is whether smartphone owners will wear a smart watch to enable them to glance at bits of information without the need to fish out their smartphone 150 times per day.

I bet many of them will. And when they do, will your app be part of this new way of using mobile devices? Or will your users switch to an alternative that works with their watch?

Originally published at rekerrsive.ghost.io on April 26, 2015.

3 Days with the Apple Watch

I received an Apple Watch on Friday (38mm Stainless w/Black Leather band, in case you’re curious). I was just taking stock of how the product is working out for me, and thought I’d share some initial impressions.

First, let me say I don’t consider myself an “Apple fanboy”. I have a Dell XPS15 with Windows 8 that I love to use…and while I gave up on Windows Phone, it took years to finally make that decision — one I took no joy in.

Like many, I had read a lot of press reviews of the Apple Watch when they came out a few weeks ago. But I actually found much of the press coverage a poor guidepost for what has been my initial experience with the actual product.

Here are some observations

It really is easy to use. Unlike a certain prominent reviewer, I didn’t find it difficult to use at all. It took three hours — not three days — to get the hang of using the watch. It has some new gestures I’ll need to get used to, but otherwise it seems pretty intuitive. I probably haven’t found all the product features yet, but that doesn’t matter. I don’t need to explore every dusty corner of the product to make a publishing deadline.

It looks a lot nicer in 3D on your wrist than it does in 2D on the web. Those close-up photos make the watch look really thick. And, well, it is thick compared to my old Seiko. But when perched on my wrist, it’s thickness isn’t something I notice. It feels small and elegant more than thick and nerdy. This is subjective, and YMMV.
Lefties Rejoice! I’m left-handed, and have never had a watch with the crown on the “correct” side (for me). It took about 60 seconds to switch the band around, and the watch asked me which arm I would wear it on (right, for me). Why aren’t more products built for use with either hand?

The battery life is fine. I put the watch on at 7AM, and it’s 5:08PM as I write this…I have 76% battery remaining. That’s not the “terrible battery life” I’ve read about (compared to a smartphone, anyway). Like a smartphone, I assume the battery rundown time will depend on how the device is used, and vary from day to day. I assume that the longer the display is on, the more notifications, the more web browsing and phone calling, the faster the battery will drain. Like free beer, I won’t ever turn down more battery life. But lasting all of my waking hours is acceptable. It’s the little things that really matter. I’m so far loving the little things that make my life just a little better.

While getting my teeth cleaned at the dentist this morning I dismissed an incoming phone call without needing to fish out my phone — that was awesome.

Great that I could see that the e-mail that came in while typing this text was from a VIP contact that I need to look at, but based on the subject it can wait until I’m done typing this article.
So nice to use the watch to switch between Pandora playlists from the kitchen counter while I was making a sandwich on Sunday afternoon (yes I could also use my phone to do that, but it wasn’t on me at the time).

Not everything is perfect. While the watch presents voicemail for playback, I still haven’t been able to make it play. And not every phone call has been displayed on the phone for dismissal or answer — not sure why. But it’s early days, and hopefully I’ll figure it out (or go to the genius bar and have them explain it to me).

A wrist-worn device that displays not only the time, but also my upcoming calendar, the weather, fitness levels, incoming phone calls, let’s me glance at what that last e-mail chime was for, etc., is pretty cool. It won’t be worth buying for everyone, but aside from healthcare, food and shelter, no product needs to be.

While this is a “version 1 product”, my overall experience so far makes me think this is the right evolutionary path for personal technology. As with the smartphone itself, Apple wasn’t the first to think of doing this, nor was it first to market. But the company has, in my view, designed the right experience and executed a product with the right mix of compromises. Apple’s leadership in the category will no doubt float other boats higher, and help the mobile industry move to the next level.

Originally published at rekerrsive.ghost.io on April 25, 2015.