Mobile Health App Platform Choices

Has everybody heard of Basis? It’s an advanced wrist-worn monitor. In addition to tracking activity like steps, it also can monitor heart rate, body temperature, and perspiration. It tries to tie this all together to motivate people to establish healthy habits. Incremental and consistent small changes are powerful for wellness. Basis tries to help people make those small changes.

At $199, Basis is a product geared towards people who are motivated to get — or more likely stay — healthy. It’s also geared towards people with the means to buy a $200 activity tracker. With that in mind, I was shocked when Basis announced that its first mobile app would be native Android and not iPhone.

It’s surprising because it goes against the grain and, to me at least, the accepted rule of building higher-end consumer apps and services, either inside or outside of health. Going Android first is not how lots of consumer companies tackle mobile. Many companies start with iOS and then move to Android. It’s not that iOS has more market share than Android, but it does have more of the higher-end consumers, the consumers that are worth more to an advertiser and more likely to buy a personal activity tracker.

Developers also have better examples of exits (Instagram, Mailbox) from building on iOS only, or at least primarily, and this is part of the decision to build on iOS first. As companies like Nike openly admit they are not working on Android, at least for certain apps, Basis decided to launch first on Android. According to Basis, the iOS version of the app is currently being tested and will launch soon.

It’s just really interesting to me. It’s also interesting that the launch of the app was behind schedule and the reasons given was, "Our engineers wanted to ensure that Bluetooth syncing worked well across all our supported handsets." That’s shocking since the app only currently supports six Android devices, all of them from Samsung.

For activity tracking, mobile apps have to be a priority regardless of the mobile platform. It’s a lot easier to track yourself throughout the day using your phone. I never log in to the Nike website to look at current or historical stats on my activity. I only ever use the app, which thankfully has improved over the last year and works well now. In a way I’m surprised any activity tracking companies would launch today without a mobile app.

This post wasn’t supposed to be about Basis, but its Android-first news brings up the issue of where to focus development resources and what mobile platforms to target. I wrote in 2011 about the different platform choices for mobile app developers to highlight the importance of a mobile presence, based on the rapidly growing numbers around smartphone adoption and usage.

Those mobile trends from 2011 have continued. The slideshow below has nothing specifically to do with health or activity tracking, but it’s a fantastic picture of why mobile matters and why it has to be a part of any digital strategy today. My favorite part about the slideshow is that it talks about mobile as more than just a new screen size. It talks about how people interact and use mobile differently than desktop.

These are important lessons in health, as we’re not just porting desktop solutions. We have new opportunities with mobile devices that don’t exist on the desktop. Please go through the slides if you have a few minutes — it’s worth it.

What hasn’t changed since 2011 is the developer choices when it comes to mobile platforms is the platforms themselves. The main options are iOS and Android or HTML5 and something like PhoneGap and Kony as a wrapper. The main difference is that there are certainly many more tablet users today than in 2011.

This is a subject that’s near and dear to me at the moment. We’re in various stages of development on a bunch of prototype apps, several of which we intend to open source and several of which are for waiting customers and we won’t open source. My thinking about the mobile platform of choice — when we’re making the decision ourselves or providing input to other decision makers — comes down two main factors: target users and talent.

When it comes to target users in healthcare, I typically think of providers and patients / consumers as the main buckets. If I’m building something for providers, I lean towards native and I lean towards iOS, though this preference is much weaker than it was a few years ago. The reasons why I like native iOS is that 1) performance is typically slightly better than HTML5 (it’s really, really minor); 2) providers can be demanding; and 3) the proportion of iOS vs Android is reversed with providers compared to the general population (iOS adoption with docs is ~60 percent of smartphones, not to mention the huge number of iPads).

If the app is for true patients, I lean towards PhoneGap or native Android, usually PhoneGap. I think minor performance issues aren’t as relevant to this group. Again, these are really minor differences. If it’s for consumers or for quantified-selfers, I lean towards PhoneGap or native iOS.

PhoneGap is great because it enables you to take apps written in HTML5 and convert them, or wrap them, as native apps that can be distributed in app stores and marketplaces. PhoneGap also gives you easy ways to connect HTML5 apps to smartphone hardware like cameras and accelerometers.

Apps created with PhoneGap typically have very minor performance differences, differences that I think the majority of users would never notice. HealthTap is a great example of a PhoneGap app that works really, really well. It’s built for consumer users so design and UI are pretty important.

The really great thing about PhoneGap is supporting lots of different devices with the same code base. You write the app and then wrap it with PhoneGap for Android or iOS or a few other platform options. There are alternatives to PhoneGap, but PhoneGap is the one in which I’m most familiar. The other bonus of PhoneGap is that we’re starting to see prototyping tools like Codiqa that are getting us a lot closer to drag and drop app development.

Ideally talent wouldn’t really fit into the equation at all, but the problem is that talent directly correlates to cost and timelines. It’s a factor that can be overcome with enough resources, or enough flexibility in terms of time, but it’s still factor. We have two phenomenal iOS developers and one pretty good Android developer. Our iOS guys can both do Android, but it takes longer. Right now I wish we had an HTML5/PhoneGap developer (we contract PhoneGap work right now), or two or three of them. We’re moving one of our iOS developers to PhoneGap for some sample projects right now.

As I’m writing this, I realize there’s no real great methodology that I use for deciding on platform. Obviously customers can choose, but many times they defer to us. I’d love to hear how readers approach these decisions. How do you prioritize mobile platforms?

Travis Good is an MD/MBA involved with health IT startups. More about me.

↑ Back to top

Founding Sponsors

Platinum Sponsors