Hybrid vs Native Mobile app [closed]

Question

I need to create a mobile app for iOS and android (so 2 apps). The app will use some native mobile functionality, and lot of functionality is related to displaying static/ dynamic information. I am planning to move the information on web app and simply embed the web pages (HTML5) in the mobile apps (basically call the urls and display info).

Is this a common way of developing mobile apps? Or there can be issues with following hybrid approach? Are there advantages of native app over hybrid app (or vice versa)

Thanks Kamal

Answer 1

Its funny how often I get asked or speak about this specific question. Here is my basic feeling on the matter:

HTML 5, Hybrid HTML 5/Native and Native apps are all good, nearly comparable options, what to choose though is a different story.

Here are some reasons I might choose one of them, and since you guys are helping me understand the programming world, I'll throw in the way product (what i mainly do) thinks about the market positioning and business side of things.

HTML 5 technical reasoning: I need this application to run on nearly any device a user could have, this application will not tap into any proprietary or complex device functions (uploading photos, triggering push notifications...).

HTML 5 Product reasoning: HTML 5 can drastically lower the cost of development in two ways. (1) There is a larger talent pool (thus lower cost) competing for standard front end engineering projects like HTML 5 devs whereas iOS and Android developers command a serious premium and are hard to come by and (2) you only have to build it once and its much easier to maintain, qa and set up staging copies.

In addition, you don't have to deal with app stores taking part of your revenue. The classic example of this is what the Financial Times(FT) did recently. The FT makes its money off expensive subscriptions that most bankers are bought by their respective banks. As such, they have a loyal, captive and price insensitive audience, and their main stream of revenue is almost entirely from subscriptions. When they had their app on the Apple App store, they couldn't possibly justify giving away 30% of any new subscriber to Apple. They dropped off the app store, and built one of the most comprehensive and impressive webapps that feels very much like an app, works across nearly any java enabled phone and allows them to keep the money from subscribers. In the development community they have gotten lots of accolades for this site (you can check it out on your phone, I think its www.ft.com) and have increased their brand awareness by being innovators. Game, set, match.

The final huge benefit to HTML 5 only is that you don't need to deal with app stores. That means your hands aren't tied and you can also change things on the fly, allowing for more iteration and a better product forming much faster than having to submit to Apple and wait two weeks for every enhancement you want to make (this is somewhat mitigated in the Hybrid approach as well). Having managed the HTML 5 tablet site at ABC News, it was vital that we were able to fix things VERY fast in the news industry, making this approach perfect for that type of app.

Hybrid HTML 5/Native technical reasoning: I want this application to run on as many platforms as possible, but I will trade some of them in order to gain access to proprietary and complex device functions on a few popular ones. I'm also comfortable with the fact that the design may not always be pixel perfect and there is the potential for occasional sluggishness.

Hybrid HTML 5/Native product reasoning: If I have an app that needs to be on at least iOS/Android, isn't an experience that needs to be completely custom and needs to be an app in the app store, because frankly, advertisers get excited about buying apps, whereas mobile web is barely on their radar, the Hybrid approach would probably be my best candidate. Like HTML 5 only, its just much cheaper to build one mobile website, and then hire one native developer to build a quick app wrapper for you on iOS/Android/Windows whatever. In addition to this, all you need to do is tweak the HTML part, create a new instance, and you have a mobile website as a bonus!

One of the dangers here is if the HTML 5 isn't somewhat responsive or is locked into 320x480 and 1028x768, as different sized tablets come out you will have to make lots of instances of the site and detect for the useragent, which is time consuming and an upkeep nightmare. When this happens it usually just gets rebuilt as a responsive site, which it should have been in the first place.

Native technical reasoning: I want this application to run on one platform exactly the way I want it to, I need to gain access to proprietary and complex device functions. This application needs to perform very complex operations, uses lots of memory and is a very custom application with many custom UI controllers. (A few categories include: 3D gaming, heavy UGC apps like CNN iReport and many utilities)

Native Product Reasoning: Keep in mind, as a product person you deal with budgets and resources are almost always limited at best. When I say above that Native is only good for 3D gaming, I fully understand that you could use it for simpler apps as well, but its much more expensive, less scalable and when dealing with small budgets at a COMPANY it often doesn't make sense. If you're great at coding apps, then by all means go native on whatever you choose, which is your right because all it costs is your time. That said, here are my main reasons to use a Native app:

Native apps make more money. Lots more money. Whether you are a large publisher or a small dev slinging in-app purchases, Apple's ecosystem works for you in lots of ways. As a large publisher, an advertiser will jump at the chance to create the Coca Cola VH1 Music Awards app and pay for the development of it for you in most cases! If you tried to just offer them a few million impressions on a custom mobile website, they probably won't even respond (the Hybrid approach is often a clever bridge for this problem). As a small dev, Apple handles the payments for you, teaches all their users how easy it is for them to buy things in apps (this is where you come in and sell users 10,000 Valour points for $9.99) and yes, takes a cut for their trouble, but you have distribution and are set up to start getting checks with very little effort after releasing your product.

The app needs to be pixel perfection and animate like a dream. Maybe this is an app for a magazine and they won't tolerate any page lagging because they think the app is broken, and their designers will hound you to death over any pixels that are out of place. This can apply to most projects that are for premium brands that want to control every aspect of the users experience. This is not a bad thing, but its rarely seen done well.

The app needs to process lots of content from the user and deal with lots of proprietary CMS systems or the app is essentially some sort of platform.

The app is a custom experience that demands a lot of the phone's processor and needs to be hooked into the OS ecosystem to do its core functions, for instance, many utilities (think appkillers on android).

You don't care about mobile web or other platforms than the ones you are developing for. A percentage of your users may not be able to access your app and you are comfortable with that.

TL:DR All three are very useful and when you want to use them needs to be carefully thought through from a technical, product, business and design perspective.

Answer 2

I've mostly done native Android development, but I've also helped debug a few apps that were created using the "cross-compile" platforms such as PhoneGap and the cross-compiled apps have a few quirks that it's nice to just let the platform handle for you if you build a native app.

For example, one of the ones I debugged lately didn't implement handlers for back button events, which was a really uncomfortable user experience. In a native Android app, and I assume it is the same for iOS although I've never tried building for iOs, the system handles back button presses for you, because it knows what Activity was running before the current one and can rebuild it's UI. In PhoneGap, it's essentially a webkit browser wrapped in an Android application, so it doesn't have access to things like the backstack.

If you keep in mind that the system isn't going to handle those kinds of events for you, and you don't need access to all the sensors on the phone, then you could probably get away with using one of these frameworks