In my experience, implementing a sufficiently complex app in PhoneGap targeting Android, Windows Phone, iPhone and iPad is absolutely more work with lower quality result than doing native versions of each app through Xamarin.
HTML apps have a tremendous hurdle to overcome. Customer expectations are different between something opened in a web browser and something downloaded from the app store. Apps that are amazing as web pages can be awful as apps. The amount of effort required to get a web application to perform in a way that matches user expectations for native UI cues, animations, quality and responsiveness across platforms is enormous and incredibly more difficult than your standard web app.
Of course, if you target just one platform, things get a lot better, but at that point, why not just use the native tooling?
This has been my experience, having tried both approaches over the course of several years, across team sizes ranging between one and ten developers.
Netflix has been using HTML5 for their mobile apps for years and the vast majority of people you will ask about it, developers or otherwise, probably don't realize it. It can be done, and is being done by many apps out there. And no, it does not take as much effort as writing N native apps for N platforms.
There's no argument that it can or can't be done, only that the time and cost to implement is equal to or greater than implementing N native apps. Wouldn't mind a contradictory citation for apps that have taken the plunge and found it to be worthwhile, and that the write-once-run-anywhere promise was fulfilled to their satisfaction.
You'll notice that the Windows Phone Netflix app certainly isn't using the same approach as the iOS and Android counterparts, and the iOS/Android versions use a non-trivial amount of native UI components for their respective platforms.
Ah, I see. All that matters for me is that it works and it looks good. I constantly modify my designs so that they are as easy as possible implement, without losing any usability. There are no fancy transitions, no fancy widgets, just a handful of animations where they are necessary for comprehensibility. My focus as a designer is on what users are able to do with my app. All my design effort is in service to that.
I don't have the resources to care about nativeness. I think you're definitely right that if you want something that behaves like a native app you're much better off just building a native app. I suspect for most people that level of nativity doesn't materially affect their business though.
One thing to keep in mind is that targeting a browser is not the same as targeting an API level. API levels guarantee consistent behaviors across different targets, but if you use the WebView, you'll encounter different behaviors across the same version of Android across different hardware vendors. Debugging PhoneGap apps isn't exactly painless, either.
It's a bit of magic to see a game work reliably across Android devices dating back to Froyo with excellent performance. Running your web app on the same hardware is not quite such a delight.
It's also interesting to note the bigger players that have recently made the transition from HTML5 to native apps. That said, the good enough bar may be good enough for many people.
HTML apps have a tremendous hurdle to overcome. Customer expectations are different between something opened in a web browser and something downloaded from the app store. Apps that are amazing as web pages can be awful as apps. The amount of effort required to get a web application to perform in a way that matches user expectations for native UI cues, animations, quality and responsiveness across platforms is enormous and incredibly more difficult than your standard web app.
Of course, if you target just one platform, things get a lot better, but at that point, why not just use the native tooling?
This has been my experience, having tried both approaches over the course of several years, across team sizes ranging between one and ten developers.