Unraveling HTML5 vs. Native
designmind.frogdesign.com
designmind.frogdesign.com
With a native app if you write your code for Version X of the OS you can be 99% certain that Version X.1, X+1, and X+1.3 are all going to treat it the same. With HTML5 "fixes" to the renderer can mean that what was working will stop working. Or stop looking like it used to.
With an HTML5 app you should be able to write once and deploy many, but Mobile Safari, and Mobile Chrome, that do the renderings on IOS and Android don't handle all JS and CSS quite the same. So you may have slight differences. Much less than you would have with ObjectiveC vs Java, but differences none the less.
PhoneGap makes much of the stuff you want to do with the hardware easier, but not perfect. If you want to send a Text, or make a call or access the contacts you will have to at least touch a plugin, if not write some native code. Most of the time you can just clip a snippet from someone else, but if you want to do anything awe inspiring you will have to still get your hands dirty with native code.
http://tldrstuff.com shows what we were able to do with a single UI Core across Windows Phone 8, Android, and IOS.
We hit all of the platforms, and had less code to change, but our app doesn't "Feel" native. We don't have a UI that looks integrated with the OS, but we have concistency across platforms. Was our decision "right"? Hard to say. We spent less resources which was a major driving factor so I say yes. Did it keep us from being Wavii or Summly? I hope not. But it is hard to say. I don't know if we traded dev resources for glory, or if we saved money we will want and need to be bigger than either.
Fwiw, the Flat/Tiled/Metro design motiff seems to taking off enough that it's a satisfactory cross-device substitute for native.
Summly used it too; as such, yours doesn't look significantly different theirs, other than their use of transparency in places.
Maybe it was their mention of their use of genetic algorithms in their well-done launch video [1], and having a 15yr old founder, that did it for them. Of the Three T's they nailed two - team and technology. Attention, interest, and Traction were sure to follow.
This is an "write once, deploy many" that has a bit different offering then html5, specifically, it deploys natively, allows offline usage, can be set up to use native ui elements, has a gpu accelerated animated vector engine available, etc.
Yet I can easily write a dozen lines of code with my 1990s GUI knowledge that display 20,000 items in a sortable table and work at full speed in any browser -- while having endless performance problems/memory leaks when using HTML and various "data tables" plugins.
Maybe in 10 years we'll have something that will let you build a GUI right in the browser and will work cross-browser properly.
What distinguishes native apps is not whether they are rendered with HTML (many native apps use HTML rendering for parts), or whether they have access to privileged APIs, but instead whether they conform to the behaviors and conventions of the platform. Getting that conformance requires using the APIs the platform gives you - you cannot adequately copy it, as Java Swing has proven.
For example, Light Table fits your criteria: it's a double clickable .app file with access to privileged APIs, with HTML and CSS rendering the UI. But it's obviously not a native app, and will never feel like one.
Note that I didn't say "real". Light Table is certainly a _real_ app. But the distinction is inescapable: it's impossible to miss the fact that Light Table is non-native.
Different runtime environments and different OSs have real differences. For some apps those differences don't matter. For others, they can make the difference between useful functionality and a pleasurable UX and a dull trudge through interactions that don't benefit from native platform capabilities.
Maybe Web apps will find their highest expression in OSs that feature Web runtimes. Java was supposed to be "write once, run anywhere" but, for interactive apps, it only became popular once Google wrote an OS and class library specific to that Java OS.
The importance of power consumption, fine-grained interactivity, the need to fit non-browser concepts in user experience such as AppWidget in Android, the desirability of sync vs. CRUD-over-IP etc. are among the decision points for choosing one or more client implementation approaches.
Then there is the fact that most high-value apps do not have a single answer for implementation approach, and that these high value apps were not born that way. When Facebook turned away from making mobile Web apps, they did not also start making native desktop clients.
This is how I would boil it down: Is your app valuable enough to be worth spending enough on a mobile client implementation than can do things a Web interface cannot do? That is, for a minimum viable product, you probably need to do almost everything your Web interface does, but in order to really justify the effort, you should, at least, have a road map to some place where the mobile app exceeds what the Web app can do. This might be as simple as notifications and an AppWidget. But preferably it's something app-specific.
in iOS it's okay we could connect device/simulator and open the safari inspector to debug. But in android it's almost impossible to know what & where the javascript has gone wrong and fix.
The webkit in android 2.3.x version also will render differently on some css properties compared to 4.x version.