Nineteen Step Process to Faster Apple Watch Button Actions

The upcoming release of Grocery focuses on speed. We can all agree that the main thing your app does should be fast, and for Grocery that's checking items off your list. As we added features to the apps the performance of checking items off a list slowed down - a lot. For some users, checking off items could take 3-4 seconds on iPhone, and 5+ seconds on Apple Watch. We needed to address that now before adding more features.

The problem on iPhone was simple to understand and solve using Instruments. When you mark an item off your list on the iPhone, we were waiting for the update to Reminders to finish before moving the table cell. Making that update asynchronous and moving the cell immediately solved the problem. When you mark an item off your list now, the list update happens instantly, just like it should be!

The problem on Apple Watch was harder to understand and harder to solve, and that's the focus of this blog post. Troubleshooting performance on Apple Watch can be tricky. You can try to identify red flags if they exist by running Instruments against the simulator, but the only way to truly evaluate performance on Apple Watch is with the physical device itself. Everything that seems slow on device will feel completely normal on the simulator. You have to test on hardware to solve the problem.

Grocery's Apple Watch app is very simple - just one table view where tapping on a cell checks the item off your list. That's why this particular issue was so perplexing: the app isn't doing anything that seems too complicated. When an item button is pressed, the app sends a message to the iPhone to tell it which item was checked off, and then removes the cell from the table view. The app isn't updating the Reminders database itself, so why is it so slow? Time to investigate!

This blog post describes my nineteen step process to faster buttons on Apple Watch, which is composed of the following individual steps that can be used repeatedly starting with the first one:

  • Disable Everything and Re-evaluate Performance
  • Refactor/Extract Functionality As You Go Into Their Own Methods
  • Start Adding Trivial/Simple Functionality Back
  • Turns Out Some "Trivial" Functionality Actually Hurts Performance
  • Identify Major Problem Areas and Either Improve or Remove Them
  • Put it All Together and Test The Final Version on Device

Step 1 - Disable Everything and Re-evaluate Performance

When tapping on a button feels slow on the Apple Watch the best thing to do is remove everything from the IBAction method and test it again. Button taps should feel as close to instant as possible on the watch. That's a major focus for watchOS 4 with the Unified Process Runtime - making touch interaction feel even faster and more reliable. If you remove everything from your action method and performance returns to normal, then you know something in that method is causing the slow down.

Commenting out the implementation also made me realize just how much functionality had been added to that button press action over time. What started out as a very simple method now included a laundry list of functionality:

  • Update the Apple Watch's Sorting Database
  • Updating the Table Data Model
  • Removing the Table Cell
  • Sending a WatchConnectivity Message to the iPhone
  • Playing a Haptic Feedback
  • Updating the Remaining Items Count
  • Hiding a Placeholder Group
  • Updating the Complication

Sure enough, after commenting all of that out things felt fast again. This approach is also very motivating because you get to see how fast it can feel which makes you want to achieve that performance with the rest of the functionality restored.

Step 2: Refactor/Extract Functionality As You Go Into Their Own Methods

While you're working on the button action method I think it's a great idea to refactor and re-organize the functionality of that method into smaller methods with a single responsibility. As I had been adding features and functionality to that button action I had just been adding them to the same method. I took this opportunity to move each area of functionality into its own method. This has the dual benefit of cleaning up the code as well as making it easier to see what you're turning on and off while evaluating button performance.

Step 3-7: Start Adding Trivial/Simple Functionality Back

I started adding functionality back one piece at a time, beginning with the most trivial pieces that I assumed wouldn't have any impact on performance. I installed a new device build after each piece to test performance on a physical watch. 

Most of the trivial features didn't affect performance at all. Haptics and hiding the placeholder group had no impact. Drawing a strike-through line through the item label with an attributed string didn't seem to hurt. Removing the table cell and removing the item from the array didn't hurt either.

Updating the remaining item count was the first place that I noticed a small change in performance. That involved counting the number of remaining items and updating the Interface Controller's title property. The change was barely noticeable though, so I decided to keep that feature in.

Step 8-10: Turns Out Some "Trivial" Functionality Actually Hurts Performance

The next seemingly trivial feature I added back to my button action was updating the complication. Updating the complication isn't slow on its own, but the way I was updating the complication was triggering a reload from the Reminders database. When I added this method back to my button action performance slowed down considerably. Once that happened it gave me an area to investigate further, which lead to identifying the database reload. By addressing that issue I was able to reload the complication after marking an item off the list without hurting button performance!

Step 11-18: Identify Major Problem Areas and Either Improve or Remove Them

The two major problem areas turned out to be updating the sorting order on the watch, and sending the message to the iPhone to tell it which item was marked off the list.

Updating the sorting order was actually completely unnecessary. In an earlier version of the Apple Watch app we had been moving marked off items down to the bottom of the list instead of removing them. Removing them from the list made more sense because of the small size of the Apple Watch screen. When we changed that behavior we didn't remove the sorting change - which was actually a pretty significant performance penalty. Removing that made a huge difference!

Sending the message to the iPhone using Watch Connectivity made more of an impact than I expected it would. Making that method call asynchronous by calling it on a background queue made our button action feel a lot faster, so that was the only change we needed to make there.

Step 19: Put it All Together and Test The Final Version on Device

Once all of the button action features are refactored, removed, disabled, moved, or improved then it's time to put it all back together and test the final product out to make sure that all the effort actually made a difference in performance. After a few days of testing it's definitely feeling like a big difference.

 

Conclusion

Troubleshooting performance on Apple Watch can be tricky but the effort is well worth it, especially for a device intended for small and quick interactions. It's truly a device where every second counts, and a little bit of testing can help make the difference between an app that feels fast and an app that feels too slow to use. Even with the upcoming improvements to app performance with watchOS 4, anything that we can do to help our apps feel faster will make a big difference for Apple Watch users.

Grocery Version 1.1 Includes Quick Add and Usability Improvements

The reception Grocery has received from users since launching has been great. Several of the reviews really capture why we wanted to make the app:

Couldn't have said it better ourselves, and in that spirit we've been working on some meaningful improvements to the app while staying true to the simple design and focused purpose.

Grocery 1.1 featuring an improved list layout and Quick Add

Grocery 1.1 featuring an improved list layout and Quick Add

The main grocery list interface has received lots of attention. When we released Grocery the title and notes fields were aligned horizontally, which limited the maximum length of titles that could fit on most phones. Stacking the fields vertically removes that limitation and improves readability. It also frees up space on the right side for persistent drag handles to quickly re-order items manually. Grocery learns the order that you shop for items pretty quickly, but it's still helpful to be able to move an item into place if you already know where it should go.

We're also introducing a new feature that we call Quick Add. This feature uses your shopping history to help you remember items you shop for frequently and quickly add them to your list. Quick Add makes suggestions based on how often you shop for repeated items. If you buy Eggs every 6 days, and it's been 5 days since your last trip to the store, then you would expect to see Eggs on your Grocery list. Quick Add learns to recognize those patterns and make adding those items to your list faster.

Grocery 1.1 includes many other general usability improvements:

  • Use custom URL Schemes to open Grocery and add items
  • Improvements to Apple Watch Complication and Snapshot reliability
  • Support for Handoff from Apple Watch to iPhone
  • Alexa can add items to your Grocery list. Check the FAQ for setup instructions.
  • We made a handy text-selection-menu shortcut to "Clean Up" a title by moving extra text besides the title into the notes field.
  • A much requested "Share this app" button to simplify sharing the app with friends and family :)
  • Emoji now correctly appear in the title and notes fields
  • Keyboard shortcuts for iPad
  • Performance improvements for manual re-ordering
  • The number of items in your list are visible at the top of the list
  • Grocery automatically scrolls to reveal the position of new items after they're added to your list.

If you haven't gone for a trip to the store with Grocery yet, give it a try. We think it could be exactly what you need too, but if it's not please reach out and let us know!

Review: Baratza Sette 270W Coffee Grinder

I'm a home brew espresso enthusiast. My morning ritual starts with brewing an espresso and making a cappuccino. I love  the attention to detail involved with great coffee. That doesn't mean that I'm a coffee snob - but I do understand what it takes to balance all the variables to make a good cup :) Perfecting that balance at home has lead me to the Baratza Sette 270W [Amazon] as an upgrade to my home espresso grinder.

I started my home brew espresso setup with a few main components. The Rancilio Silvia [Amazon], regarded as one of the best machines for home use. And the Rancilio Rocky, one of the original espresso-caliber grinders designed for enthusiasts. I added a few other items later, like the incredible Acaia Lunar scale [Amazon] and the essential VST basket, both of which aid in consistency and are just fun to use. I've been doing this for a little over a year, and I've been very happy with the results.

Several people told me before I started that I should plan to spend almost as much money on the grinder as I spent on an espresso machine. I didn't understand that at first. What's the point of an expensive grinder? I already had two basic grinders, and they both...well, ground coffee beans. Wasn't that good enough?

I rationalized buying a new grinder by thinking that grinding coffee fine enough for espresso was harder to do than grinding coarser for the aeropress. That must mean the grinder is more expensive to produce. But it wasn't until I spent a year brewing espresso at home that I really understood how important the grinder is, and how it can improve quality even more than the machine itself.

The Baratza Sette 270W grinding into a bottomless portafilter. The coffee grounds shoot out of the grinder almost like a jet engine, at a remarkable level of consistency.

The Baratza Sette 270W grinding into a bottomless portafilter. The coffee grounds shoot out of the grinder almost like a jet engine, at a remarkable level of consistency.

I first heard of the Sette 270W from a barista I follow on Twitter. I looked at the product and saw that it included Acaia weighing technology - the same technology in the Lunar scale I already use every day while brewing espresso. That immediately caught my interest. The Acaia Lunar scale is the most fun piece of coffee equipment I own. If you're interested in the nerdy details of brewing espresso, it's just a fun and delightfully accurate/fast device to brew with to measure both weight and extraction time of brewed espresso.

The Sette 270W's promise is to use a built in scale to weigh the coffee grounds in real time, delivering exactly the amount of ground coffee into the portafilter. For espresso, that probably means somewhere in the 16-20g range, depending on the type of coffee you're using. The machine includes an adjustable holder for the portafilter, and works with both spouted and bottomless portafilters. Adjusting the holder is easy, with an included small allen wrench. Once set, I haven't had to adjust mine, and it holds the portafilter very comfortably.

Weighing the ground coffee while the grinder is active saves a lot of time. Previously if you wanted to measure the weight of the coffee ground into the portafilter, you would need to tare out a scale with your portafilter, grind roughly the amount of coffee you think you need into the portafilter, and set it back on the scale. If you're over the target weight, you can use a small spoon to remove extra grounds. If you're under, it's back to step one to add a little more coffee, and weigh the portafilter again. This isn't difficult to do, especially if you're only making one or two cups, but does take time.

The Sette 270W works exactly as advertised. You select from three programmed weight settings or enter one manually, set the portafilter in the holder, and press the play button. The grinder starts up and very quickly the scale is displaying the precise weight of the coffee ground into the portafilter basket. There are no extra steps. It's a very automatic process to end up with a precise amount of coffee in the portafilter basket, ready to tamp and brew espresso.

I've been very impressed with the grinder's accuracy. I've seen very consistent results at a variety of preset weight settings. I usually target 17g, and my grinder hits this number exactly most of the time. If it's off it's only off by 0.1g or 0.2g. 16.8g, 16.9g and 17.0g are the most common results.

This is a video of the Sette grinding 17g of coffee. It overshoots 17g by 0.2g, but this was before I adjusted the default offset described below.

Baratza did have some issues with the accuracy of early production model grinders, judging by user comments on various websites. Some users saw a wider range of results that were inconsistently higher or lower than the target. I believe those issues have since been addressed, as evidenced by the model I received in April, but if you receive a model that has an issue Baratza customer service will make it right for you.

More commonly, you may see the ground coffee result consistently high or low by a small amount. Baratza has a tuning offset setting to allow users to adjust for this, if your grinder is consistently higher or lower than the target. I noticed initially that my grinder was consistently about 0.3g higher than my target at 17.3g. I adjusted the factory default offset up by that amount to compensate, and now the result is exactly where I have the target set at 17.0g.

The accuracy of ground coffee by weight has been a huge quality of life improvement for brewing espresso at home, but its perhaps nothing compared to the other major improvements that the design of this grinder affords home brew enthusiasts:

  • The straight down design from bean hopper to the grinding burrs to the dosing chute virtually eliminates grounds retention – making it simpler to adjust grind settings and easier to avoid stale coffee caught in the chute ruining flavor.
  • The straight down design coupled with a very high grind speed results in very evenly distributed grounds with ZERO  clumping – dramatically lowering the chances of channeling ruining an espresso shot.
  • The hopper itself is removable, making it simple and easy to change beans regularly to try something new.
  • The grinder includes a full range of macro adjustment settings and a wide range of micro adjustment settings PER macro setting – making it extremely easy and intuitive to fine tune your brew times to exactly the timing and flavor profiles you're looking for.

I try a lot of different coffees as a home brew enthusiast. There are certainly some that I come back to frequently that I like, but I like trying a variety of coffees from local shops in Austin, and I always bring back a new bag of coffee to try at home when I travel. That means I'm usually dialing in a new coffee every week or two. Because that's such a big part of my workflow, I really love how well the Sette 270W works for dialing in new coffees. The excellent set of adjustment settings coupled with the other features above make it simple and easy to dial in a new coffee.

When I start dialing in a coffee I set the macro ring somewhere in the 7-10 range, and always start with the micro setting on E - the center setting. Adjusting from there based on extraction time is very intuitive for someone accustomed to dialing in a grinder. What I like about the Sette's adjustments is how predictable they are. If you're several seconds too fast or slow, then one or two turns of the macro adjustment ring should bring your extraction very close to where it needs to be. But if you're only a second or two off, then one or two turns of the micro adjustment ring will almost certainly bring it perfectly in line. That predictability gives you a lot of confidence making adjustments to suit taste, or to correct for coffee that speeds up or slows down as it gets older. The micro adjustments are a huge improvement, meaning that you don't have to worry about overcorrecting if a macro adjustment might be too much change.

The straight down design of the Sette is a clear breakthrough and a wonderful innovation. Ground coffee shoots out the bottom into the portafilter at a very fast rate, and very evenly with no static or clumping issues. I was taught to tap my portafilter on the side to settle the grounds, and then use my finger to break up any obvious clumps and make sure grounds were evenly distributed. The Sette completely removes the need to do this. The grounds are so fluffy and evenly distributed that simply shaking the portafilter gently from side to side is enough to settle everything evenly before tamping. It's delightfully simple and easy to tamp.

That even distribution and easy tamping has been a huge improvement for the consistency of my results. I used to have a few issues with shots channeling if I didn't pay close enough attention to clumps and even distribution of grounds. The channeling was most annoying when it happened while I was dialing in, because I could never tell if it the shot was running fast because I made a mistake in my technique, or if the grind settings were too coarse. The results are far more consistent now, with channelling a very rare occurence.

I can't believe how much of a difference the Sette has made to my home brew espresso experience. The improvement in quality is remarkable, and it just makes the whole process more delightful. The consistency and ease of adjustment afford more opportunities to experiment with flavor, and I think I'm learning more about coffee now as a result.

If you decide to buy a Sette 270W I think you'll like it, and I very highly recommend it.


Note for purchasers:

One note that I do have to future owners is what to expect for break-in time after you start using the grinder. Baratza mentions a roughly 2kg break-in time for the burrs to settle into their routine. This very closely matched my experience. I'm on my 5th or 6th pound of coffee now, and I think my grinder has finished settling. The grinder trends towards a finer and finer range during break-in, which is normal and expected. 

During or after break-in, it's also expected that you'll have to add a shim to maintain the fine espresso brewing grind range. Two shims are included in the packaging with the grinder. I knew about this when I purchased the grinder, so I decided to add one shim immediately after I set up the grinder. After break-in, my grinder had shifted down towards the finest settings for espresso, and so I added the other shim after I'd run through 4lbs. I've been very happy with the range and consistency since then. For the curious, around 8E seems to be the sweet spot for me right now with two shims and the Rancilio Silvia.

 

Other sites that carry the Sette:

My Homebrew Espresso Morning Ritual

Every morning has begun the same way since I bought a home model espresso machine last year: walk to the kitchen, and turn the machine on to start heating up. That's the first step in the relatively complex, yet fun and rewarding, process of brewing a morning espresso. I'll describe the rest of the process here, with links to some of the gear involved below.

The Acaia Lunar scale measuring the extraction time and weight of espresso for the current pour. This pour is running slower than normal - ultimately reaching 30g in about 35 seconds. The slow pour actually works well for this particular coffee, with the sweetness balancing things out and not being too sour.

The Acaia Lunar scale measuring the extraction time and weight of espresso for the current pour. This pour is running slower than normal - ultimately reaching 30g in about 35 seconds. The slow pour actually works well for this particular coffee, with the sweetness balancing things out and not being too sour.

People that enjoy coffee all have different approaches to brewing at home. Some people don't want the fuss - and will default to the best option with only one button to press. Others welcome the fuss, and will agonize over water temperature and pouring motions to create the optimum cup. Others want to experiment, not just with brewing methods but even coffee roasts - some going so far as to roast their own beans at home.

What I enjoy about home brew espresso is the number of variables involved, and the attention to detail that the combined process requires to brew something great. It's a delicate balancing act, and a multi-variable equation between grind size, weight, time, water temperature, pressure, water volume, and a variety of other factors...not to mention coffee itself.

While the machine is heating up I grind coffee into the portafilter basket. Grinding is a key step, and most mornings when I begin my grinder is still dialed in to the specific setting that I adjusted it to when I bought the coffee I'm brewing. Dialing in a grinder is a process of trial and error, but involves finding the right setting that controls the flow of water through the finely ground coffee powder. If the grind is too coarse, then water will flow through too quickly without extracting anything from the grounds. If it's too fine, the water gets trapped by the coffee and won't flow through at all. For brewing espresso, you're looking for a grind setting that allows water to flow at a relatively slow rate of 30 seconds.

The Baratza Sette 270W grinding into the Rancilio Silvia's portafilter.

The Baratza Sette 270W grinding into the Rancilio Silvia's portafilter.

The amount of coffee grounds is very important for espresso. The standard recipe for espresso is a 1:2 ratio of ground coffee to brewed espresso. If you start with 17g of ground coffee in your portafilter basket, you should expect to end up with 34g of brewed espresso. Less than 34g, and your espresso might taste too sweet, or more and it might taste too sour or bitter. You can always adjust this to suit your own taste, but 1:2 is a good place to start.

One of the most important pieces of kit for any home brew coffee setup is a good scale (or two). The scale needs to weigh both the amount of coffee grounds, and the amount of brewed espresso. You can use the same scale for both, but many people use different ones designed for each task. The industry leader for scales designed specifically for coffee is Acaia. Their scales are water/coffee proof, extremely accurate, very sensitive down to 0.1g, and include specific software features to make brewing coffee simpler and more fun.

The Rancilio Silvia and Acaia Lunar scale, set up on the counter getting ready to brew.

The Rancilio Silvia and Acaia Lunar scale, set up on the counter getting ready to brew.

Before brewing I make sure the grounds weight is what I'm expecting for the coffee I'm using. I usually prefer about 17g of ground coffee, but sometimes I use 16g or 18g depending on the type of coffee. Even just 1 gram actually makes a noticeable difference to flavor and quality when brewing espresso - which is why a good scale is so important. When I buy a new bag of coffee I write down the grind size and coffee weight on a small whiteboard next to the grinder so I don't forget.

The next step before brewing is to tamp the coffee grounds into the portafilter basket using a small tool called a tamper. The whole point of tamping is to uniformly distribute the coffee to make water flow through it evenly. That includes breaking up any clumps or chunks of grounds that might exist in the basket, either by running your finger through the grounds or tapping the basket lightly from the side with your hand. Then I hold the basket down on the counter with my left hand, and tamp firmly with the tool in my right hand. There's plenty of technique involved with tamping, and I don't think mine is that good yet. But I focus on creating an even surface with the tamper, and trying to let gravity do the rest.

Controlling the water temperature is important for any type of coffee brewing, including espresso. Most commercial espresso machines have special temperature controllers that allow you to set a specific temperature that the machine will hold. My home machine is a Rancilio Silvia. The Silvia is special because it is built using the same commercial-grade components that go into Rancilio's larger and more expensive machines. But it doesn't have a built in temperature controller - so you have to control the temperature manually before you brew.

Once my portafilter basket is tamped and ready, I put a cup under the machine and run hot water into it. While the hot water is running from the boiler out of the machine, cold water from a tank is refilling the boiler. This levels out the machine's temperature, and a light turns on when the temperature falls below a certain level. That's my queue to stop the water, pour the cup out in the sink, and attach the portafilter basket to the machine. It takes about 10-15 seconds for the boiler to heat back up to the correct temperature...and then the light turns off. Just like in a car race, when the lights go out, it's time to brew.

Under the portafilter basket of my Rancilio Silvia machine is an Acaia Lunar scale. This specific model of scale from Acaia is specifically designed for espresso. First, it's small enough to fit on the drip tray of most espresso machines, and thin enough to hold a normal size coffee cup below the portafilter. That means it can weigh the amount of coffee being brewed in real time as it's coming out of the machine - allowing me to monitor the progress of the brew. Second, it has a built in timer, which is the other key variable to brewing a great tasting espresso.

We talked about the recipe for espresso earlier (a 1:2 ratio of ground coffee to brewed espresso), and about the grind settings required to produce a flow rate of 30 seconds. Brewing is where we combine this multivariable equation to produce espresso. We want to brew 34g of espresso, but we want it to take 30 seconds before the scale reaches that number. If it's too fast, and reaches 34g in 20 seconds - the espresso will taste weak or bitter. If it's too slow, and takes 40 seconds to reach 34g, the espresso will taste too sweet and strong. Extraction that is too fast or too slow is my queue to start over and adjust the grinder before trying again.

What a pour will usually look like when it's just starting out.

What a pour will usually look like when it's just starting out.

After the light goes out I start the brew. The machine starts building pressure and forcing water through the tamped coffee grounds in the portafilter basket down into the cup on top of the scale. The scale is very smart. It automatically tares out the weight of the cup, and automatically starts a timer counting up. While the machine is brewing, I watch the weight and time numbers on the scale. It should take a few seconds before any espresso drips into the cup at all, and it should progress slowly for several seconds after that before speeding up. At 15 seconds, the weight of the espresso might only be 10g. By 23 seconds though, the weight of espresso will likely have caught up, and read 23g.

When the scale reads 34g I turn the machine off. The espresso is finished brewing. Hopefully the timer on the scale reads close to 30 seconds. If it's anywhere between 26 and 34 seconds, then we have likely produced a very tasty espresso. How tasty will depend on the quality and freshness of the beans and their roast, and on some other factors that are harder to control.

Near the end of a pour the espresso consolidates into a single thick stream of a brown color.

Near the end of a pour the espresso consolidates into a single thick stream of a brown color.

Once the espresso is finished brewing I'll clean out the portafilter and the machine itself, preparing it for the next cup. I'll turn the steamer on to heat water for steaming milk to pour a cappuccino. I prefer the ratio of milk to coffee in a cappuccino at home. Steaming milk takes some practice, and is harder to explain in a blog post. I've learned by trial and error, and watching several youtube videos. The Rancilio Silvia does a great job steaming milk.

This is a lot of explanation about a process that might seem foreign to anyone who hasn't brewed espresso or other types of coffee before. You have to pay close attention to the details, but it's not hard to grow accustomed to. I've really grown to love the process. I love dialing in the grinder, and monitoring all the variables, and changing some of them to see what happens to the flavor. All told, making a cappuccino in the morning only takes a few minutes, and boy does it taste good :)

Everyone needs a morning ritual of some sort, and this one is mine. Turning on the espresso machine and making a cappuccino.

All of the gear I am using at home is listed below:

Introducing Grocery - An Opinionated Shopping List App for iPhone and Apple Watch

I'm excited to introduce Grocery, a new app that Ryan Considine and I built specifically for grocery shopping with the goal of making trips to the store more efficient. We started the project with a question — what if our app knew the path we took through a store, and how would it use that to make the trip more efficient? What we are launching is a simple shopping list with a focused interface that includes a lot of intelligence to always keep your list sorted in the order that you shop.

Grocery for iPhone

Grocery for iPhone

Smart Sorting

Sorting a grocery list is no small task. There's no end to the variety of different ways that people shop. Paper lists are still very common, and people have different ways of manually sorting their lists. Grocery store layouts are almost as varied as individual people's shopping behavior — even among the same chain of stores. Some stores have tried to solve this problem with technologies like geolocation and beacons, but those are expensive to install, unreliable to use, and just haven’t caught on.

We wanted to build something that would be easy and reliable for everyone to use, regardless of store location or shopping habits. Our first step was to create our own intelligent sorting algorithm that can learn from an individual's shopping behavior. This is a new approach that we haven't seen applied before, but we chose to pursue it because it doesn't require hardware or analytics, or even a user's location to build a custom sorting order.

The algorithm we built learns from each trip you make to the store and sorts based on the order you shop for items and check them off your list. All of this analysis is taking place on the user's phone and stored locally. We aren't doing any machine learning in the cloud — not just for privacy reasons, but because there's no need. Everyone shops differently, and we don't need to learn from someone else's behavior to build a better sorting order for you.

Let's say you make a trip to the store for a few essentials, in this case:

  • Eggs
  • Milk
  • Avocados

You move through the produce section of the store first, and this was the order that you picked up the items and checked them off your list:

  • Avocados
  • Eggs
  • Milk

From now on, Grocery knows that Avocados come before Eggs and Milk. The next time you go to the store and only need to visit the produce section, but added a few new items to your list:

  • Kale
  • Carrots
  • Onions
  • Bell Peppers
  • Avocados

After this trip to the store, Grocery knows how to sort all of these items relative to each other, and because you previously shopped for Avocados, it also knows that these items all come before Eggs and Milk. If your next trip to the store is for Kale and Eggs, Grocery will know which item comes first and sort your list accordingly.

 

Apple Watch

Grocery for Apple Watch

Grocery for Apple Watch

Efficiency in the store is our number one goal for Grocery, and an even more efficient place for the app is on the Apple Watch. We learned early on that the Apple Watch was a great device to use at the grocery store because it keeps your hands free to hold items or push a shopping cart.

We wanted the Apple Watch experience for Grocery to be the best possible. To that end we actually built the Apple Watch UI before we started on the iPhone. We spent a lot of time optimizing it to be as fast as possible - which is key for third party watch apps.

Always having your Grocery list in sorted order is the key to an efficient and effortless user experience on the watch. Because your list is in order, the item you just put in the cart that you’re looking to check off is visible immediately after raising your wrist without your needing to scroll to find it.

Raise your wrist, tap the item to check it off, look at the next item on the list, and lower your wrist. It’s a very quick interaction that makes shopping with the Apple Watch feel easy and efficient.

 

Adding Items

We also wanted adding items to your list to be as simple and fast as possible. The iPhone UI for adding items is optimized around speed and efficiency. The text field for adding an item and associated notes is always present at the bottom of the screen, within easy reach. Tapping the + button after entering an item keeps the keyboard up, ready to enter more items. And we built our own autocomplete system that populates from your personal history of purchased items, making repeat entries fast and easy.

You can also add items to the list on your Apple Watch, via dictation or scribble, or by picking a past item to add back to your list. We've all been in places where using our watch to do something is simpler than taking our phone out, and we wanted to make sure Grocery supported that use case.

But we didn't stop there. You can also add items to your Grocery list from the Mac, iPad, iCloud, and Siri! And even, via IFTTT, from Alexa. That's because Grocery is built on top of the iOS Reminders database, which supports shared lists on iCloud. When you start using Grocery, we prompt you to create a new list called "Grocery" (which you can change if you want to), that can be edited from any device with the Reminders app, or access to iCloud.com.

Support for Siri is something we've really grown attached to. Even the phrasing is simple with the default list name — "Add Eggs to my Grocery List", and items show up immediately after they're added. Voice assistants like Siri and Alexa work great in kitchen settings, and adding items to your shopping list that way is a great example of why.

And finally, because we're supporting iCloud Reminders lists, you can also share your list with a partner or roommate, and they can add items to your shared list from Grocery or from the Reminders app. You'll each see the items the other added in your list - but each person will still have a unique sorting order based on the order in which each person shops for items.

 

Conclusion

Grocery is launching today as a free app that includes Google app install ads, with an optional in-app purchase to remove ads and support future development of Grocery. We love using the app and are excited to introduce it. We hope you enjoy it!
 

Thoughts on a New Mac Pro

Like many other pro Mac users I was very surprised and excited to hear that a new Mac Pro is in the works. I don’t think I actually believed the Mac Pro was dead, at least not deep inside. But I had certainly come to terms with never buying one again…until now.

Before the Retina iMac, I used pro Mac towers for almost 10 years. I used a Power Mac G5 from 2005 to 2010 and a Mac Pro from 2010 to 2014. If there’s anything I took away from the experience of using pro Mac towers, it was the incredible performance. When I upgraded to the Mac Pro in 2010 the dual PowerPC CPU’s in my Power Mac G5 still felt like they had more in the tank. Those Mac Pro’s are famous for their longevity - mine was still performing very well when my iMac arrived.

What I want out of a new Mac Pro is a return to that level of performance longevity. The old Mac towers were relevant for 5+ years after you bought one. They stayed relevant because they used the highest quality parts currently available and had some user-replaceable parts. In both towers I owned I upgraded the RAM several times after I bought them - eventually reaching max capacity as I could afford it and the system felt like it needed it. I upgraded the Power Mac’s GPU to an Apple-sanctioned optional X800. I upgraded the Mac Pro’s storage many times over the years before eventually installing PCI-e SSDs in the giant tower - a massive boost to storage performance.

When I moved away from the towers to the iMac I also moved all of my primary storage to external drive enclosures. That experiment was a success. Apple made a big bet on Thunderbolt for expansion. From my experience, that was the right move. My Mac Pro had 8 internal drives at the end (4 in the 3.5 bays, 2 in the optical bays, and 2 PCI-e slots). That setup was convenient, but it wasn’t necessary. Thunderbolt enclosures are more affordable and the available storage capacity of SSDs and cloud storage has risen significantly. There are plenty of options to choose from now to increase storage capacity and performance. I’m very happy with the Thunderbolt storage system that I’ve been using with my iMac.

The biggest concern I had with the Retina iMac was graphics. Unfortunately I think that concern was valid. The GPU industry is advancing at an incredible pace, and the lack of an ability to upgrade the GPU is going to limit how long my iMac stays relevant for performance graphics. I don’t blame the iMac for that - the iMac was never intended to have upgradable or full-size GPUs. But what I want from a new Mac Pro is exactly that: upgradeable industry-standard GPUs. The older Mac towers had upgradeable GPUs after a fashion, but it was clearly an edge case. I’d really like to see Apple focus on solving this particular problem for pro users.

The 2013 space-age cylinder Mac Pro cut a lot of features from the 2010 Mac Pro. Some of those include:

  • 3.5” bays
  • Optical bays
  • PCI-e Slots
  • FW-800

As a long time Mac tower user, I agree with all of those cuts except for PCI-e. Optical drives are clearly dead, and Firewire support is easily gained through Thunderbolt hubs for legacy drives. Storage expansion through Thunderbolt is a very reasonable option for virtually everyone - and for the folks that don’t want to deal with spinning disk enclosures, the price of large SSDs is very close to affordable levels. But dropping PCI-e expansion was a step too far. PCI-e is a requirement for upgraded graphics, and is a great option for a lot of other expansion, including storage. 

I’m 100% on board with the suggestion ATP hosts made in “Thermal Corner” regarding adding additional PCI-e SSD expansion ports to the new Mac Pro. That would be a great step forward and go a long way towards keeping these machines relevant for years after you buy one.

The other wish that I have for the new Mac Pro is this - keep at least two Thunderbolt 2 ports. I can see why Thunderbolt 2 might be on the chopping block for the new Mac Pro. USB-C may be the future, and I understand why Thunderbolt 2 was removed from the new MacBook Pro’s. But when Apple signaled the shift to Thunderbolt storage, a lot of pro users invested heavily in Thunderbolt storage setups for an iMac, 2013 Mac Pro, or MacBook Pro. Apple should make using these storage expansions as easy as possible for Mac Pro users, especially on a machine where storage expansion through Thunderbolt will be required.

So will I buy a new Mac Pro? I think I will. My iMac will be about 4-5 years old at that point, and out of Apple Care. I wasn’t kidding about the graphics not holding up on the iMac. The iMac used to run Blizzard games at high settings when it was released, but lately I’ve had to reduce all of the settings to fairly low levels. The CPU is still one of the fastest that Apple has shipped in a computer, and the display is still amazing, but I think the graphics performance could be enough to convince me to upgrade.

Apple Watch at 360iDev

Next week I'll be presenting a talk on developing apps for Apple Watch at 360iDev in Denver, Colorado. I've been wanting to go to this conference for a long time and I'm really excited to be presenting this year.

I've written and talked a lot about watchOS, and this time I'm going to try and share as much technical detail as I can about what it's like to develop for the watch. I think that watchOS 3 will make developing for the watch much more appealing for a huge number of teams and developers. I'm hoping that people who attend my talk will come away excited about building a watch app and ready to get started.

My only regret going into the conference is the other talk during my time slot is one I'd really like to see! There are so many great topics and speakers that I'm really looking forward to being there this year.

CocoaConf Yosemite

When I first heard about CocoaConf Yosemite I couldn't believe there was a conference designed around three very different things that I love: Apple, Photography, and the outdoors. I enjoyed the experience so much that I went back for seconds this year and had an even better time. The conference is returning for 2017, and I'm very much hoping to attend next year.

It's hard not to feel inspired in Yosemite National Park. Spending time outdoors has always been a great way for me to recharge, but the serenity you can experience in Yosemite Valley is quite unique. There really is nothing else like it. If this were just a tech conference then Yosemite would still be a very special setting that people would get a lot out of. But CocoaConf Yosemite is more than that. It's a place to focus on the human side of working in the technology industry and why what we do with technology matters to other people.

When I came to Yosemite last year I spent some time after the conference exploring the park. I had a chance to hike around by myself, which was a unique experience for me: I almost never go out hiking on my own. But it lead to some of the most amazing things I've had happen to me on the trail, like getting snowed in above Yosemite Valley!

Snow! I woke up around 6am with a foot of snow outside my little backpacking tent.

Snow! I woke up around 6am with a foot of snow outside my little backpacking tent.

Getting out and hiking by myself was actually pretty far outside my comfort zone. But that also fits the theme of the conference, which really focuses on learning more about yourself. Pushing myself lead some amazing experiences, including witnessing the most amazing sunset I've ever seen, above Half Dome. A picture of the sunset from Cloud's Rest is my favorite picture that I've ever taken. But it's not just the picture I like, it's the experience that it represents. Talking to people in the valley to get ideas on where to hike to. Planning the hike and determining if I could make it safely to where I needed to go. Being totally isolated, knowing I was the only one witnessing this in person up in the snow, but being able to share the experience with people later through photographs. And knowing the whole time that I was out there doing something new that I enjoyed. Such is the power of exploring the outdoors, that just one sunset can mean so much to you.

Sunset from Clouds Rest, overlooking Half Dome in Yosemite National Park.

Sunset from Clouds Rest, overlooking Half Dome in Yosemite National Park.

While I was exploring Yosemite that first year I had a few books with me. I read Becoming Steve Jobs by Brent Schlender, as well as Creativity Inc. by Ed Catmull. Both books taught me a great deal about leadership that I don't think I would have understood as well outside of a place like Yosemite. The conference and the environment were the perfect backdrop for listening to these types of stories.

This year leadership was a central theme at the conference, as well as another trait I wasn't expecting: vulnerability. I had started reading Daring Greatly by Brené Brown before the conference and I kept marveling at the similarities between what was being discussed in the conference talks and the themes of Brené's book.

Daring to be mediocre. The only thing between you and what you want to do is doing it. Be a little wild because we are in the wilderness. Be your own replacement. Challenge yourself. Having empathy for the point of view of others.

Many speakers told stories of using 31 day challenges as a way to coach yourself into doing something you were interested in but not comfortable getting started with. It takes courage to start something new, especially something you don't know you'll be good at. Daring to be mediocre helps you take a step towards something you want to achieve but are having trouble getting started with.

But the biggest takeaway I had from Yosemite this year was community, and how important it is. Sometimes it's easy to forget in the interregnum between WWDC's just how special the community is around the technology industry. The tech community is one that I think can be of immense service to others. I was so impressed by the talk Christa Mrgan gave on Civil Comments, a tool that is actually helping change people's behavior and positively influence the nature of discussion online. That's the type of impact we can have on the world, and I think it's a perfect example of why CocoaConf Yosemite is so great. It's about inspiring you to make a difference, in your team, in your company, in your community, in the world.

CocoaConf Yosemite is the best experience I've had at a conference. If you haven't been I highly encourage you to go. I'm hoping to return again next year.

App Launching on Apple Watch

Let me start by saying that I am very excited about watchOS 3. If I could have made a list and told Apple, "Here are the improvements I would like to see made to watchOS at WWDC this year" then I would consider that list to be thoroughly crossed off. A focus on performance, background updates for workout apps, and ditching the Friend button in favor of the new Dock are exactly what I wanted to see.

A lot of people watching the announcements caught that one notable Apple Watch feature was omitted from the commentary. The App Launcher, or Honeycomb / Home Screen, wasn't mentioned in the keynote or subsequent discussion about how users interact with Apple Watch. The subtext is clear. I don't think Apple intends or expects people to interact with their watch by launching apps from the Honeycomb any more than we do.

It's still clear that launching third party apps on the watch is very important. The Dock is a big step forward here but it can't be the only answer. The Dock is a more concise list of apps than the Honeycomb is, but the only context its aware of is which apps were launched recently or that the user favorites. The Dock is glance-able and meant to keep apps visible and freshly updated, but it's still not as easily accessible as the user's watch face with all of their complications.

It's been clear for several months that complications truly are the best app launchers. That's why the new ability to easily swipe between watch faces is absolutely game changing for Apple Watch despite not being something I was expecting. Next to the flashy new Dock it's an easy thing to miss, but I think it will have the biggest impact in how I interact with apps on my Apple Watch. 

The Apple Watch apps that I launch regularly are ones that I have complications visible for. I routinely use two fitness apps, UA Record and Runtime, because their complications are so easily accessible to me. The only time I go deeper into the Honeycomb is to launch apps that I don't have room to show their complications...like Stopwatch, or Timer. I choose not to keep their complications visible on my watch face because they usually don't have any content that is contextually relevant to me.

The significance of complications being the best way to launch apps is why swiping between watch faces is so valuable. It allows users to literally switch their context on the Apple Watch. One day this could presumably happen automatically, but at least it only takes one swipe to switch from your primary daily watch face to one with the type of information you want to have at a glance in another context.

This is going to completely change the way I use my Apple Watch. I'll be experimenting with this for a while in the coming weeks, but for now I've created three watch faces that I intend to switch between depending on what I am doing:

- Cooking
- Daily Activity
- Distraction Free / Movies

I love using the Stopwatch and Timer apps while I'm cooking or brewing coffee, but I don't want their complications visible during the rest of the day. The ability to swipe left and bring up an entire watch face devoted to them and any other complications relevant to cooking is a game changer for me. I'll keep my existing primary watch face configured with the date, and a few activity / fitness complications, and I'll also have my Movie watch face with no distractions that Ryan Considine inspired me to use.

Apple clearly intended for this usage pattern to take hold when designing watchOS 3. Craig Federighi stated so himself in tonight's live episode of The Talk Show in San Francisco. Watch faces are the true app launcher for watchOS, and users will start to customize their watch faces based on the contexts that are most important to them. This is where I could see some really exciting things happen with the platform. Collections of activity and fitness complications seem very likely to become popular, as well as watch faces with complications related to travel. I hope Apple will use curation to promote this concept and apps with great complications because of how much better this will make the experience of using an Apple Watch.

This is a really exciting week for watchOS developers. This is where the platform really starts to take off and we start to see what people will really do to build amazing watch apps.

The Twenty-First Floor

Lately I've been following along on the Swift conversation about static and dynamic features and the importance of the dynamic runtime. I'd like to share some of my thoughts as a developer who is using both Swift and Objective-C on an almost daily basis.

The concept of using the right tool for the job is a bit of a cliché, but it describes my views on the static nature of Swift very well. I like that we as developers for Apple's platforms have great options on both ends of the spectrum. Swift is an excellent static language, and Objective-C and the associated dynamic runtime is a great tool as well. I haven't found myself only wanting to use one or the other.

Maybe the point of Swift is to have a strongly-typed static language to use for the things that should have compile time type checking, like building application layers. Having the capability to build your application in a type safe environment while still leveraging a sophisticated dynamic runtime that supports tools and behaviors that make our applications easier to build feels like a huge advantage to me.

I think Swift is a great language and I've been enjoying using it to build applications and internally used frameworks. A team I work with just shipped an app built entirely in Swift with a 0.0% crash rate. There's a lot of places where using a static language makes sense, and I'm not ready to judge Swift's future based on whether it could be used today to replicate UIKit, Core Data, or any other Cocoa frameworks.

The measure of Swift's success shouldn't be whether or not it eradicates Objective-C from our tool chain. Honestly, I don't think that it should. The value it is adding to our existing tool chain as a foundational component, and the capability it brings to build highly sophisticated and powerful tools like Interface Builder and Core Data earn it a place in our tool kit for a very long time to come.

I liked this quote from Manton's blog post about Apple's mindset on Swift dynamic features:

Remember when Steve Jobs came back to Apple and compared NeXTSTEP to constructing a building by starting out on the 20th floor, with so much of the foundation and common patterns already taken care of for you? Cocoa allowed apps to be built significantly faster than before. Steve said at Macworld Expo in 1997 that the goal was to “eliminate 80% of the code that every developer has to write for their app.”

I love this, because I think the building metaphor applies really well to where we are with Objective-C and Swift. The building is Cocoa, and we don't need to re-build the first 20 floors. What's great about the static nature of Swift is it gives developers an option to make that last 20% of code type safe, faster, and more expressive. For a lot of applications and use cases, that's a really great tool to have.

–––

As a brief aside, I know that Swift has a lot of promise in areas with no history of a dynamic runtime, like Linux or perhaps even with embedded devices. I'm not trying to diminish that, or imply that Swift has to exist on top of Objective-C. I'm actually very excited about all of those areas and hope that Swift becomes widely used on other platforms. But I won't mind if much of the core platform for Mac and iOS continues to rely on the dynamic runtime.

Great Watch Apps are Great Complications

A great point came up in the Wrist UX panel I was on yesterday at SXSW, prompted by a user question about what makes the best watch app.

The best Apple Watch apps in my mind are the ones that include the most useful and frequently relevant complications. The watch face itself is the best piece of real estate on the watch. That's park avenue. It's what people will see all the time. The complications that inhabit it are the fastest way for users to launch your app. Having a great complication puts you in a prime position to have users interact frequently with your app while inherently giving them quick, timely updates at a glance. It’s an amazing feature for users, and the most rewarding should you get it right.

Designing a great complication is actually very hard to do. For complications to be used frequently they need to be something that a user would keep on their watch face at all times, meaning they should always have something relevant to show. 

Weather and fitness apps are great use cases, and I think the biggest reason why is the data they present you with is easy to take action on. If your activity ring or dashboard wheel isn’t full when you check the time before dinner, you might choose to go for a run. If you glance at your watch while getting ready in the morning and notice the temperature, you’ll remember to bring a coat. The fact that you notice these bits of information while doing something unrelated like checking the time helps you in a way you didn’t expect it to.

A complication that tracks a flight or a package is also very useful, but it's only relevant for a limited portion of time. These are the types that power users might set on a secondary watch face to use occasionally. Ultimately, I hope that Apple will eventually allow complications to be more dynamic based on context, but for now the best complications are the ones that are literally always relevant to the user.

Complications are also very difficult to design for because they have to provide relevant data without needing to be updated frequently. Generally speaking, a complication can only update itself once every 10 minutes. If your concept for a complication requires more frequent updates than that, then you may have to go back to the drawing board.

Getting the complication right is the key to unlocking a huge amount of potential on the Apple Watch. Once you get your one main use case nailed on the watch app, I would focus the rest of your energy on designing a great complication. It's difficult to do, and competition for space on the watch face is stiff, but when a user chooses to place your complication on their watch face that's when you know you've built a great watch app.

Wrist UX - Designing for Apple Watch

Today I was on a panel at SXSW focusing on the challenges designers face when creating apps for Apple Watch and Android Wear devices. I've spent the better part of the last year and a half building different apps on the Apple Watch, ranging from fitness trackers to news readers and collaboration tools. I really enjoyed speaking on a design focused panel and wanted to continue the conversation by sharing some of my thoughts here on what works and what doesn't when it comes to smartwatch UX.

The Apple Watch is both a blessing and a curse for designers. It has a very small screen that provides natural constraints for what you place inside of it. The watch invites simplicity, and welcomes a minimal approach to app design. But it is also very easy to overthink your design and create a complex and confusing user experience.

One of the reasons people complain that the Apple Watch is too slow and that apps on the watch aren't great is that many of them are trying to do too much. We're used to iPhone apps that can do 10 things really well. An Apple Watch app can’t really be great if it’s trying to do more than one of them.

Pick One Feature, and Maybe Not Your Most Obvious One

When it's time to gather around a whiteboard and start designing your Apple Watch app, draw all of your features and start discussing some of your least obvious ones. It’s very likely that one of them represents a better use case for the watch. If you start with the secondary features you might realize that focusing there can actually improve the utility of your overall product.

I think there are two great questions to ask yourself when considering a feature for the watch. Will having this feature on the watch make my combined wrist+phone experience better? Or is this feature simply a better fit for the watch than the phone?

I think that we are moving towards a place where watch apps become standalone. The Apple Watch is already a great standalone fitness tracker and information dashboard. It's great for quick updates and simple bursts of interaction. But it’s also still safe to assume that the user has their phone with them, so an augmented experience that improves with both devices is also important to consider.

What each app does best on the watch will be very different. And honestly it doesn't even need to be an app. Notifications are a core feature of the watch for many users, and providing excellent contextual notifications that a user can take action on is huge win for many apps. Richly detailed notifications are a big differentiator on the watch, and I think that’s an important area for any iOS designer to consider.

It’s very hard to do more than one thing well in a watch app. Screen space is one issue, but there’s also limited context around what the user might be doing while using your app. It’s very hard to build an app that will be easy to use in multiple different situations. Scrolling through a grocery list on your watch while sitting on the bus is a very different experience than trying to scroll through it with two hands while pushing a grocery cart. That's why it's better to solve for one use case, and make that one interaction simple, fast, and intuitive in as many contexts as possible.

Protect The User

One of the reasons it’s so important to focus on a single use case and keep your design simple is so that you can protect the user from getting lost or feeling like they can’t get to where they want to go. The watch just isn’t big enough for bread crumbs or detailed error states or handling issues like that. Think about protecting the user to keep your interactions quick and to the point.

On our panel we discussed the concept of an undo action. How would you undo something on the Apple Watch? Would you scroll down to reveal more buttons, or force press to find a reset button? Or would you just shake your wrist, like the system undo gesture on the iPhone? In reality, none of those interactions work or are standard for this action, and that’s probably for the best because we ought to design our apps such that they aren’t necessary.

One example of very focused simplicity on the Apple Watch are the Activity rings. A discerning user might think that if they stood for 6 full hours on a walk and at the park that it should count as a full 12 hours credit on the stand ring, because 6 full hours is a greater amount of time than 12 partial ones. But the beauty of the activity rings is how simple the UX is. There is only one way that system ever behaves. If that ever changed, it would confuse people.

The same principle applies to our apps too. If you have to invent logic that changes the behavior of a feature based on information the user doesn't have or that isn't obvious to them, then you can't expect for them to understand what is happening.

One of the hardest things to do well in an Apple Watch app is to keep its scope and feature set limited. Usually when you start building the app you’ll be surprised at how easy it is, and that success will lead you to want to do more. Remember that is a slippery slope and take care to avoid overcomplicating your app by trying to make it do more than it should. Avoid the Hamburger Force Touch navigation pattern.

It’s also important to prototype and test your designs with users before shipping the final product. The fastest way to prototype a watch design is on paper. Draw out your screens and see how it makes sense to you and your team. You can actually get really far into your design just using paper or a whiteboard, because of how simple a watch app should be.

One of the lessons we learned while user testing our apps is that even experienced Apple Watch users are trained to tap and scroll and don’t intuitively reach for the Digital Crown as an interaction mechanism. Adding a coach mark or guide post to the screen to indicate interactivity actually improved the usability of our app quite a bit. We actually validated this by prototyping the feature in code, which was a really great way to try our assumption and get it in front of users quickly to see how they reacted to it in a real situation with working software.

Apple Watch Users Are Passionate

It's easy to look at Apple Watch users as just a subset of iPhone users, but I think that’s too shallow of a view of the smartwatch landscape. People that own an Apple Watch and use it every day LOVE that watch. If they're passionate about your app too then you have a great problem on your hands, which is that they want to use the app on their wrist too.

There have been a number of key moments for me that showcased just how much users of the Apple Watch care about the device and its software. I remember scrolling through the App Store reviews after shipping a new watch app several months ago, reading the comments left by people excited about the update. People that were excited about the watch app took the time to leave a positive review. Many included ideas for improvement or feature requests.

Users of another Apple Watch app I worked on are incredibly engaged on Zendesk. Proportionate to the number of users, there are a lot more comments left about the Apple Watch app, and many of them include very useful feedback from people who WANT to use the app. That was really the key moment for me with this lesson. Apple Watch users are clearly using the app enough to WANT it to be better so that they get more out of it.

Remember that these users are motivated to go the extra mile to make the experience on their watch better. I think it’s important to consider that and add watch-specific settings to your iOS app to allow people extra control over the type of notifications they receive on the watch or prioritize content they see on the watch. That’s a great way to keep people using your app who might have otherwise lost touch with it.

A lot of people think that third party apps on the Apple Watch are dead. I disagree. I think that third party apps on the Apple Watch are a big opportunity to delight your most passionate iOS users who also use an Apple Watch.

Conclusion

Apple will eventually ship a better, faster, newer model of Apple Watch and a new version of watchOS. But the principles of design that we apply to watch apps now will continue to serve us well even as people expect more from apps on the watch. Keeping things simple and focusing on doing one thing really well is the best way to make your passionate users love what you made for them, and serving those users is a very worthy goal while you think forward to future versions of the platform.

Designing in Swift

I've been slowly easing into Swift over the past few months. Some projects I've helped with at work have been in Swift, and my last personal app, Picturesque, was written completely in Swift. I've really enjoyed using the language, but until recently hadn't designed a major new component from the ground up in Swift. Fortunately, last year at WWDC I think we got a great primer for doing this: Protocol Oriented Programming.

I've been attempting to follow a protocol oriented methodology, and so far I've really enjoyed it. The rule of thumb I've been trying to follow is not to use classes for anything. It's obviously possible to take this rule to the extreme, but I think it is a good standard to start by for learning how to design in Swift.

Without using classes (much), you're left with Protocols, Protocol Extensions, Structs, and Enums. I'm going to cover how I am currently using each of these in my design.

Protocols

Protocols are, of course, the primary interface to what I am building. They represent the capital-T Types that another developer would be interacting with, and the methods they would be calling. But they also represent the plumbing between internal components. 

For a message passing framework there are public facing protocols like Listening, and internal protocols like Persisting or Encoding. Since Protocols are also just Types, the Listening protocol can have a reference to the Encoding Type that its implementation can use to decode a message. This form of dependency injection has always been a good idea, but the reason this is so useful in a Swift design should become clear below.

Protocol Extensions

Not only can Swift protocols inherit from other protocols, but they can also be extended to provide a base implementation of their methods, or add new ones. Using this feature to provide a base implementation of a common protocol is a huge deal for Swift. You know exactly what I mean if you've ever defined a protocol in Objective-C that many classes implement, and had to copy-paste the same method implementation between all of them.

I'm also using protocol extensions to drive out the dependency injection scheme described above. Since a method implemented in a Swift protocol extension has very limited access to Self (after all, this isn't a Class implementation), you have to make sure that anything that implementation needs is available from the protocol definition. 

That's why having your protocol reference other Types, like an Encoding type, is so useful. Those referenced types end up forming the shared base implementation of the protocol. If your varying implementations of the protocol need to change the behavior of one of the base methods, they won't override the method, they'll just override that dependency instead.

Structs

One nice thing about structs is that they're really not intended to mutate. Once I find myself starting to insert mutating keywords in front of method definitions I start to think through A) whether or not I should just use a class, or B) does this method really need to be changing state after all? Many times, having a struct (instead of a class) implement a protocol has helped me make better decisions about how my methods handle object state, which I think makes me more careful when adding or changing state. Of course, structs shouldn't be encapsulating state anyways, which leads us to:

Enums

Enums are my favorite feature of Swift. I don't think we could have asked for a better tool to manage state and branching in our programs. Enums can have methods, hold associated values, and conform to protocols. Their initializers can even take parameters. They're beyond cool.

One of the ways that I use enums is to support different behaviors for different cases - a common programming problem. I have an enum conform to various protocols that can return a Type. A message passing system could use an Enum to represent the form of messaging, which could return a different version of the Encoding type for each case. Other implementations only need to hold onto the current case in order to receive an Encoding type for that case, and don't need to care about state. All of that is managed by the enum itself. Generally speaking, if you start to define a switch statement outside of an enum, consider just using an enum instead or adding your functionality to the existing enum.

Conclusion

We're still in the early days of discovering what makes for good design in Swift. From what I've seen so far, I'm very excited about adopting a protocol oriented methodology and continuing to learn more about good code design in swift.

Swift is clearly a language that presents us with a lot of options from a design perspective. Once we get accustomed to protocol oriented programming, the next big decision to master is going to be when to use reference types (classes) versus value semantic types (structs, and enums). That's a decision we really weren't accustomed to making regularly with Objective-C, but one which presents a whole new set of options to consider in Swift. I don't have an answer for this one yet, but stay tuned for a future blog post.

Review: Running Belts for the iPhone 6s Plus

It's prime running season here in Austin, TX and I've finally finished up a new batch of running belt reviews. I've been using several of these belts for a while now with my iPhone 6s Plus, though the FlipBelt Zipper is a very recent (if greatly anticipated) addition. The iPhone 6s Plus is of course the same basic size as it's predecessor, so running with a large iPhone isn't a very different experience than it was last year. But, I do think the popularity of the large phones is fueling a larger market for iPhone running belts, which warrants expanding my reviews to include more products as they come on the market.

Note: The links below are Amazon Affiliate links. If you find this review useful and decide to purchase any of these belts, consider using the links below and you'll support this site.

Note: You can find a link to all of my previous (and future) running belt reviews here at the Running Belt Mega Review.

Daswise Waterproof Running Belt

Daswise Waterproof Running Belt

Daswise Waterproof Exercise Runners Belt (Amazon) - Facebook

I picked up the Daswise runners belt after seeing the great reviews on Amazon and being curious to try a waterproof belt. Even though I'm usually not taking my phone out to run in the rain, protection from sweat was a key reason for me switching to running belts over armbands in the first place, so moisture protection is a welcome feature.

The pocket on the Daswise feels like the right size for an iPhone 6s Plus. It needs to stretch a little when headphones are plugged in, but that's very typical with most running belts. The snugness means that the phone will lay flat while running and not tilt down to either side.

I did notice that the Daswise straps were fairly smooth. The friction point between the straps and the buckles is low, making it fairly easy to adjust by pushing on the buckles. For this reason, I feel like this belt was probably designed to be worn with the pocket on your back. In this orientation, one would simply grab both buckles and pull backwards to tighten, or flick forward to loosen. That seems like a natural interaction to me, but for someone who wears their belt facing forwards, I had a little trouble getting the right fit. Once I found the right fit it did stay put without accidentally loosening.

While I haven't tested the Daswise out in a storm, I have noticed that my phone feels less damp after a long run when using this belt. I definitely think that it protects against moisture better than my other belts, but I would hesitate to call it waterproof. Fortunately though, the iPhone 6s Plus has been tested as far more resistant to moisture than previous iPhones, and the iPhone 7 is rumored to be totally waterproof, so this feature may not be required for long.

The build quality of this belt felt better than the TAPP-C, but not quite up to the level of the higher priced and very popular SPIbelt or FlipBelt. But for the price ($9.99 at time of writing) and with the additional moisture protection, this belt feels like a great bargain.

FlipBelt Zipper

FlipBelt Zipper

FlipBelt Zipper - Website

A favorite from my original Running Belt review last year, FlipBelt recently released a Zipper addition that addresses one of my early qualms with the original. Adding a zipper pocket makes a lot of sense for people running with loose items like a credit card or a single key that they don't want to worry about losing.

As I noted in my expansion review last year, the FlipBelt has actually become one of my favorite and most used running belts. A lot of this just comes down to comfort. The FlipBelt is soft and fits evenly around you, which makes it feel great for longer runs.

One downside is the sizing. FlipBelt isn't adjustable, so if you're really on the bubble between sizes I suggest ordering the smaller of the two. I actually ran into this issue this year because of losing weight. I'm now closer to the Large fit than the XL. My FlipBelt still fits and does work, but it's not quite as comfortable as it was previously.

The FlipBelt Zipper retains the great ease of use of the original. Getting your large iPhone 6s Plus in and out is still the easiest of any belt I've tried. Distributing snacks and other objects around the belt to spread out weight or bulk is also still a thing you can do.

As for the zipper pocket, it feels well made with a quality zipper, and is actually pretty large. It's big enough to hold an iPhone 6s Plus, but I wouldn't recommend putting it there. You have to really stretch the pocket to make the phone fit, but I think that's fine because that's not the intended use for that pocket. Keep the phone in the primary pockets, and use the zippered pocket for keys/cards/cash. If you've been holding out on FlipBelt until they added a zipper, then this is definitely the one for you.

Run Baby Running Belt

Run Baby Running Belt

Run Baby Running Belt (Amazon) - Facebook

Run Baby's belt borrows an aspect of its design from FlipBelt, going with a slot opening pocket rather than a zipper. While this design for a pocket works well, especially given its size, the other aspects of this belt are very different from FlipBelt.

The Run Baby belt uses a large band with a wide buckle. It's actually the largest buckle of any of the belts I've tested. In practice, this buckle felt too large for me. The size of the band and buckle are necessary to support the size of the rest of the belt and its pocket. Of course, having a buckle also makes this belt more adjustable than the FlipBelt, but the tradeoff didn't make this belt any more comfortable.

The downside of the Run Baby belt's pocket design and how it impacts comfort is the woven seems around the edges of the main pocket. The seems were irritating whenever they came in contact with skin, scratching in a similar way to velcro. If you tend to wear your belts over clothing this wouldn't be an issue, but I usually run with mine underneath my shirt.

The final area where this belt differs from the FlipBelt is around the pocket slot openings. The FlipBelt slots are fairly easy to locate because of an inseam that separates them from the rest of the main seam. The slots on the Run Baby blend in a little more, and are also a tad smaller. My iPhone 6s Plus still fits, but experienced a fair bit of friction when used with a case.

While I appreciate the ability to adjust a belt with a slotted pocket, the comfort issues were enough for me not to want to use this belt day to day.

Gear Beast Running Belt

Gear Beast Running Belt

Gear Beast Running Belt (Amazon) - Website

Gear Beast's belt is of a minimal style similar to SPIbelt or Daswise. The pocket is only barely big enough to hold an iPhone 6s Plus, and does hold it tightly. The straps are thin, but not too thin. The material is wicking, but isn't advertised to be waterproof.

After testing a large number of running belts, I appreciated the tight-elastic nature of the band on the Gear Beast. You can definitely tell that your phone isn't going to end up bouncing around, because the band does hold very fight after you snap the buckle.

The band attaches to the pocket in an interesting fashion, whereby the pocket itself sort of wraps around the back of the band. While I can see this being a win for durability, it has the side effect of torquing the pocket around the band. This means that unless your phone is perfectly leveled within the pocket, the compartment could be torqued up into your waist, or down towards your groin while running. This likely wouldn't be an issue for people that run with their belt behind them on their back, however I found it to be a little fiddly until I got the positioning right.

Similar to the Daswise belt, the straps on the Gear Beast were fairly low friction. I found them to be just a little bit tighter than the Daswise, making it easier to get the right fit while wearing the belt facing forwards.

With the same price and a very similar build quality to the Daswise, it might be difficult to choose between these two belts. I think the difference will come down to fit preference. The Gear Beast will be easier to get and keep the right fit, because of it's higher friction point and tighter elastic. The Daswise pocket is more evenly leveled though, so your phone will sit straighter in the pocket while at rest. Either way, both belts are quite cheap and are a good value.

 

SPI H20 Companion

SPI H20 Companion

SPI H20 Companion (Amazon) - Website

While not itself a running belt, the SPI H20 Companion water bottle does fit nicely as an accessory to really any running belt because of it's clip on design. The companion is marketed as an add on to the SPIBelt (Amazon), but really applies to anyone interested in trying to add hydration to their running routine.

What I found while testing the companion is that carrying hydration during my workouts was an adjustment I hadn't really considered before. It's something extra you need to plan for and optimize, and I honestly just hadn't thought about that challenge before. I've been very used to running in urban areas with lots of water fountains, but that's not always something that people have available to them while training.

I found the companion bottle to be an easy fit on the belts I tested it with. The clip on the back is easy to use while running. Drinking out of any bottle while actually running is a skill all of its own, but I appreciated the nozzle design of the companion that felt easy to direct the flow of water.

The one area that I wish were improved was the angle of the nozzle backwards towards the clip. When worn beneath clothing, I could feel the nozzle rub against my skin. I found myself just tucking the edge of my shirt around it, which had the benefit of preventing the rubbing as well as making it easier to pull out of the belt.

While the companion isn't something I carry with me on every run, it is something I can add to one of my belts for longer runs or when I'm out running in a place with less hydration available.

Note: SPIBelt supplied me with a SPI H20 Companion bottle for the purpose of this review.


Conclusion

So which belt do I choose which running belt I use for a given run? I usually go with lighter weight ones for longer runs, unless I need to carry bars or gels, when I'll choose one like the FlipBelt that offers more options for packing extra goods. Moisture protection isn't a big factor for me, and neither is fit. All of these belts fit me well. Comfort is very important though, and I usually find the smaller/lighter belts to be more comfortable for me, with the exception of the FlipBelt which remains my most comfortable belt.

Whichever belt you go with, I'll give one more shout out to running with the Apple Watch. In watchOS 2, Apple further expanded the workout tracking capabilities of the watch, making it a wonderful companion to any runner. I still carry my phone with me when I go running though, which is why I still feel it's important to have a good running belt.

I hope this helps you choose the running belt that is right for you. I think it's safe to say that larger iPhones are here to stay, which will make these running belts great running companions for us for a long time to come.

Mega Review: Running Belts for the iPhone

When the iPhone 6 Plus came out I decided to buy several running belts to try out for my own use as a runner, and after realizing how much I enjoyed using each unique belt I decided to start reviewing them.

FlipBelt Zipper

FlipBelt Zipper

Running belts have been a trend for a while now because of how well they solve the issue of carrying a large phone while running. They're quite comfortable, and not overly distracting while running. They're worn over your shorts or shirt which makes them get far less sweaty than an arm band, and they hold other things like keys or food. They're useful for more than just running, more comfortable than velcro arm bands, and are now made in dozens of models.

This post is a reference point to those reviews to make it easy to find information about each of the belts that I've reviewed. You can visit each of the reviews for details and images of each belt, or tap the links to visit the Amazon page or manufacturer's website for more information.

Review: Running Belts for the iPhone 6 Plus

Further Review: Running Belts for the iPhone 6 Plus

Review: Running Belts for the iPhone 6s Plus

Running with my phone in a belt ends up being a far better experience than running with an arm band. It's more comfortable and less intrusive, doesn't get as sweaty, and lets me carry some extra goodies for longer runs.

For runners looking to stay connected with their phone in a belt, running with the Apple Watch has been a great experience for me. It allows me to keep my phone tucked in its zipper pocket while tracking my workout and changing music tracks from my watch.

If you found any of these reviews useful and plan to purchase a running belt through Amazon, please consider using one of the affiliate links above to help support this site.

Introducing Picturesque - National Parks Image Trivia Game for Apple TV

I'm happy to introduce Picturesque, my first game and first app for the new Apple TV. Picturesque is an Image Trivia game focusing on America's great wonders - our National Parks. If you want to lean back get inspired for your next adventure, or challenge your friends to test their knowledge of these natural wonders, then try this. It's available today on the Apple TV App Store.

Home Screen

Home Screen

In Picturesque, the player's objective is to correctly identify as many parks as possible based on a random image of the park. It's a great fit for the TV because it combines social game play and interaction with rich photographic imagery. The pictures look amazing on a wide screen TV, and the new Apple TV remote makes the game play fun and interactive.

It's always exciting when you can build a product that bridges different hobbies and interest. Picturesque combines my work as an iOS developer with my passions for Backpacking and Photography. I'm happy for the result to be both my first game and my first foray into this new platform.

Game Screen

Game Screen

Designing the game modes was a fun part of working on Picturesque. We made the game modes include a time limit based on difficulty so that the game becomes more challenging as you progress to new levels. But we didn't want people to feel rushed to move on if they were enjoying the current photo, so we made the game require an explicit button press to move to the next image, instead of using an automatic timer. Enjoying the photography is just as much a goal of playing Picturesque as correctly identifying the parks are.

Because tvOS includes all of UIKit and Core Animation, we had a lot of flexible to design and build fluid animations between images in the game. You'll notice that the entire UI moves to advance to the next image. Transition animations like this look great on the large interface of a TV screen, but do still require a degree of subtlety the same as they do on smaller devices.

Picturesque is the first app I've shipped that is written entirely in Swift. I have to say that I am really enjoying developing in the new language. It's clear that this is our future as iOS developers. More and more of the work we are doing at Mutual Mobile is in Swift, and I feel very comfortable that this is the right direction for us to be moving in. Developing for tvOS in Swift 2.0 was a great experience.

Picturesque was designed and developed by myself and Ryan Considine. Working on this with Ryan has been hugely rewarding, and as an added bonus, we now have an added excuse to visit more National Parks!

With any new platform, this really is only the beginning. Developers have only had a few weeks to build products for this device, and I'm excited that it's now here and looking forward to seeing what's to come.

Game Complete

Game Complete

MMWormhole and WatchConnectivity on watchOS 2

This year at WWDC Apple introduced watchOS 2 and the ability for apps to run natively on the watch. If you already created an app for Apple Watch then your work can be easily migrated to a native watch app. The user interface and interaction model are the same. The biggest consideration when migrating your app to watchOS 2 will be updating your communication system.

The key difference between inter-app communication on watchOS 1 and watchOS 2 is where your message is going after you send it. On watchOS 1 your message was being transferred to a shared container that was accessed by two processes running on the same device. All of this was handled via App Groups and Darwin Notification Center. On watchOS 2 your message is being transferred over a Bluetooth or WiFi connection between different devices. For some apps, that means it's important to rethink your overall strategy for how, when, and what you choose to transfer between the app running on an iPhone and the app that is now running on an Apple Watch.  

Because your communication path now exists between two different devices, your communication architecture needs to make sure it takes latency and device availability into account. Complex apps will need to understand the tradeoffs between various communication mechanisms and how to use each one to achieve the best result. Now that the watch app runs on the watch itself, and the watch also has access to a WiFi network, you'll be using a combination of NSURLSession APIs as well as the new and extremely useful WatchConnectivity framework.


WatchConnectivity

The WatchConnectivity framework offers three core types of communication operations.

The Application Context is a shared data structure where you can store information that is synced in the background between the watch and phone. This is a huge deal for watch app developers because it gives you an opportunity to store information for the initial state of a watch app's UI that can be available on the watch before the user opens the app the first time. Anything that can be serialized as NSData or a Plist can be stored in the context. This is almost certainly going to be the centerpiece of your communication strategy for native apps on watchOS 2. It's a very elegant way to implement a basic View Model for configuring the UI of your Apple Watch app.

Here's an example of how you might use the Application Context. Lets say you are building an audio control Apple Watch app that can play a list of tracks on your iPhone. You could store an array of tracks and the currently playing track index in the Application Context. Any time that data changes on the phone, you can update the Application Context. The next time your Apple Watch app loads, it will have the latest information available to update its UI. The Application Context is a very easy to use API to achieve this result.

WatchConnectivity also supports background file transfers. This API should be used for longer running transfer operations. If your audio player app requires the presence of large media files on the watch, then this API will likely be the best fit for you. It affords you a much higher degree of control over the order and timing of file transfers than other communication tools do.

Interactive Operations most closely model the message passing system in MMWormhole. These operations are meant to send information between apps while both are running in real time. This operation might make sense to use for updating a playback indicator on the watch for audio playing on the phone. If the user is looking at their watch while your app is running on both devices, this API will be a great tool for keeping the two experiences in sync with each other. While this method is capable of waking up your iPhone app in the background, your communication system shouldn't rely on this too heavily because of how that will affect power usage on the user's iPhone.

As you can see from our audio player app example, there are very specific use cases for each of the APIs introduced in WatchConnectivity that come into play for our native app on watchOS 2. You'll want to think through all of your scenarios for sharing data between your iPhone and Apple Watch app to decide which one makes the most sense for each situation in your app.


MMWormhole

Many initial Apple Watch apps were built using MMWormhole, and we want to make it as easy as possible for those apps to migrate to watchOS 2. We are creating a new subclass of MMWormhole called MMWormholeSession that uses the WatchConnectivity framework. This means that if you were using MMWormhole to share information between your Phone and Watch apps then you can swap in MMWormholeSession and gain basic support for the WatchConnectivity framework in your native Apple Watch app. 

The MMWormhole implementation of WatchConnectivity is based on the Application Context. The context provides a useful persistence mechanism for MMWormhole, as well as an opportunistic background syncing engine to make data available to your watch app before the next time it loads. The MMWormhole unique message identifier is used as the key for the application context, and the serialized data structure of the message is saved as its value. This way, you can pass messages to the wormhole without worrying about having an active connection between the phone and the watch. By the time the watch app activates in the future, the latest information will have been stored in the Application Context and will be available through MMWormhole's messageWithIdentifier API. This is a really nice feature for building more responsive native apps on watchOS 2. 

Another popular feature of MMWormhole is real time message passing between an app and its extensions. The real time messaging operation of WCSession is a perfect fit here. The MMWormholeSession subclass uses this API for both sending messages and triggering listener blocks when a new message is received.


Conclusion

So, was MMWormhole "sherlocked"? Not exactly. The existing version of MMWormhole will continue to be supported and will be a great tool for sharing information between apps and extensions running on iOS and OS X. If you already have an Apple Watch app and have considered building a Today Extension, MMWormhole will still be a key component for your extension's communication system.

The new MMWormholeSession will be a useful tool for developers migrating to native apps on watchOS 2, but it is not a replacement for the WatchConnectivity framework. For instance, MMWormholeSession won't be a wrapper for the WCSession file transfer API, or handle message reply blocks. It will help make it easier to support watchOS 2 today, but developers will want to learn the WatchConnectivity APIs in order to build the best experience possible for their native app on watchOS 2.

We're going to keep iterating on MMWormhole throughout the iOS 9 and watchOS 2 beta process.  If you have any feedback or want to help, check out the library on GitHub.

MMWormhole 1.2.0

WatchKit apps have been out in the wild for several weeks now and I'm excited to release the first major update to MMWormhole since the launch of the Apple Watch. MMWormhole has been a big part of building many apps for the Apple Watch. This 1.2.0 version should help the library mature alongside the practice of developing for the Apple Watch.

Most of the changes included in this version represent bug fixes and improvements from many community contributors. Chief among them were several fixes to issues resulting in multiple message notifications being sent to listeners for single messages. There is also a great troubleshooting feature to alert users of issues with their App Group configuration. Check out the release notes above for a full run down of what's new.

This release is also geared towards keeping MMWormhole current with the latest developments from Apple. There are improvements to using MMWormhole with Swift involving the nullability flags introduced in the latest updates to the Swift programming language. There are also improvements to support NSFileCoordinator which was fixed in iOS 8.2 to support coordinated file access between apps and extensions. Special thanks to Tom Harrington for pointing this out on his blog.

In order to support coordinated file access, the underlying architecture for MMWormhole was refactored to support a message passing protocol called MMWormholeTransiting. This protocol defines the means by which messages "transit" from one side of the wormhole to the other. The default implementations include straight up file access or optional coordinated file access. Additional subclasses could be created by the community to support features like NSUserDefaults message persistence, or queued message delivery.

I'm glad this mechanism now exists because it makes MMWormhole more extensible without adding any new complexity to the simple interface that has been so key to the library's approachability and ease of use. It also makes the library more future proof. If Apple ever implements a first party system for passing messages between apps and extensions, MMWormhole could likely support that system through a new implementation of the transiting protocol.

The community of people using MMWormhole has been incredibly supportive. If you have any feedback or thoughts and suggestions on ways the library can improve, or simply want to share how you're using it, feel free to share an issue, pull request, or blog post. If you'll be out at WWDC this year and want to chat about MMWormhole, come find me or one of the other engineers from Mutual Mobile

Running with Apple Watch

I never ran with anything on my wrist before, but the prospect of running with the Apple Watch was a major factor in me deciding to purchase one. I've been running with mine for a month now and it's been a fantastic experience thus far. The Apple Watch was designed with fitness in mind, and it certainly feels like a very useful fitness companion to me.

Runtime for Apple Watch

 

Remote Control for my Phone

I use my watch out on the trail primarily as a remote control. I realized early on that I was using both Overcast and the Now Playing glance far more than any other app except Runtime. I have always run with my iPhone for listening to music or podcasts. But my phone is never where it's easy to reach, making it impractical to adjust my music or podcast selection on the go. Controlling audio from the watch is much more convenient, which makes going for a run feel more fun.

Having a remote control for my phone is key, because for the last several months I've been running with my phone in a running belt. It's not really practical to look at your phone to check your stats when it's in a belt, so I just wasn't doing it. Some apps have settings to periodically read your stats to you over audio, but I've never liked that experience because it takes me out of the zone of listening to something or focusing on my run. Being able to quickly glance at my stats on the watch suits my running style far better. It's a huge part of how I use Apple Watch when I run.

 

Training with Apple Watch

As far as hardcore runners go, I am probably still on the more casual side, but I am trying to push myself to improve my long distance endurance. I've been focusing on maintaining my pace over the course of several miles. Recently I've built up to running 7+ miles at a 9 minute per mile pace. Before I started using Apple Watch on my runs, evaluating my data was a mostly post-run activity for me. Now I find myself checking my pace and split times every 5-10 minutes while I'm running to see how I'm doing. About half way through my run I switch from the stats screen in Runtime to the splits screen to gauge how my mile times are doing. It's been a fairly effective way to gauge my progress and keep myself honest on my longer runs. I wrote a previous article about Runtime for Apple Watch, and in practice I am really enjoying using it to train while running.

1425851786060.png

 

Apple Activity and Fitness

Of course, the Apple Watch is a very useful fitness companion even when not running. I keep the activity circles complication on my watch face, and I do generally try to fill it every day. Sometimes I take a day off after a long run the day before, but I like having a visual reminder to stay active. I'm not fanatical about filling the circles every day, so I wish I could configure my circles to act more like a weekly goal than a daily one. But for someone that has never used another fitness tracker, I feel like the Apple Watch is a very useful one.

I also experimented with using Apple's Fitness app to track my run, in addition to tracking it with Runtime. From my testing, the Fitness app felt very accurate. Distance and Pace were very close to what I was seeing with Runtime, which is using GPS to track your route. Of course, the Apple Watch also includes a heart rate monitor, so the Fitness app shows your current heart rate as well as those statistics.

Showing my heart rate is a nice feature for the Fitness app, but I've stopped using the Fitness app on my runs. Its interface for stats doesn't feel well optimized for the watch. I prefer the Runtime watch app that includes all of the stats I care about on a single screen. I don't like swiping between stats on the Fitness app. It feels redundant to track my run on both apps, especially since Runtime tracks my route via GPS and breaks out my pace into split times. Runtime also tracks elevation, which is something I'd like to see in the Fitness app.

 

My Apple Watch Setup

The key Apple Watch feature for making it a running companion is the Activate on Wrist Raise -> Return to Previous App setting. That means that either Runtime or Overcast remain in the foreground when I raise my wrist. This is critical to me so that I can check my distance with literally just a glance, or skip to a new podcast with a glance and a few taps. I usually launch both apps at the beginning of my run so that I can double tap the digital crown to switch between them. Between them I have everything that I need for my run.

I do occasionally get text message notifications when I am out for a run. I usually don't stop to read or reply to messages when I am out running, and would simply ignore them when my phone is in my running belt, but it is nice to glance at a notification and know immediately if I do actually need to stop to respond to a message. It's easy to glance at the notification without breaking stride, and in a few cases I've used a contextual reply to respond to a message, or let the person know that I'll message them back later.

Because I knew I'd be using it for running, I opted for the black sport Apple Watch with the black sport band. I'm glad I went with the lighter weight model, because I can barely feel it when I'm out running. I've also tried running with the milanese loop, and it's doable in a pinch, but I find the sport band to be better suited for exercise. I tend to wear the watch slightly tighter while running, and the sport band is more comfortable to wear tightly. I tend to wear the milanese loop a bit looser.

 

Conclusion

I've really enjoyed running with my Apple Watch. Even as just a remote control for my phone, it makes going for a run feel more enjoyable. But I think there's a lot of potential for it as a training tool, especially when it integrates more with other fitness accessories and developers have more access to the native sensors and taptic engine. And of course, when future models include GPS, then we'll really be off to the races. Running with Apple Watch is already great, but I am sure the best is yet to come.

Further Review: Running Belts for the iPhone 6 Plus

Immediately after getting my iPhone 6 Plus I started testing out several running belts to hold my phone while out running. I wrote a review about my experience using each of them and the response to that has been overwhelming. That blog post has become the most popular article on my site, and I think it's because people love running with their iPhones and are looking for a good way to carry them on the go.

Between the three belts I tried out, I had plenty to choose from for my workouts. But I decided to try out two others that have come on the market recently to see how they stacked up against the belts I was already using. Especially now that the Apple Watch has come out, running with a running belt has become a core part of my workout routine. Never have I considered switching back to arm bands for running. And while I look forward to the day that I can run with only my Apple Watch, I don't mind running with my phone in a running belt at all.

Note: The links below are Amazon Affiliate links. If you find this review useful and decide to purchase any of these belts, consider using the links below and you'll support this site.

 

Large Pocket SPIbelt

Large Pocket SPIbelt (Amazon) - Website

In my original review, I mentioned SPIbelt as a product worth considering but wasn't big enough to fit the iPhone 6 Plus. SPIbelt actually reached out to me later and let me know that they had released a larger version of the SPIbelt that does support the iPhone 6 Plus. They sent me one to try out that I've been using for several weeks now.

The Large Pocket SPIbelt is the most well made with the best materials of all the belts I've tested so far. The band, buckle, pocket and zipper are all high quality components. The design and branding are all very tasteful. The fit and feel is also very good. The band feels like just the right width and thickness. It's also easy to adjust and seems to keep it's adjustment well. 

The pocket itself is comfortable and plenty big enough to fit an iPhone 6 Plus, even with a case. I started using a case on my iPhone after it cracked falling out of my workout shorts pocket, ironically enough. The SPIbelt pocket is made of a stretchy material that expands to easily fit more than just a phone. I've run several times with my car key and an energy bar or gel pack in the belt along with my phone.

It's fairly easy to get your phone in and out out while wearing the SPIbelt. I attribute this to the stretchiness of the pocket, since you don't have to apply much pressure to fit it snugly into the pocket. The pocket just compresses to fit around the phone.

SPIBelt advertises it's product as not bouncing, which is important. The last thing you want is your phone bouncing around while you're running. In practice, I don't feel like the SPIbelt bounces up and down while I run, which is a good thing. This is most likely because the band and pocket are stretchy. If you tighten the belt to where it fits snugly, the elastic will already be tensioned around your waist, which prevents it from bouncing.

However, the stretchiness and size of the pocket creates a separate issue. I notice that my phone tends to shift position in the pocket fairly easily. The most comfortable resting position for your phone in the belt is parallel to the band and your waist line. Sometimes though, especially on longer runs, my phone will shift in the pocket to rest at an angle. This results in the corners of my phone sticking up and down, which tends to be uncomfortable while running. This could be solved by making the pocket slightly smaller to prevent the phone from moving around quite as much.

The SPIbelt does tend to be fairly comfortable to use at the Gym, mostly because of the relatively thin straps and smaller buckle that can be positioned off to the side depending on your preferred adjustment. The only issue I've had with it at the gym is wearing it while doing pushups. The pocket tends to flip over a little and can hit the ground below your body if you go low enough while doing a push up.

The Large Pocket SPIbelt has definitely earned a place in my running belt rotation. It's well made and comfortable and feels like it will last a long time. But there a few improvements that could be made to turn it into an even better product for my purposes.

 

Active Rhino Adjustable Running Belt (Amazon)

I picked up the Active Rhino belt recently after reading about it on Tools and Toys. It's named the "Adjustable" running belt on Amazon, and with good reason. The entire band is covered in velcro, making it simply and infinitely adjustable. Of all the belts I've tried, this one is the easiest to get the right fit.

The Active Rhino eschews the zippered pocket of many other belts, making it very similar to the FlipBelt (Amazon), which I tested in my original review and continue to use frequently. This design makes it very easy to slide your phone in and out through slots along the main section of the belt. The Active Rhino also includes a welcome addition to this design that the Flip Belt lacks, which is a tether hook to keep your keys from escaping if they pop out. I felt much more confident storing my car keys in this belt because of that feature.

The downside to the Active Rhino's reliance on velcro to create the band is that velcro tends to be itchy or scratchy if not perfectly adjusted or when worn beneath clothing. This was always something that bothered me about the running arm bands I used to use. I end up having to fidget with the band quite a bit to position the velcro where it isn't irritating while I run. This isn't an issue that I've had with any of the other belts I've tested.

Finally, the pocket of the Active Rhino isn't sown symmetrically on both sides. The seams are set at the top and bottom of the pocket, rather than in the center. You can see the seam running across the top of the belt in the image above. As a result, the seams themselves are also friction points that can be irritating while running. I think this is mostly caused by the difference in design between the two sides. On one side of the belt is the Active Rhino logo, and on the other are the slots to slide objects in and out. The fabric for the side with the logo sticks out slightly above the pocket, adding to the seam irritation issue.

While the seam and velcro imitation issues frustrate me while running, I still anticipate using this belt for going to the gym. The lack of a buckle, and a secure fit for both my phone and keys make this one a better gym companion than any of the other belts I've tested except maybe the FlipBelt.


Conclusion

Running with both a running belt and Apple Watch has been a great experience. The Apple Watch makes it easy to check my running stats on Runtime, and having several belts in my workout bag lets me cycle through them so that no single one ends up getting worn out.

So which belt do I use the most now? I've been using the SPIbelt quite a bit lately, but the FlipBelt has really become my go to favorite. After several months of running, the Tapp C belt has started to wear out, which is unfortunate. It would be easy to replace it, but the SPIbelt is a similar product with higher build quality. The Amphipod is still in the rotation, but tends to stay in my travel bag for when I need to work out away from Austin. It's a great travel companion because it's so small and light.

I hope this helps you choose the running belt that is right for you. I think we can anticipate Apple shipping an iPhone 6s Plus this year, which will make these running belts great running companions for us for at least another year.