5 Apple Watch Design Patterns to Avoid

In my next installment on @thinkapps I talk about 5 Apple Watch Design Patterns to Avoid.

Since first announcing the Apple Watch last fall, Apple has been trying to prepare its developer community for the launch, providing early access to the WatchKit SDK in order to inspire well-thought-out apps for the wrist device. 


Despite these efforts, it can be said that most of the third-party apps currently available have shown to be quite lackluster, slow, and cumbersome. 

Some say this is because, in one of the most protracted releases in Apple’s history, developers lacked a real-life device on which to test, having to rely solely on a simulator to try out their app ideas. 

Others attribute the lackluster third-party apps to the fact that this is a new platform and UX paradigm, and it will take some time for developers to start building best-practices knowledge. 

Most likely, it is a combination of both. 

In response, we present the 5 Apple Watch Design Patterns to Avoid in order to provide the best UX experience possible, at least with the current version of the Watch. (You can check out our Wish List for Apple Watch 2.0 here.)

Here are the top 5 things NOT to do when it comes to Apple Watch design … 

1. Making Apple Watch Apps the Focus

Say what? Well, as crazy as this sounds, the best Apple Watch apps that we’ve seen aren’t ones that are the spotlight but instead act as a great wingman to your iOS app.

Badly-designed apps require a lot of reliance on the iPhone for dynamic data, a heavy dependency that slows down the experience. Take the Twitter app, for example. It takes some time to load up so you can browse your tweets, but the wait is far too long with a use case that isn’t that strong. 

On the other hand, receiving tweet messages is passive rather than active, and, instead of you waiting for something to load up, it sends you a Glance notification and you can then peek at your wrist. There’s a fundamental UX difference here.

2. Dynamically-Generated Images 

This is something Apple explicitly asks developers not to do and flows from the previous design pattern to avoid.

The choice of dynamic or static images alters the speed of the user experience significantly, due to the dependency Apple Watch has on the iPhone for passing dynamic content. 

Static images are images that have been pre-loaded onto the Watch app at design-time and thus are accessible directly on the device, whereas dynamic images are accessed at run-time through the phone app.

If the app does require dynamic images, ensure the images are cached, using addCacheImage. This approach will speed up the app a little bit, especially if those images may persist for a while. Also, be sure to provide static images as placeholders while the dynamic images are loading.

(For more advice on incorporating images and animations without slowing down your Apple Watch app, check out our case study on Clover Clover.)

To find out what are the other 3 patterns to avoid, check out the remainder of my article @ThinkApps.