So you’re back for more after part 1? Great.
Firstly, some admin. Much like making an app, this series is going off project scope: the planned two parts have become three. Also, I didn’t have space to delve deeper into the last post as asked. That will happen in part three.
In this post, I’ll focus on how the native/web app decision affects product development and business model. Then I explain a hybrid native-web app option. Read on.
FYI: I assume you are developing your product iteratively with feedback from user testing. If that’s not true then the next part doesn’t apply to you (and good luck – you are hopefully some kind of user/customer scryer).
The great advantage of a web app in product development is speed. Updates are simply pushed to a central server. They can be seen instantly on any device. User feedback (and measuring through analytics) can begin. What’s more, because a web app lives on the server (and not on your device), you can guarantee that all your users are using the same version. You see the effect of changes on all your users immediately. Great news, unless you’ve created a bug.
Native apps, however, are more cumbersome. Updates need to:
- get through the relevant app store approval process
- become known to your users
- be downloaded by your users
You have to wait for all that before you can get user feedback. Indeed, even before you release to the app store, a native app is not as simple to share with others, especially those outside your project team. (Although longer-term it’s worth adding that native apps do have app store customer reviews, web apps don’t.)
How much is a native app? I guarantee you my answer is within £/€/$1 of yours. App prices are more standard than shoe prices. They are a known quantity that can be planned for. What’s more, app stores already have customers’ credit card details. Customers go to app stores expecting to spend money. These days, even in-app purchases and freemium models are understood and accepted by most.
How much is a web app? And is it a once-off purchase or a monthly subscription? And why would someone give up their credit card details to a website they happened upon via Google? Pricing web apps is more complex. Although this means there is more scope to experiment, and, as there is no mental ceiling (‘you paid $5 for an iPhone app?!?!), users may be willing to pay more once convinced. (And, unlike a native app, you won’t have to forfeit 30% of your revenue to an app store.)
How to pretend your web app is a native app
The best of both worlds? Well, not exactly but there are clear benefits.
Hi, I’m PhoneGap. I’m like a UN interpreter. I’m a C2 in web Esperanto (aka HTML5) and the language of pretty much any other phone you care to name.
OK I’m stretching the metaphor, but you can use something called PhoneGap (check out the video) to make your web app seem native.
A PhoneGap app is developed like a web app: one* set of code, written in web Esperanto, and interpreted by PhoneGap for each different mobile platform.
- access to the camera, microphone, calendar, and other native device features
- no need for a new set of skills to develop for each type of phone (you can use the same developers)
- changes can be made in one* place (you don’t need a different set of code for your native iPhone app and your Android app)
- You get instant updates, just like a web app
Also, customers find you via an app store (discussed above).
As it is not really a native app, there are some issues:
- Load time is higher because the app is not stored on the device
- It won’t be as responsive as a native app (remember you’re speaking through an interpreter)
So a web app probably takes the prize on product development, but is a more risky proposition on business model. You can try to get the best of both worlds with PhoneGap but there are still compromises.
In the next post, I’ll sum up the story so far. Then, I’ll add a few technical layers for those who’d like to see under the hood. As always, leave your thoughts below.
* Sadly, it’s not that simple.