Investing in an app over just using a mobile-optimized website can be expensive, but there are three reasons to consider going with an app and a couple of ways you can do so while cutting costs.
Last month we talked about the importance of mobile-optimized websites and the challenge of ISI display on small screens. This month’s question: To app or not to app?
Dear Dr. Mobile,
Your column last month was right on the money. We invested in a mobile-optimized version of our site and have seen it make a big difference to the amount of time and number of clicks from smartphone users. Some of my colleagues think we’re ready to take the next step and build a mobile app, but I’m not so convinced. Can we do a branded app without violating any regulations? Does an unbranded app even make sense? Help Dr. Mobile!
I’m always glad to hear that marketers have gone down the web path before they start eyeing up the shiny app stores. Yes, there’s immense appeal to being part of the app revolution and, yes, there’s an app for everything else, so why not? Because it’s expensive, especially across platforms, and most apps don’t get enough use to justify that expense. The Consumer Health Information Corporation found that 26% of apps were only used once and 74% were discontinued by the tenth use. What’s a poor marketer to do? Fear not. The answer is quite literally at hand.
Let’s start off with some definitions for those of you unclear on the difference between, say, a native app and a mobile-optimized site. Native apps are generally written in a software language that’s “native” to the platform: Java on Android and Objective-C on iOS. Because Android and iOS use different languages and require developers to take different approaches, an app written for one cannot be used on the other (much like Windows software won’t work on a Mac).
Okay, so what does that mean to you? Let me break it down:
- Apps are expensive to build, especially if you want to run on Android and iOS.
- Most apps will remain buried in the various app stores unless you’re willing to mount a marketing campaign behind them.
- Apps that do get downloaded are lucky to get used once and will probably get deleted before they get reused.
Generally speaking, it’s not a pretty picture. That said, there are an equal number of good reasons to go the app route and it’s often absolutely the right decision. Let’s take a look at what those might be.
1. Smartphones are jam-packed with useful sensors.
You can, for example, use the motion sensing to measure walking speed or agility. GPS can provide location data to understand environmental triggers. Bluetooth can communicate with other devices in order to collect their data for storage or transmission. Most of those sensors are unavailable through the web browser, which means even the most sophisticated mobile-optimized websites and web apps can’t make use of them, so all of your clever, ambient data gathering apps are going to have to be native.
Native apps run way faster than their HTML5 cousins, largely because their code has been heavily optimized for that specific platform rather than written in a generic, cross-platform language that needs to be interpreted first. This is especially true if you want to do things that take more processing power, including 3D animation, complex user interfaces with lots of moving parts, etc.
3. App store distribution is not as bad as you think.
In app stores these days the signal-to-noise ratio is poor (there are about 750 new apps added to Apple’s store every day) and each category has become crowded with copy-cat apps (there are about 5,500 apps in the U.S. iTunes App Store’s Medical category alone). That may not fill you with optimism, but consider that there are 650 million websites out there and the odds of getting discovered start looking pretty rosy. Now, consider that patients and specialists in your disease state are probably searching for something quite specific. A search for “rheumatoid arthritis” in the U.S. iTunes App Store, for example, turned up 18 iPhone apps, while “diabetes” found about 450. Also, keep in mind that market share stats can be deceiving. Although Android phones make up about 50% of the smartphone market, Apple’s app store revenue continually outranks Google’s—grossing nearly four times as much in 2011 (see above graphs). This indicates a much stronger app culture among iOS users, which is why we often recommend coming out with an iOS version first, getting it right, and then porting to Android.
As for the MRL side of apps, you can’t control the comments and reviews that appear on your app’s page in most app stores. Anyone with an ID can post a review and say anything they’d like, with no possibility for moderation and very limited capacity for removing them after the fact (essentially limited to offensive language). Your MRL team may not find this to be a problem as your complete lack of control may alleviate your responsibility for the content.
The above question also asked about branded vs. unbranded apps. Unbranded will be easier to get through MRL approvals and require much less screen-occupying safety information, but the ROI on your unbranded app will be as questionable as the ROI on your unbranded website. It can absolutely work, and there’s lots of evidence to back that up—especially for market leaders—so if you believe it’s the right choice for your brand then go for it.
Some apps may find themselves afoul of the FDA’s 510(k) requirements for diagnostic devices, especially if there’s a chance that an HCP may use the device’s output (sensor data or on-screen display) for diagnostic purposes. There is precedent for them granting 510(k) status to apps—Mobile MIM was granted it in February 2011 for displaying images from various scanners to radiologists—but the process can be long and arduous.
So, to wrap it all up: mobile apps are a lot of work but can be well worth it. There are ways to build great apps that are more cost-effective, especially if you’re going cross-platform. Everything we do is subject to regulations, and apps are no different, so involve your MRL team early and often.