Anatomy of a Native Feeling HTML5 iOS App (opens in new tab)

This app is so painfully a web app.

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.

The reality is that the quality of any app depends on the skill set of the developer(s). Some of the native apps I use are wonderful, others are terrible.

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 animations are smooth and I wouldn't be able to tell if it was native or not based on what the app can do.

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

I've been working on a more polished version of HTML5 Clear, trying to bring the "native-like HTML5" concept a bit further. It's still work in progress (around 85%) but it can be found here: http://clear2.youyuxi.com

This is a great example of the power of HTML5 and excites me about the future of it.

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 best "native feeling" HTML5 app I've seen is hnmobile: http://cheeaun.github.com/hnmobile/ ,which I use everyday and recommend to everyone who read HN on iPhone.

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...

I just recently completed a mobile web app for my start-up and was pleasantly surprise with what I was able to achieve.

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.

This is a really nice looking html app. There's a couple of things not mentioned that I think help it look like a native app. One is that the app actually doesn't actually try to look like a "native" app with standard iOS controls - it looks like a custom styled app. In that way you don't actually have to trick the user into thinking the controls are all native. Perhaps some people might consider that cheating, but I think it's clever.

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.

In my (very recent) experience building a relatively complex [1] mobile web app [2] as a first-time web-app-for-mobile developer, I learned a few important rules, so to speak, about how to make the app feel as native as possible. (If you check it out, let me know at frank at callingvault dot com if you have any issues. We're in beta, and we love when tech savvy folks test.)

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/

> Although the app is small, it’s easy to imagine that a larger app made of multiple components such as this could also be made to feel just as native.

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.

DoubleDollar JS Framework: http://doubledollarjs.com/

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

Stepping back a bit, I find this incredibly ironic. When the iPhone was a year or less into its release and there was no App Store and when Steve Jobs stood on the stage of (iirc) a developer conference and told devs that the API for programming the phone is simply HTML and Javascript through Safari .... I sensed laughter in the crowd :)

I don't mean to bust your balls here, because I really like HTML5 and believe that there's some potential there for making apps, but I just installed it, and when offline, the app does nothing besides showing me interface and a loading spinner. Forms will even work, but the view isn't updated and nothing really works.

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?

Interesting, though using "position: absolute" for everything would be a problem on varying screen sizes (or for a more complex UI). The CSS3 flexibox module can accomplish a lot of "app" layouts pretty easily, however (and you can mix and match!).

There is what appears to be a UIPickerView in this app. Did the developer re-implement this in HTML5? If so, doesn't that defeat the purpose of using HTML5 if they're just going to replicate iOS's look and feel?

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.

Why would you craft all that in CSS, and then use an image to do a simple gradient? Not that I'm claiming there aren't reasons (AFAIK you can't add random dithering to the gradients to make the transition between shades less noticeable) but still - why?

I still prefer writing the core of the application in something platform independent like monoTouch and then building UI with the native tools. I dont even know if its much more work than fiddling with HTML5 for weeks to get it feel right.

Even for a simple app like this there is slight lag when loading UI elements (iPhone 5) and was fairly noticeable. I'm not sure I'd consider this non-native if I didn't know for sure but I would think it was poorly made.

Nice, thanks for the breakdown on what you did on each section.

Downloaded the app, and it is quite smooth. Only lags when the ads are changing...

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

Too bad Apple artificially limits the performance of the embedded browser.

Seemed to take a chunk of time to download. What's coming down the wire?

Since this is an HTML5 App made in Phone Gap it should be possible to have an Android version shouldn't it.

Could you send it to me to try ?

iOS is about detail. Especially the "feeling".

Sorry but the app doesnt feel native at all. it is slow ,doesnt feel snappy on the last iphone. And you can easily tell the difference on touch event ,there is an noticiable lag, and nobody cant do anything about it. Web apps are good for basic lob apps. But for anything more complicated , going native is the way to go.