“Mike Lazaridis was at home on his treadmill and watching television when he first saw the Apple iPhone in early 2007. There were a few things he didn’t understand about the product. So, that summer, he pried one open to look inside and was shocked. It was like Apple had stuffed a Mac computer into a cellphone, he thought.
6 years later September 10th: iPhone is featuring an all-new A7 chip, making iPhone 5s the world’s first smartphone with 64-bit desktop-class architecture for blazing fast performance in the palm of your hand.
who is able to stuff a desktop-class software inside the desktop-classs CPU powered smartphone ?
quoted from here: http://www.intelliware.com/going-native-cheaper-may-think/
A commonly held belief is that writing native mobile apps is expensive, especially when you need to support multiple platforms. A related belief is that writing apps using HTML5 or a Mobile Application Development Platform (MADP) tool entirely solves the cost issues associated with cross platform application support
The hard truth is: getting an app to run effectively on multiple mobile OSs using any of these methods is more complex than you may realize. If your goal is to optimize the end-user experience, the cost difference between writing native apps tailored for each mobile OS experience and writing a generic app that runs properly in all mobile environments may be less than you expect.
“From a developer’s point of view, one of the greatest advantages to native development is the freedom from worry about cross-platform compatibility. You are able to use hooks and features unique to a specific OS without having to create workarounds for other platforms. Similar features (e.g. share) that are implemented differently across platforms are far easier to develop. The code is cleaner and easier to maintain. Above all, you can get the most out of each platform and present the user with the best experience, all without wasting time “optimizing” code so your app is responsive. Native apps are almost always responsive without effort. The compiler optimizes the native UI widgets for you and the native SDKs force you into sensible design patterns for the mobile platform.
There is a drawback: you are now supporting multiple code bases and all the maintenance that this implies. That’s a pretty big negative, but it does hide an advantage: handling updates. In a multi-platform solution, an update to one OS may bring new conflicts that have to be resolved on the other platforms, which should not have been affected by that update. A native solution should give you less cause for maintenance in the first place, and OS updates should be much easier to apply to your app. The only time you will need to modify all your code bases is when your app is updated. Ideally, you have designed your app such that most of the functionality requiring updates is handled by the back-end.”
Web apps would have some limitations against hybrid apps, but would be available truly anywhere.
So it is not one (web app) over other (hybrid app), rather I look on (HTML/JS) web apps as core (and common, shared) minimum that can be reused for hybrid apps.
here is also interesting statistics/graphs from recent Business Insider: