AILW: Thinking about Load Time

watchOS series

One of the loudest complaints I’ve heard since the launch of the Apple Watch is the delays you can experience while launching 3rd Party apps. These can experience widely differing waits, sometimes a few seconds, sometimes upwards of a minute.

There is a certain amount of non-determinism that is inherent in the way WatchKit is structured. Any time your UI is split from your controllers via a wireless connection weird things can happen. This variability in launch times is probably just something we’ll have to deal with until we get native apps. But what can we do now?

I did a series of experiments this morning to see if there were any structural differences in the way a WatchKit app is designed that make a difference on how quickly it launches. My initial (incorrect) hypothesis was that having an app structured with pages, tables or getting data from your parent app would have a major impact on launch time. It turns out that the reality is far simpler.

Here are the results of my initial testing. I built a variety of test apps and launched them all on the watch (force quitting them between launches). I then found the median launch time for each build and laid them out side by side. I made (clockwise from top left):

  • Blank - Any empty app with no data or UI.
  • Paged - An app with three pages of Interface Controllers
  • Table - Loads a 10 row table
  • Core Data - Uses openParent to retrieve a value from the parent app’s Core Data stack.
  • Parent - Uses openParent to retrieve a value from the parent app

As you can see, the load time across each of these various configurations is nearly identical.

What this tells me is that the area I need to focus on for improving the launch time of my apps is entirely the speed at which I can get the data that drives my app loaded and sent over to the watch. The physical layout and structure of what I build matters far less.

I’ve settled on an overall structure for my apps where the watch extension does essentially all of its work from caches primed by the main app. Similar to what I outlined back in December. Taking this approach means that I can minimize any waiting that is my fault during launch. My apps still sometimes have the odd long launch time but I’m increasingly convinced this isn’t something fixable until we get the native SDK.

David Smith