Well, that didn’t take long. Some people, in a recent article by Reuters, are reporting their first impressions of the Apple Watch and, unsurprisingly, they are already complaining about the performance of the apps on the Apple Watch. As an engineer who started my career working on real-time embedded systems for industrial automation, I can tell you what a Herculean task it can be to get a tiny piece of hardware to run very sophisticated software on comparatively low specification central processing unit (CPU). All the while having it execute quickly to provide a responsive end-user experience. The tradeoffs between cost, CPU capability and speed, power drain, software functionality are nearly impossible to navigate and satisfy all of your goals. There’s the old product managers joke that you’ve got three options: cheap, fast, and good, but you can only have two.
For developers creating applications for the Apple Watch or creating extensions for the Apple Watch for existing applications these complaints show two things: You have to completely re-think the nature of an Apple Watch app user interface/user experience.
Secondly, you have to be laser focused on every aspect of your app that contributes to the performance of your app on the Apple Watch.
As a developer or application product manager, your mantra should be Fit for Purpose. Don’t try and port your entire app UI to the watch. Only put that portion of the UI on the watch that is explicitly required for a particular action. Let the phone does what it does well, and let the watch do only the micro interaction required for a part of the work-flow specific to using the watch.
Let’s look at another complaint from Nilay Patel of www.theverge.com who is quoted as saying, “There’s virtually nothing I can’t do faster with access to a laptop or a phone except perhaps check the time.” To show just how silly Patel’s comment is, let’s look at the fitness use case. This is an example of where I think the Apple Watch has the potential to make health and fitness tracking appeal to the general public rather than just the niche market of fitness enthusiasts.
Let’s consider the act of jogging, cycling, or even just walking. Now a lot of people already bring their phones with them when they exercise, and many of them even use specialised fitness apps like Strava, RunKeeper, MapMyFitness, MyFitnessPal, etc. to track their activity, share it with friends via social media or even just listen to music while they are doing their activity.
But the key thing is that once the activity is started, the phone is usually tucked away in a pocket, a cycling jersey, a fanny pack, or even an armband, and anyone who has tried knows that it’s a pain in the neck to take your phone out to interact with the app while you are doing the activity. Now, for a small niche of enthusiasts like myself one will also wear specialised fitness trackers from Garmin or Timex on our wrists so that we can see our data like pace, cadence, distance, elapsed exercise time, and power output.
But for the vast majority of the general public, they are not going to shell out another $300 for a single purpose fitness tracking wearable. With the Apple Watch, on the other hand, one can easily imagine a significant number of people who would be willing to spend that money for a multipurpose device that connects to the apps on the phone and lets them interact with them naturally while doing their activities.
There’s no way, for example, that I am going to pull out my very expensive iPhone (or even risk mounting on my handlebars) while I am bombing down Panoramic Highway on Mt. Tam at 40 mph on my bike in order to check my pace, but it would be quite simple for me to take a quick glance at my Apple Watch to see the data.
No matter how carefully you have thought through the scenarios, you still need to know exactly what your app is doing and all of the factors that are contributing to the performance of the app during development and production.
You need to understand how much data you are transferring and how long it’s taking. Now you could try and instrument the app yourself with a bunch of timers and variables on your method calls, but that would be a waste of your time as a developer when you should be focused on implementing the features your users want that make sense for the watch.
Fortunately, this is where AppDynamics has you covered. With AppDynamics Mobile Real User Monitoring, you can get detailed data about how every aspect of your app and the Watch Kit Extension are performing and track the interactions of the extension with the Apple Watch. Moreover, the AppDynamics Mobile RUM solution provides you with all of this information through a single portal where you can see how your users are distributed geographically, all the network requests and errors that are occurring, how long they are taking, how much data is being transferred, and you can dig down into any line of code and stack trace to see what’s happening in your app and how that is contributing to the end user experience.
The writer is senior technical marketing manager at AppDynamics, an application intelligence company