mHealth App Development Options – 11/28/11

Everybody wants to have a mobile presence these days. With smart phone usage on the rise and close to 40% of US residents owning a smart phone today or likely to buy one in the next year, providing access to services over mobile is crucial. Developers and organizations have choices in mobile app development. They can go native or use a mobile web app built on HTML5, which is getting tons of press for being the future of mobile development.

A native app is simply that — an app written exclusively for a specific mobile platform. If the device is iOS, it’s written in Objective-C and if it’s Android, Java. Web apps are developed using HTML5, JavaScript, and CSS. Web apps are not listed in the app stores or app marketplaces, but users can add icons for them to mobile screens fairly easily.

Native apps provide full access to the features of the phone (GPS, camera, etc.), offer the best performance and experience, and provide a presence in the app store. However, in  the case of native iOS development, technical resources are harder to find and the cost is greater. The other major problem with native apps is that they need to be written specifically for individual platforms.

Web apps have limited access to the features of the phone and have relatively worse performance than native apps. One major performance issue is that web apps are dependent on network speed, so the experience can be frustrating if network performance is bad. A recently published story on HTML5 presents some of the hard truths of HTML5 web apps, several of which are applicable to mobile health.

Since web apps run in a browser, their major benefit is the ability to deploy the same web app across different types of devices without rewriting any code. Web apps are also dynamic, so new content and features can easily be deployed without approval from an app store or user-driven upgrades. The other big benefit of web apps is that the skill set required to build them is in greater supply, so the cost is less and the timeline is usually shorter.

For mHealth development decisions, it comes down to the purpose of the app and intended audience. In my view, if building anything for clinicians (EMRs, DSS, charge capture, PM, etc.), it had better be snappy, with minimal lag between touch and response. For this audience, where adoption has always been an issue (though Apple devices seem to garner more forgiveness), building native apps is the way to go. Another major limiting factor of web apps for clinicians — at least for those that require data collection — is synchronization (Hard Truth #4 from the above story).

In building apps for consumer end users, native apps are still superior, in my view. Unless you’ve got a name like WebMD, a presence in the app store is a requirement to acquire users. Additionally, as everyone seems to be pointing out, user experience is extremely important, especially in consumer health where the level of motivation is not as high. Slightly slower data entry or access to health-related information might not be forgiven.

For hospitals creating a facility app, the user experience isn’t as important and the goal isn’t necessarily repeated use. Building one app that can be accessed today by ~40% of phone users, as opposed to an iPhone app that can be used by 10% of phone users makes a lot of sense.

Hybrid models between web app and native app exist. Kony enables the reuse of a single code base for distribution as native apps to an incredibly large number of mobile platforms. Open source PhoneGap allows you to wrap a web app as a native app to be distributed in the app store to iOS, Android, RIM, WebOS, Symbian, Windows Phone 7, and Bada.

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

↑ Back to top

Founding Sponsors

Platinum Sponsors