Brian Gilham

Engineering leader, husband, and father

apple-watch

Crossing the Finish Line

Before I dive into this week’s article, I want to extend a warm welcome to everyone joining us for the first time. After Be Kind reached the top of Hacker News, the Monday Mailer grew by more than 600 subscribers – in less than 48 hours. I’m glad you’re here! Have you ever found yourself close to finishing a side project, only to become stymied by one last task you need to complete?

Before I dive into this week’s article, I want to extend a warm welcome to everyone joining us for the first time. After Be Kind reached the top of Hacker News, the Monday Mailer grew by more than 600 subscribers – in less than 48 hours. I’m glad you’re here!


Have you ever found yourself close to finishing a side project, only to become stymied by one last task you need to complete? You have to figure out how to integrate Stripe payments. Or you’re futzing around with the landing page design. You know you should just ship the damn thing but, for whatever reason, you can’t.

It feels like running the New York Marathon. Except when you near the finish line, there’s a brick wall in your way. At that point many of us give up and walk away, promising to do better next time. But the cycle continues. We start the next project full of energy. Then, as we near the finish line, we stall. Again.

I’m as guilty of it as anyone. Here’s a gem Facebook surfaced recently. 

Facebook Screenshot

I never did ship that project, by the way. If I had a nickel for every side project I’ve abandoned, I’d be living large right now.

Why do we allow ourselves to get so far, only to succumb to procrastination? 

Often, deep down, it’s because we’re afraid. Afraid of failure. Afraid of what our family and friends will think. Afraid that, if everything isn’t just perfect, we’ll have wasted our time. Afraid that we’ve built something nobody wants. It’s safer to keep fiddling around – secure in the knowledge that, as long as the project sits on our hard drive, we don’t have to risk anything. 

It’s self-sabotage. And, for those of us trying to do our best work, build an audience, and make an impact, it’s a habit we have to break.

A lot of times people fall into this pattern because they put the concept of “Launch Day” on a pedestal. They think they get one shot to reach a huge number of people and impress them. They’re not only wrong – they’re limiting their audience

When I started working on Chronicons, my icon set for Apple Watch apps, I took the opposite approach. Instead of hiding it away from prying eyes, I shared what I was doing as often as possible. I wrote about it on my blog, posted updates on Twitter, and solicited feedback on Dribbble. I got valuable comments and advice from designers around the world and built up an audience of people who couldn’t wait to buy from me. And they stuck around once the launch had come and gone! It’s a process I’ve repeated a few times since, with similar results. 

I won’t lie – it’s hard to do, the first few times. But it gets easier with practice.

You side project could be a huge hit. Or, it could be a disappointing flop. But until you can set aside your fears and share it with the world, you’ll never find out. 

You – and your work – deserve better.

Until next time,

–Brian


The End of WatchKit Resources

I’ll keep this short. I will no longer be publishing WatchKit Resources, my collection of curated Apple Watch design and development links. The community simply isn’t active enough to warrant a weekly publication. I hope that changes, eventually. Over the course of just over a year, I published 225 blog posts, released 16 newsletter issues, and had the opportunity to check out some of the amazing work being done by developers like Natasha Murashev, David Smith, and Kristina Thai.

I’ll keep this short.

I will no longer be publishing WatchKit Resources, my collection of curated Apple Watch design and development links. The community simply isn’t active enough to warrant a weekly publication. I hope that changes, eventually.

Over the course of just over a year, I published 225 blog posts, released 16 newsletter issues, and had the opportunity to check out some of the amazing work being done by developers like Natasha Murashev, David Smith, and Kristina Thai. To anyone who took the time to follow along: thank you.

I truly appreciate it.


How to debug an iOS app while the associated WatchKit app is running

(Originally published at FiveMinuteWatchKit.com, before the release of watchOS 2) Since the introduction of openParentApplication:reply: I’ve seen developers struggle to debug their iOS app while running a WatchKit app in the simulator. If you haven’t worked with extensions before, the solution may not be obvious. Here’s how to pull it off: Build & run your iOS app in the simulator. Wait for it to finish launching, then hit the stop button in Xcode.

(Originally published at FiveMinuteWatchKit.com, before the release of watchOS 2)

Since the introduction of openParentApplication:reply: I’ve seen developers struggle to debug their iOS app while running a WatchKit app in the simulator. If you haven’t worked with extensions before, the solution may not be obvious. Here’s how to pull it off:

  1. Build & run your iOS app in the simulator.
  2. Wait for it to finish launching, then hit the stop button in Xcode.
  3. Switch your active target to your WatchKit app, build, and run it.
  4. When the Watch app has finished launching, tap your iOS app’s icon in the main simulator window.
  5. In Xcode’s menu bar select Debug > Attach to Process.
  6. Select your iOS app from the list. Chances are you’ll find it under Likely Targets.

If you take a look in the Debug Navigator (⌘ + 6), you’ll notice the debugger is now attached to both your iOS app and the WatchKit extension. You can click on each target in the navigator window to select which console output you’d like to view. If Xcode encounters a breakpoint it will automatically switch to the correct target.

Keep in mind that you’ll have to repeat this process each time you re-run your WatchKit app.


One weird trick to “fix” openParentApplication:reply:

(Originally published at FiveMinuteWatchKit.com, before the release of watchOS 2) A quick perusal of the Apple Developer Forums shows more than a few developers have experienced strange bugs when calling openParentApplication:reply: in a WKInterfaceController. Most often, it seems, when making multiple requests in quick succession. In an app I worked on recently we were hitting all sorts of strange behaviour. Sometimes openParentApplication:reply: would mysteriously be called twice. Every once in a while the reply block would fail to ever be called — despite being certain the delegate was functioning correctly and completing work in a background task.

(Originally published at FiveMinuteWatchKit.com, before the release of watchOS 2)

A quick perusal of the Apple Developer Forums shows more than a few developers have experienced strange bugs when calling openParentApplication:reply: in a WKInterfaceController. Most often, it seems, when making multiple requests in quick succession.

In an app I worked on recently we were hitting all sorts of strange behaviour. Sometimes openParentApplication:reply: would mysteriously be called twice. Every once in a while the reply block would fail to ever be called — despite being certain the delegate was functioning correctly and completing work in a background task.

Frustrating, to say the least.

However, I’ve discovered a solution that has made communication with the iPhone rock-solid. Essentially you have to begin — and end, after two seconds — an empty background task right at the beginning of the delegate method. It should be the absolute first thing you do. Afterward, kick off a background task for the real work.

Here’s an example:

The theory is the bogus background task prevents the OS from killing your app immediately. I honestly couldn’t tell you for sure.

All I know is it’s made openParentApplication:reply: far more reliable.


How to round the corners of a WKInterfaceImage

(Originally published at FiveMinuteWatchKit.com, before the release of watchOS 2) The Human Interface Guidelines recommend using black as the background colour across your entire app. Why? It allows the background to blend in with the bezel surrounding the display, giving the illusion there isn’t a bezel at all. In my experience, rounding the corners of your full-width images can help this illusion. A quick look at the WKInterfaceImage class reference, however, might make you think this isn’t possible.

(Originally published at FiveMinuteWatchKit.com, before the release of watchOS 2)

The Human Interface Guidelines recommend using black as the background colour across your entire app. Why? It allows the background to blend in with the bezel surrounding the display, giving the illusion there isn’t a bezel at all.

In my experience, rounding the corners of your full-width images can help this illusion. A quick look at the WKInterfaceImage class reference, however, might make you think this isn’t possible. Where’s the setCornerRadius: property?

It isn’t possible. Not directly, anyway.

Poking around, you’ll notice that WKInterfaceGroup does have a setCornerRadius: method. Place your WKInterfaceImage inside a group, set the corner radius, and you’ll notice it clips the corners of your image beautifully.


How to Display an Image Using WKInterfaceImage

(Originally published at FiveMinuteWatchKit.com, before the release of watchOS 2) If you take a look at the class documentation for WKInterfaceImage, you’ll notice there are three different methods for displaying an image. For many developers new to WatchKit this has proven to be a bit confusing. When should you use one over the other? Where are the images coming from? Here’s a quick guide. setImage: This method sends a UIImage — or multiple, if you’re creating an animation — from your WatchKit extension to your WatchKit app.

(Originally published at FiveMinuteWatchKit.com, before the release of watchOS 2)

If you take a look at the class documentation for WKInterfaceImage, you’ll notice there are three different methods for displaying an image. For many developers new to WatchKit this has proven to be a bit confusing. When should you use one over the other? Where are the images coming from? Here’s a quick guide.

setImage:

This method sends a UIImage — or multiple, if you’re creating an animation — from your WatchKit extension to your WatchKit app.

setImageData:

This method sends an NSData object containing one or more images from your WatchKit extension to your WatchKit app. This saves the overhead of creating a UIImage if you are trying to set an image with data loaded directly from a file or downloaded from the Internet.

If you have to send an image from the phone to the Watch, this is the most efficient way to do so.

setImageNamed:

This method displays an image that has already been stored in the WatchKit app’s bundle, or cached on the device. If you are trying to displaying an image from the bundle, be sure to specify the full name and the file extension.

Caching

If you are displaying an image using setImage: or setImageData: that you’ll show more than once, cache it using the addCachedImage:name: method on WKInterfaceDevice. Afterward, you can use the specified cache name when calling setImageNamed:.

Make sure to clear images out of the cache as needed — you get 20mb of storage and it isn’t pruned automatically. To remove an image from the cache, you can use the WKInterfaceDevice method removeCachedImageWithName:. To clear all cached images use removeAllCachedImages.

Storyboards

One thing to keep in mind: while Interface Builder will allow you to specify an image from anywhere in your project, it will only be displayed if it is included in your Watch app bundle.


Things to think about when planning an Apple Watch app

The first question to ask yourself is, “Just what the heck is this thing going to do?” For the average user, the Apple Watch will be joining an entire constellation of devices they already use in the course of a day. If they use their laptop for general computing, perhaps they use their iPad for reading books or blog posts on the couch. Or watching Netflix. They pull out their phone on the go to play games or catch up on Twitter.

The first question to ask yourself is, “Just what the heck is this thing going to do?”

For the average user, the Apple Watch will be joining an entire constellation of devices they already use in the course of a day. If they use their laptop for general computing, perhaps they use their iPad for reading books or blog posts on the couch. Or watching Netflix. They pull out their phone on the go to play games or catch up on Twitter. We’ve all seen someone browsing Instagram on the bus.

Despite how connected to our smartphones we’ve all become, the Watch will be even more intimate. It’s literally strapped to your body. You need to respect that.

Should your app exist?

Assuming you have some say in the matter, take a moment to ask yourself if creating a WatchKit app for your product is really beneficial for your users. I love Dropbox, but struggle to think of any reason I’d want it on my wrist. Perhaps they’ll surprise me.

What would your app bring to the table? In my mind, useful Watch apps do one of three things:

1. Make it easier to do my job or live my life.
2. Improve the connections I have with people I care about.
3. Bring a small moment of joy into my life.

If the app concept in your mind doesn’t fit into one of those three categories — or more than one — I would think long and hard about whether it should exist at all.

When in doubt, why not ask your users? By speaking to my app’s potential users, I’ve avoided making false assumptions about how they’ll use it.

If I try your Watch app and you piss me off, I won’t be back.

Precious Seconds

If we measure iPhone app usage in minutes, Watch apps will be measured in seconds. In my testing, users want their smartwatch to integrate into their life/workflow, not become the focus of it.

Watch apps should get the user in and out as fast as possible. Convenience is your guiding principle.

I had the opportunity to test a Pebble smartwatch for two months and I loved how little I had to pull out my phone to deal with my digital life. New message from a contact? I glanced at my wrist, decided whether or not it needed to be dealt with in the moment, and got on with my day.

That’s powerful.

When you’re planning your app’s functionality, design, and UI don’t disrespect my time by asking me to do any more than that.

Duplication of effort

A Watch app complements your existing iOS app, it doesn’t replace it. Don’t try to re-create all of the existing functionality. What are the top three features your app needs and your users would appreciate? Better yet, what’s the one killer feature?

  • I want to start/stop recording my bike ride in Strava, I don’t want to read through a long list of every ride I’ve ever taken.
  • I want to see the latest deals at the store and find the closest location. I don’t want to browse every product you carry.
  • I want to see the top 5 reviews of the restaurant I’m standing in front of, not read every damn review ever written.
  • I want to read the top news stories of the day that are most relevant to me, not flip through every story in the paper.

Your Watch app is bundled with a fully-featured iOS app. Don’t duplicate your effort. If you simply “minify” your existing app, you blew it.

Working on an awesome app for the Apple Watch? I’ve released a set of 113 HIG-compliant icons called Chronicons. Designed specifically for the Apple Watch, they’re $5 off until Wednesday.


Chronicons Site Header

Just a small portion of the new design for http://chronicons.com. The site does a much better job of explaining what the icon set is, who it’s for, and why it’s beneficial. I’m psyched.


How to Design an Icon Set for the Apple Watch

As I prepare to wrap up work on the first edition of Chronicons, my menu icon set designed for the Apple Watch, I wanted to share a few of the steps I took to (hopefully) ensure its success. Designing for a brand-new device — particularly one that hasn’t been released — can be tricky. It’s important to find ways to anticipate design considerations ahead of time, rather than just waiting for launch.

As I prepare to wrap up work on the first edition of Chronicons, my menu icon set designed for the Apple Watch, I wanted to share a few of the steps I took to (hopefully) ensure its success.

Designing for a brand-new device — particularly one that hasn’t been released — can be tricky. It’s important to find ways to anticipate design considerations ahead of time, rather than just waiting for launch. Here’s the approach I took:

1. Read the documentation

Often the docs are all you’ll have to go on at first. For Apple products, the Human Interface Guidelines are your bible. Following the guidelines in the HIG won’t stop you from designing garbage, but it’s better than going in blind.

I went one step further and used iOS Artwork Extractor to grab the menu assets included in the beta OS. By studying how Apple’s designers had created their icons, I was better able to understand the guidelines set out in the HIG.

2. Follow what other people are doing

Every morning I sit down with a coffee — or a Red Bull — and open a new tab to the Apple Developer Forums. Ditto for Stack Overflow questions tagged “WatchKit”. Oh, and a Twitter search for the same.

Part of the reason I do this is to find great links for WatchKit Resources. But it also allows me to stay abreast of the problems other designers are facing — and the solutions to those problems. When it’s the Developer Forums, those solutions often come Apple devs, designers, and evangelists. Invaluable. Where I can, I try to offer solutions of my own — either by responding directly, or writing blog posts.

3. Fake it

Designing for a device that hasn’t been released yet is really hard. Sure, you can read the HIG and look at pretty mockups on Dribbble. But it doesn’t help you understand the context your work will be used in. It didn’t for me, at least.

The size of the Apple Watch simulator window can be deceiving. If you want to get a better sense of just how damn small the Apple Watch is, I suggest using Bezel to bring it back down to size.

But that wasn’t enough for me. Forget launch dates, I wanted to hold an Apple Watch now. Enter 3D printing. I created a model of the 42mm Watch and, at one point, strapped it to my wrist with duct tape. If you have access to a 3D printer, I highly recommend it.

Oh, and I wore a bunch of competing smartwatches. Every single one I could find. Pebble, Moto, you name it. Fitness devices like the FitBit and the FuelBand, too. I wanted to understand their individual strengths and weaknesses, along with the benefits of wearables in general.

4. Talk to your future customers

Coming up with icon concepts was easy, at first. I knew the kind of apps I wanted to build for the Watch, so I created icons to fit those ideas. After a few weeks, however, I realized I needed to ask other developers what they were working on.

I chatted with my fellow Apple Watch devs every chance I got. Heck, I still do. I asked them what they were working on, where they saw the Watch going in the future, and what sort of design assets they needed for their projects. Basically, I listened to their needs and then said, THAT’S AWESOME PERHAPS I CAN HELP.

There are plenty of icons that wouldn’t have made it into Chronicons Edition #1 if it weren’t for those conversations. And I already have a great list for Edition #2.

5. Assume you’ll be wrong

This is all well and good, but we still don’t have the damn Watch in our hands. And, despite all the efforts to lessen the risk, that’s still a risk. Particularly when you are asking customers to give you cold, hard cash for your design work. I know there’s a good chance some of these icons will need tweaking once the Apple Watch has been released to the public. If something ends up looking like crap, I don’t want people to feel ripped off. But I also want them to be able to make use of Chronicons now.

To that end, I am committing to free updates for all customers. Dead stop. It just seems like the right thing to do. If you are getting ready to launch your own pre-launch products for the Apple Watch, I would suggest thinking about doing the same.

Working on an awesome app for the Apple Watch? Chronicons Edition #1 will be available March 4th, 2015. Want to hear more from me? Sign up for the mailing list to be first to know about new icons sets and deals.


Chronicons Edition #1

For my first shot on Dribbble I’m excited to debut an icon set I’ve been working on for the last few months called Chronicons. They’re designed and tested specifically for the Apple Watch.

I’ll be releasing the full set on March 4th, but I wanted to share a tidbit here first. They’re fully compliant with the HIG and I hope they’ll be as helpful for others as they have been for me.

I’d appreciate any feedback you all may have and I look forward to participating a bunch more on Dribbble as time goes on.

UPDATE: Chronicons Edition #1 is now available! Check it out at http://chronicons.com. $5 off for a limited time.