As a mobile developer, I get asked my opinion on mobile web vs. rich app development quite often, and understandably so. For most mobile developers, this is one of the very first questions we face when we begin planning to build an application. And to be honest, there’s really no “correct” answer to the question. If I absolutely had to break it down to a couple distinct criteria, the decision would likely be based on the following:
- OS/Hardware-specific feature requirements
- Development budget
- Development timeline
- Target audience
Before I get too much further, I feel I ought to explain that a vast majority of my mobile development experience has been with Android, so you’ll likely find that most of my examples revolve around it. With that in mind, let’s carry on.
OS/Hardware-specific feature requirements
HTML5 and native mobile browsers are quickly getting to the point where the gap is quickly closing between what can be accomplished from inside a browser vs. what can be done from a native (rich) application. However, there is still one significant feature that separates the two in my opinion: push notifications.
I’m not very familiar with the push notification system for iOS, but I have implemented Cloud-to-Device Messaging (C2DM) for Android several times, and it is incredibly useful for server-to-device communication. You can use them to get a device to “call home,” start a process running on the device, or even deliver a short message. The only feature that comes close to this in HTML5 is the WebSocket. But if the user closes the browser, your channel of communication is severed.
Another reason why you might choose to build a rich app is because your requirements demand a long-running service that persists in the background. A background service may be needed for indefinite location tracking, device monitoring, or lengthy calculations/processes.
One of the features I like most about Android as a developer is the way intents were designed. Intents allow you to not only integrate other applications into your own, but also integrate your application into others. A good example of the prior scenario would be launching a thrid party barcode scanner application from within your own app and receiving a UPC code back. As far as the latter situation is concerned, many apps will allow you to “share” content with other apps, so it’s possible to get your app to appear in the list of possible choices (for instance “sharing” a place from within Google Maps). This unique interoperability is definitely a very strong case to build a native Android application over a web app.
Development budget and timeline
I doubt there are very many developers out there who’d disagree with me when I say that mobile web development is grossly cheaper than developing a native rich app. Granted, 95% of my development experience is web development, so it’s fair to say that it’s what I know best. However, the fact that you can develop once and automatically target every web-enabled platform is quite a powerful one. Compare this to developing, say, an Android, iPhone, and Blackberry app separately, and it’s easy to see the advantage here.
As far as development timeline is concerned, I don’t think I need to say much more. Obviously developing one web app is quicker than developing multiple rich apps, so let’s move along.
OK, I’ll admit it. I’m an Android fanboy. So when I first started doing mobile development, I completely neglected iOS and only focused on Android. No wait, let me try that again. I completely thumbed my nose at iOS and all my iOS-using friends. It didn’t take me long, however, to realize that if I was really serious about being a full-time mobile developer, I simply could not ignore one of the top two mobile OSs, no matter how much I disagreed with Apple’s philosophy or believed in Android’s success.
At first, my peers were pleased that they now had a way to use an app they had been begging me to port for months. But as soon as the novelty wore off, they quickly realized that the mobile web version just wasn’t quite as slick as a native rich app could be. Even though they could create a bookmark on their home screen to make it appear as a native app, the differences were still noticeable (namely the lack of push notifications, which I get around by sending emails).
Now I’ve presented a select few arguments on both sides of the case. Clearly there are a lot more factors that go into this decision, but I feel like the ones I’ve mentioned have been the biggest determining factors in my own personal choices. There really is no right or wrong answer at this point, and at the rate the mobile tech industry is evolving, everything I have just said may be moot tomorrow.
As things stand today, I feel that the best approach is to target both mobile web and rich apps if all your determining factors allow for it. But this is clearly a subject that will need consistent reevaluation as time progresses. Eric Schmidt himself has been quoted as saying “HTML5 is the way almost all applications will be built, including for phones” so I’m confident in saying this is a topic to keep your eye on.
On a final note, I encourage everyone reading this article to watch this video if the subject matter discussed piques your interest. It’s the Android vs HTML5 session from Google I/O and I discovered while writing this article that it was uploaded to Youtube, as it was not streamed live from Google I/O. Hopefully I have answered a few questions for you, and if not feel free to sound off in the comments!