Building Mobile Apps that Pair with Other Devices

The huge majority of mobile apps live in their own bubble; they don’t interact with any other devices. Sure, some apps connect to other phones, but these mostly go through cloud-based systems, not directly connecting to other phones nearby (with notable exceptions, like FireChat http://www.opengarden.com/about.html.

There is a new class of apps becoming mainstream. These apps are paired with a physical device you can buy separately. For example, FitBit and Nest are two products with apps. FitBit (fitbit.com) is an activity tracker you wear on your wrist to track steps and other activities. The bracelet pairs with an app that allows you to visualize your activity and progress over time (this kind of device plays into the concept of the quantified self, the interest in knowing more about your habits and activities). The Nest takes this concept to your home, providing you with data and control over the temperature of your house. The Nest app allows you to set your house temperature from work, and to be notified when the fire alarm goes off. I assume the long-term vision of the Nest line of products is true home automation, with the thermostat just the first step.

This kind of app+device pairing is very powerful, but also challenging.

Opportunities

Do something completely new

The main opportunity provided with this approach is to build something completely new, something that does not exist in the market, something that solves a problem in a way that wasn’t possible before. For example, a huge fear of new parents is leaving their kid in the car. An example product would be to build a car seat sensor that detects if your child is sitting in the seat (your passenger seat probably already does this, with that annoying reminder for your passenger to put on their seat belt). Whenever you walk away from your car, your phone would check if the car seat sensor is active. If so, you get huge alarms for you to immediately go back.

Your product could have a fixed location

Another potential benefit of this approach is that the physical product could have a fixed location. For example, the Nest is attached to the wall in your house. This means that it could be hardwired, providing constant power (no batteries). It also means the product can have simplification assumptions because it won’t be moving. A big challenge with mobile apps is that you never really know where a user is: on the bus, on their couch, at their desk, driving. All of these situations demand different kinds of interactions, and building all those different states is a challenge that is removed when the product doesn’t move.

Second income stream from the hardware

Monetizing an app can be a challenge, so selling a hardware component could be a great second income stream. This could be paired with a subscription system in the app, if your hardware can live on its own. For example, the Nest can be a standalone product without the app. For Nest, the app is really a value add that helps push this product into another market. Note that if your app is free, then you will only make one-time purchase income from the sale of the product, and then you will need to support that product for years without any additional income. This does work for some products, but a combination of product sale + subscription is an ideal situation, where you can make a larger upfront sale and a smaller long-term income stream.

Challenges

The opportunities are endless for this kind of hardware + app product, but there are some challenges you should be aware of.

Custom or integration?

This is the main question to ask yourself: will I build my own hardware, or integrate with existing hardware? Some products allow other software systems to integrate with them. FitBit does provide this ability, though it is a bit limiting, so if you want to do something that FitBit doesn’t directly support, this approach may not be possible. Another issue with integrating with an existing product is that it can change randomly, often without warning. If FitBit decided one day to stop supporting integration, your app would be left hanging.

Of course if you build your own hardware, you can do whatever you want with it (within legal and moral boundaries). The stumbling block here is almost always cost. Building custom hardware can be extremely expensive (the tooling alone can be several hundred thousand dollars), let alone the costs of materials, production, storage, and shipping. It can be a gamble, but with a solid product that you control, you can achieve something that no one else can.

Upgrading hardware

With software, it is relatively simple to roll out an update. Want to add that cool new feature? Push it out to the app store, and all of your users can automatically get the new feature. When you have physical hardware out in the world, this can be a much bigger challenge. Want to add a new feature so your child seat alert system will also sound an alarm in the car itself, in addition to on your phone? That’s not something you can just push out to the app store, since your child seat doesn’t have a speaker in it. When you build your own hardware, be sure to plan out the next few years in case you need to change something about the hardware to support this. Keep in mind that adding pieces to your hardware will increase the cost, so unless you are 100% sure you will want this in the future, it is safer to not include it now, and to sell a version 2 of the product that people will need to purchase to get the new feature.

The real world is messy

Having hardware out in the physical world makes the design of the app difficult, because you have no control over the physical world. The product may be in a concrete basement, blocking the wireless signals you need to communicate to it. People may put it outside, in the rain and freezing temperatures, draining the product’s batteries. At a high level, designing an app means that you only need to worry about the user and the phone. When you add this hardware component, you have to worry about how users interact with the physical hardware, as well as how the hardware will interact with the phone. There are so many variations of phones out there, especially on Android, that it is really hard to predict how those phones’ hardware will interact with your custom hardware.

Conclusion

Products that combine apps with physical devices provide opportunities to create solutions to problems that were not possible before. These can be incredibly powerful, and can provide huge profits for your company, but there some hurdles you need to be aware of, often around the cost of developing hardware.

Andre is the Product Director at Push with a PhD in Human Computer Interaction. Andre believes that thoughtful design can simplify people's lives, and strives to make all of Push's products easy to learn and use, while providing compelling, useful, and joyful experiences.

One response to “Building Mobile Apps that Pair with Other Devices”

  1. Cuzee says:

    like the idea….I appreciate you share it.

Leave a Reply

Your email address will not be published. Required fields are marked *