It's going to be both web and native. Performance matters and web simply aren't up to it for a long time to come. Even with WebGL etc.
Understanding the tradeoffs is important because we don't have unlimited development resources.
The backend and design work scale identically for web and native apps as you move from "prototype" to "usable app" to "delightful experience". The client side work scales relatively linearly across this axis for native code, but tends to rise exponentially for a web app.
He actually said that couldn't really think of any good examples of a "delightful experience" in a web app, particularly on mobile. He cited the example of one of the top web companies on the planet working for years to build what is arguably a worse word processor than the "hello world" example code included in most native platform SDKs.
Another issue is that once you start really trying to nail the user experience on each platform, most of the cross-platform nature of a mobile web app goes away. Sure, you can use something like PastryKit to make a web app that acts just like a native iPhone app, but then you end up with a very un-Android-like app when using it on Android.
Something like JQuery Mobile is a great way to get a usable product to market on multiple platforms quickly, but ultimately not everything that could be just a web app should be just a web app.
Anyway, this is just patently untrue for many, many users:
But you know what? My dad doesn’t care about the deceleration of a scroll and neither does yours. Not mentioning the “native experience” of my brother’s ZTE!
Yeah, dad doesn't care about "scroll deceleration", but if the app feels clunky and unresponsive, they do care and won't come back. Again, it depends on whether we're talking about real apps that do something or just wrapped-up marketing pages.
Already, developing the same app for the iPhone, iPad, Android phones, and Android tablets is an expensive prospect. Appcelerator helps, but it's not a perfect solution, in part because it doesn't and probably never will support every platform.
With HTML/CSS/JS, on the other hand, you get cross-platform compatibility for free. "But," you say, "not all mobile devices have good support for web technologies!" This is true, but I think we can expect that to change. Support for the web should constantly improve across all platforms over time.
Since I prefer to invest in the technological long-run, I'll put my money on web apps except when native-only features are required. That way, instead of trying to port my app to an ever-increasing number of platforms, an ever-increasing number of platforms will--of their own accord--come to support my app.
the problem is that vendors will have a conflict in implementing those features since they will compete with their native apps and app stores
Apple and Google will need developer pressure to keep them honest, and hopefully give us access to the appstore upside of distribution while writing to just the html5 api
They can maintain the same approval processes, charge the same fees, and enforce submissions of your mobile apps to the same places if you want inclusion in their app stores.
For mobile web, it could be as simple as compressing a folder of specially named HTML and JS files or providing an absolute URL where the main "executable" HTML file lives.
In the end, Apple and Google can make the same amount of money from mobile apps vs native apps. I don't find many reasons they would care how the app is made (except that maybe they want "exclusive" apps that are only on one platform or the other --- or they want to not include absolute URL mobile web apps because you can submit an app and change it entirely the next day by changing the files on your server...though you could get around this by mandating that your app be submitted as packaged HTML/JS)
The only thing I can see possibly being a concern is UI consistency - web apps are a free-for-all. Apple may release a UI kit
Until you can solve the data input problem on mobile devices, and massive content delivery limitations by screen size, web apps will still rule.
When it comes to games, the computer vs. mobile device really isn't a fair comparison. They both solve different entertainment needs. One is an intense or shared experience need, the other is a casual time filler need. The concept of a portable gaming system is not new. Mobile games are just more accessible than previous systems.
I could remember CPU-intensive applications (for example, number crunching of all sorts), cryptographic applications, OS-integrated applications (VPN, network filesystems of all sorts, process monitoring, and whatever else needs to be integrated with OS), all sorts of plugins and so on.
Essentially, if your app is glorified advertising or a just a front-end to an online database, yeah, you can probably use the web. Otherwise, if there's more than just pretty, mostly static, graphics over the top of SQL, then you better go native otherwise your competitors will.
I see articles like this all the time that talk about "their mom" not minding such and such. Really, they are just talking about setting the bar low enough to step over it. My parent used a shitty virus laden install of windows xp for years, and crashing was just part of the experience, like a sticky lock or a worn screwdriver. Do not use others expectations as an excuse -- surprise and delight people. (dammit :-))
Windows Media Center (2002)
Garage Band (2004)
Final Cut Pro (1998)
Creative Suite (2003)
True Crypt (2004)
Visual Studio (1995)
under "Specifying a Startup Image": https://developer.apple.com/library/safari/#documentation/Ap...
I don't have an answer yet.
Right now, since apps are predominantly native, a vendor can add new hardware and capabilities to their devices without the prior blessing of a standards body. Standards bodies will always be several years behind the state of the art in features, which means anything really compelling and new will always be in native form.
As long as IE lives, web standards will move at a snail's pace. I'd say we're >5 years (probably more!) out from being able to, in general, expect something like geolocation to be supported in your average user.
If you want to move faster than the competition and give more hardware/features to your users, you're still going native.