Here's why.

First thing I did, started dragging around when I was presented with some grey/brown screen (an intermediary between the load image and the web app actually being loaded?) so I got a nice little rubber bandy action on a grey screen. Web app.

Since there is no normal iOS UI pieces, I find myself being more critical of it because it's unfamiliar.

I tap the input for the dollar amount, I am presented with the default keyboard. Very crappy for entering dollar amounts. Web app.

Oh yeah, also the entire view slides up on focus. Web app.

When changing the number of guests, I get a weird white flash before everything animates in. Typical sign of a... Web app (a symptom of poor usage of translate3d, generally).

And then of course, there's the final piece, this app is a tech demo, not a serious application. It makes no calls to the server, has no serious scroll views, etc.

There are decent examples out there of what can be a good web app, this is not one of them.

As a web developer who is currently on a mobile app project that uses HTML5 and PhoneGap, I have been pleasantly surprised that we have been able to create an app that, in my opinion, looks great, is wonderfully fast on newer devices, and is a pleasure to use.

HTML5 is not the right choice for a lot of apps. But it's an option that should be taken seriously by anyone who has web development experience and it's a solution that I feel is getting better every day.

The problem is, the app doesn't DO anything. There's no scrolling. There's no loading anything from the web (except for the blurry non-retina ads). There isn't anything in this app that makes it a candidate for an app (vs a website) in the first place.

I'm about to start writing my first mobile app - a UI client to a ReSTful image rating API. I've been debating between native and HTML5 for the past few days, and reading this article makes me lean ever more toward native.

I see that the author's goal is possible. However, he's also illustrated that getting an HTML5 app to feel native on iOS requires a deep understanding of the underlying implementation of Safari/WebKit. I assume the benefit to this kind of app design is to keep people familiar with web design from having to learn native development?

The problem is that in the quest to not break your comfort zone, you're ultimately forcing yourself to (painfully) learn the depths of the how Safari/WebKit render HTML5 and where its performance 'gotchas' lie. It seems that the uninitiated would have more unimpeded success using the straightforward, well-documented path of native UI development.

Or maybe my assumption is off. HTML5 was originally appealing to me for the sake of portability; I didn't want to write the same app for umpteen different devices. While the idea of writing just one nice responsive interface is appealing - doing this in HTML5 in such a way that it provides a good UX across all devices (or at least the ones I care about) means that I need to learn all the pitfalls of how all the rendering engines out there work. And then there's the maintenance whac-a-mole game that comes when a fix on one platform creates a bug on another... It seems like for portability it'd be a safer bet to rely on separate code-bases for each platform. If I'm doing that - what benefit is HTML5 providing me specifically toward portability, and is this benefit outweighed by the fact that I need to be a WebKit/Chrome performance guru?

Either way, I'll pose the question again: Am I missing something (not sarcastic/rhetorical)?

I'm a web and iOS developer and I'm starting a consumer facing app and here's my release priority:

1) Web app for desktop, tablet, and mobile using responsive web design

Pro: Every device in the world can reach my app. Since I'm trying to gain exposure, I want everyone to be able to experience what the app has to offer no matter their device or OS.

Con: Currently, users don't expect to interact with my app in this way. They want to go to the App Store and download an app. They also want to use something that they are used to on their specific platform. (To counter this (and for other reasons), the plan is to label the app as beta, so users know what they're getting themselves into and what to expect.)

2) Native App for tablets and smartphones

Pro: Performance, distribution, and native controls. Also, mobile users will use my app differently than desktop users so they deserve their own design and features.

Con: Resources in time and stress managing several code bases.

3) Native App for desktop

Pro: Performance, distribution, and native controls. Also, desktop users will use my app differently than mobile users to they deserve their own design and features.

Con: Resources in time and stress managing several code bases.

Existing case in point - Trello. They started with a responsive web app, they made a great native mobile app, and I expect them to release an awesome desktop app soon.

The author also went through a great details on how he built it: http://cheeaun.com/blog/2012/03/how-i-built-hacker-news-mobi...

If I was to share anything from my recent experience these would be my main points: - use the correct HTML5 elements for input (eg: "number" brings up the keyboard with numbers already selected, "date" brings up a native datepicker (iOS5+))

- Use lightweight javascript frameworks, or write your own. I tried JQueryMobile and performance was terrible with just a simple list(on iPhone 4). Used XUIJS instead and rolled my own framework on top to manage views etc. Performance is great.

- Use graphics only when needed, gradients, shadows, should all be css.

- If you must use graphics, be sure to support high res screens with alternative resolution images. I found the best way is to use the 'background-image' css property with pixel ratio css media queries to differentiate between different resolutions.

- Set the correct metadata values so you can add your web app to the homescreen to run full screen.

One problem I had was a lack of access to Android devices for testing, but I used this site http://www.manymo.com/ and found it invaluable.

The other thing is that this app doesn't have navigating to new screens, especially swiping. I've seen some HTML apps that simulate swipe and it's damn close, but you can still tell that it doesn't feel exactly native.

I think it's great to see HTML apps getting better all the time, though. Having to manage three codebases (Android, iOS and Windows) in three languages can be incredibly challenging for small shops.

The rules:

- Most of the browsers on Android (Chrome's good, but it's not available on anything less than 4.0) suck pretty hard, and you'll almost definitely have to do a few weird hacks to get everything to work well (read: at all, sometimes).

- Use transform-3d for any animations in browsers that support it. No JS required for detection – you can use media queries [3]. For browsers that don't support it, you can fall back to jQuery's animate method [4] or standard CSS transitions.

- Avoid using fixed positioning in your CSS unless it's absolutely (no pun intended) necessary. It's not well supported in many mobile browsers, and you might end up creating more work for yourself down the line (i.e., hacking for Android and older versions of iOS). If you can figure out how to use absolute positioning instead without completely fubaring your layout, do it.

- If you're using divs that don't move (i.e., fixed- or absolute- positioned ones), use -webkit-overflow-scrolling: touch; to enable inertial scrolling within them in iOS and other browsers that support it. If browsers don't support scrolling at all, you'll have to either implement your own scrolling solution from scratch or use one of the many decent ones available on the interwebs.

- Try the simplest solution you can think of first and go from there. Sometimes it'll work better than you'd expect.

1. http://callingvault.com 2. http://m.callingvault.com 3. @media all and (-webkit-transform-3d) {} 4. http://api.jquery.com/animate/

It's easy to imagine, but in my experience, doesn't match reality. Unless things have changed drastically in iOS 6, CSS can be incredibly redundant. Imagine that you have a feed with a lot of drop shadows + gradients on, say, comment buttons on each feed item. Even though the dimensions and styles are the same, for each DOM element, it's going to recalculate layout and re-rasterize the graphics. So while things may be snappy in a mockup, with real data, often times HTML5 (really the CSS) will be exceedingly memory hungry and slow to initialize, thereby killing the experience.

I assume this is the framework the author was referring to.

When I have a connection on it works, but the app asked me for my location, I thought it would give me my currency based on my location, but instead it gave me nothing at all. So I tell you my exact location and get nothing back? Why did I allowed it then?

Overall it's not a really good experience, the modals are cool and the buttons are usable by the fingers, but can't ever mistake it for a native one.

PS: I tried to comment on the blog this exact comment here and the comments were already closed. Maybe too bad comments?

And more importantly, why is this on the App Store if it's HTML5? I'd like to see this running 100% in the browser and then compare vs. native app.

I wonder if that would be any different if it were native?

Could you send it to me to try ?

When we started to port our app to Android and went through the same analysis again. Once again, we have picked native.

Looking at the iOS app we naturally have some webviews for the nice formatting and easy loading of changeable content. If you look at the LinkedIn presentations they have ended up in a similar place. Basically have native apps on each platform with some common ground shared through web views.

Have you considered titanium appcellerator for your project?

I happily used the HTML5 Facebook app on iOS without any notice of its performance "issues." Can someone give me an example of a non-native app where it's lack of nativeness is the cause of poor UX, and for bonus points a similar app with UX noticeably improved by the sheer fact that it is native?