Having developed a more complex app for the Apple Watch, I’ve picked up a few recommendations for how to best be effective while developing, and especially testing on the Watch.

  • While debugging, always keep the watch on the charger – Unless you require the heart-rate sensor or similar, the debugger is so much more responsive when the Watch is connected to charger. Save your sanity by keeping it there.

  • Always test on device – This is obvious if you have worked on an iPhone app, but it’s very relevant for the Watch also. The frameworks that are available on the Watch is also different from what is available for the iPhone (for example, JSContext is not available if you would like to run any scripts on the Watch). Make sure to try it out on the device so you know the code you run works.

  • Order of calls to the UI matters – When you update the UI on the Watch. The order in which you call setHidden etc. is relevant. If you have two views that are exclusive (should never appear at the same time).

      view2.setHidden(false)
  view1.setHidden(true)

    is not equivalent to:

      view1.setHidden(true)
  view2.setHidden(false)

    The first on will cause a flash in the UI where both views are visible at the same time, while the second will not.

  • No backgrounding – I made a Workout app, and even if you can use HKWorkoutSession to get restore-on-wake behavior (will open the app again when you wake the Watch, not the watch face), you will not get the opportunity to run any code at all. If you want it to appear like you can, you need to save the timestamp you went to the bacground, and calculate the new state from that timestamp. You can’t rely on background timers / notifications like on the phone.

  • Use a modal dialog to present errors – A very common pattern in an app is to show a global message in case of a failure (no bluetooth, no data entered on phone). Some people recommend doing this by having a top-level Group in your initial view containing a label. A better idea is to have a special view with that label. Why? Because then you can set the title to Retry, or add a simple retry button. This will trigger willActivate in your view controller again for the view that failed in a very natural way.

  • You can’t use the debugger to test no-phone behavior – This is a major shortcoming of Xcode in my opinion. It seems to be impossible to use the debugger to see what happens on the Watch when it is not connected to the phone. This means you have to rely on NSLog statements to keep track of the app behavior in those situations. Be very careful!

In general though, it can be said the Watch is a nice platform to develop for because of how simple it is. There is very little you need to do to for the most part because it forces you to make simple apps due to the inherit constraints.

My new workout Watch app should be finished very soon and released on the App Store.