Software Engineer & Architect

Key Considerations for Building Wearable Apps

I have recently developed an Android Wear app that uses sensors within a smartwatch to detect and display metrics specific to a sport such as: acceleration, active time, stroke count etc., in real-time. I would like to share lessons learned from my experience developing a wearable app and, considerations to be cognizant of – if you are considering or are in the process of building a wearable app.

As an application’s functionality and use cases can vary drastically from one app to another. Lets use the following context to set a level playing field.

A wearable app that leverages sensors and displays real-time information such as: step count, speed etc., and has an optional phone companion app that displays historic activity information, which might require a authentication mechanism to be able to persistent such data in the cloud.

Wearable ecosystem and wide range of choices available for users

When making a purchase decision with respect to wearable devices, users tend to care about aspects such as: personalization, compatibility with their existing smartphone(s), style, design and ease of use. And, as expected – not much emphasis may be placed on underlying technological criteria such as: the Operating System running on a wearable and whether or not a wearable would work (in full compatibility) and can be paired with a smartphone from a different ecosystem such as: Android versus Apple.

A simple example to illustrate the same from a user’s perspective is: a step counter app. A wide range of wearables from Fitbit to Apple Watch can track steps and in some shape or form display this data on a paired smartphone. Users may or may not know that vendors such as: Fitbit, Samsung, Apple Watch, Google: Wear OS are using application architectures that are not necessarily portable from one platform to another.

This puts developers, especially, individual developers in a difficult spot in having to decide which of these mainstream vendors to support in terms of application development and, whether or not replicating a app across multiple platforms would yield effective results; not to mention any design changes or bug fixes to be replicated n number of times across such platforms.

Sensors – availability, specifications and accuracy

With the above mentioned application context, an application developer would have to account not only for consistency in sensor specifications across devices but also, availability of specific sensors on a device and the accuracy of sensor data provided in real-time. For instance, Android returns sensor accuracy status as low, medium or high which can be helpful to skip or disregard data of low accuracy.

With respective to sensor availability, it can be worthwhile to make note of sensors that are hardware based versus software based. And, set the appropriate delay in obtaining sensor data.

In my experience developing a Wear OS app that requires real-time sensor data, as there way a slight delay in obtaining sensor data with watches such as: LG Style or Huawei watch, I had to set SENSOR_DELAY_FASTEST for accurately tracking and processing real-time data. Refer to the sensors overview Android documentation and helpful methods such as: getMinDelay to identify during app initialization if sensor(s) meet your meet your app’s minimum requirements (precision, availability and accuracy). If you’re interested in viewing raw sensor data from a Wear OS device, SensorDashboard does a great job of displaying such data on a paired smartphone.

Standalone Wear apps

While this section is specific to Google / Wear OS, the context can apply to other App stores (Samsung, Fitbit etc.,) as well.

In order to a Wear OS app to be listed and distributed via the Play Store app within a wearable device powered by Google: Wear OS, note that a developer would need to opt-in to Wear OS and publish. Google would then review such Wear apps for quality and approve or reject an app release.

In my experience, the app review process was frustrating in that – no specific information was provided as to why a specific app release was rejected. Considering a wear app that depends on sensors for app’s functionality, there is only some many physical smartwatches a developer can test on, to find any specific issues in a vendor’s wearable device. If you’re submitting an app for Google’s review, for any rejections – my suggestion would be to reply via email or reach out via Android Developer’s documentation support form and request specific feedback.

From a user’s perspective, it can be a pain point that standalone wear apps can’t be installed via a linked Android phone. Two options to install standalone Wear apps on a device powered by Wear OS are via: Play Store app on the watch itself or via Play Store website on a Mac or PC but not, a linked smartphone. Considering these installation limitations for standalone wear apps, my recommendation would be to ship a standalone wear app along with an optional phone companion – allowing users to either install the phone companion and guiding them to install the wear app as well or providing the option of directly installing a wear app via smartwatch without the optional phone companion. Here is a sample codebase on how to detect a paired phone from a smartwatch and vice-versa.

Another caveat with standalone wear apps is that the search results for Play Store on Android wear devices are very limited. This can vary based on the search query but, from a user’s perspective it may not be appealing to have to revise voice searches or use a text/keyboard on a smartwatch with very limited screen space to install a specific app. Not to mention, retrieval of results relies on a bluetooth connection to a paired phone, if wifi isn’t available on the go.

Hopefully, the above considerations would be helpful in developing your next wear app and making the necessary tradeoffs on which Wear device and app vendors to support. Feel free to comment below on any other criteria that can be useful in developing wear apps.