[benjamincburns]

I'm probably missing the point (not sarcasm).

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)?

[matwood]

We asked this question before writing our iOS app. Before I came on the team they had used PhoneGap to get part way there, but pulled the plug because of performance issues. Creating the app in native iOS worked and took about the same amount of time as what the original PhoneGap project had spent writing and trying to optimize the performance issues. Disclaimer, 2/3 team members had some iOS experience.

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.

[jv22222]

The author here. You bring up a very good point. The caveats will be different for all different devices. And this does depend on a very deep knowledge of HTML5 hacks and tricks as well as a lot of experimentation.

Have you considered titanium appcellerator for your project?

[benjamincburns]

I have, but I'd rather stick to one set of proprietary technologies (the app platforms themselves) than learn another proprietary layer atop said first proprietary layer, and risk constantly scratching my head in vain when inevitably the abstraction leaks and things become inconsistent.

Not to mention lock-in. I'm already at the mercy of the respective distribution channels - I don't need to add to that pain.

Edit:

Don't get me wrong, I'm happy that these things exist. I like anything that lowers the barrier of entry for people who otherwise wouldn't write software. It's just that you're trading a lot of maintenance/optimization time for a shallower learning curve - and it's important to make that known.

Also one last point - the reason why this kind of stuff typically needs to be learned through painful iterative experience is because it's typically undocumented. In most cases it's undocumented specifically because it's not a supported development path, and as a result it's very likely the techniques you discover today will break tomorrow.

It's a lot like leveraging unspecified/implementation-specific language behaviors in C.

[benjamincburns]

Also another question along this topic: How bad is "not native feeling" for UX? As a poor self-funded "I just need to launch this" wantrepreneur, do I care?

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?

[ianhawes]

Native Twitter iOS app vs the HTML5 Twitter app.

Native Twitter is great. Very snappy, great UX. If, by chance, you click a Twitter link in Safari on iOS, you'll be facepalming as you wait.

[lukifer]

Twitter's HTML5 is the worst possible example. That thing is unusably slow on high-end desktops, too.

[benjamincburns]

Is it possible to load both apps simultaneously to do a comparison? I feel like I need to experience the trade-off.