Anatomy of a Native Feeling HTML5 iOS App | Hacker News Reader

Anatomy of a Native Feeling HTML5 iOS App

justinvincent.com

94 pointstheseanz60 comments

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.

Hey, at least you got that far. I'm on a completely brown screen that brings up keyboards when you click in places, but that's it. Can't even kill it in the multifinder, the app isn't there!

I'm caught btw native vs html5 so if you could list a couple of the decent web apps sites you know, I'd be interested to see good examples. Tks

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

I seriously don't get why more developers don't use it.

If I remember correctly the support for the decimal separator is a mess between Android and iOS, I think it was so that iOS defaults to comma and Android to a dot which makes is difficult to write any cross-browser code with input-type number if it has to handle decimal numbers as well.

Surely these advanced operating system environments allow you to localise decimal separators?

The last pic in the article says they did exactly that.

Pix or GTFO. Any internet windbag can make cheap criticisms. Show us some examples of what you regard as "a good web app".

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 important bit is that HTML5 is a set of standard abstractions around complicated things, such as networking and data-storage, that should almost never be re-built from scratch by the developer.

It is extremely important that we build standards around these things. Unfortunately, it seems like these abstractions are only accessible through a JavaScript DOM environment, which makes them sort of useless if you need/want another language.

I think we need languages agnostic standards. That's at least my idea of the future of the web and desktop development.

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.

Scrolling feels 100% native using -webkit-overflow-scrolling: touch;

I am currently working on the next (more complicated) app for UberMedia that has all of those components and works very nicely. It will be one month or so before it is ready for release.

-webkit-overflow-scrolling:touch disables the feature where tapping the phone's status bar scrolls content back to the top. That has been a showstopper for most of the things I have worked on.

True. I wonder if there's a fix for this in PhoneGap, at least.

One workaround that was functional but subpar experience-wise:

Put a transparent UIView over the status bar and wire it up to call a javascript function on your UIWebView using stringByEvaluatingJavaScriptFromString.

You can fake it with some pretty simple Javascript.

I have tried many a workaround, all quickly reveal a pretty crappy non-native experience.

That sounds like a bug. Have you submitted a radar on it?

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

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?

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.

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

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

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.

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?

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.

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.

If you have the time to validate a different approach using Html5 and mixing Native OpenGL, you can see it by download a Android Apk in https://github.com/Srid68/Priya.InfoList (Early Alpha)

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.

Interesting. I found I had the exact same experience as you did for my latest projects. In fact you helped solved a problem I have with JQuery Mobile (i.e. it laaaaaaaaaaaaaaa....gs)

Guess I'll be picking up XUIJS.

Zepto is also worth checking out, especially if you're looking to reuse bits built with jQuery from a larger web app (API is almost identical).

Yeah I've tried Zepto as a drop-in replacement for JQuery once ... a long time ago. The results were disastrous (everything broke!) but I guess I'll try it again

It's still not a drop-in replacement, but it's close. You need to include more modules than just the core for eg. ajax or transition effects (the official modules are all available from http://zeptojs.com and/or the github linked there). I maintain a pretty hefty Backbone based web app where we use Zepto for mobile/non-IE to save on file size, and serve the exact same code but with jQuery for IE. In about a thousand lines of code, there are only 3 or 4 edge cases where the code paths diverge for a line or two, and they're due to IE peculiarities rather than Zepto/jQuery conflicts.

You should have a look at this page for a comparison of javascript frameworks on mobile devices:

http://www.codefessions.com/2012/08/performance-of-jquery-co...

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/

For my latest project I've did all that. Here are somethings I've learned:

I've discovered that chrome has a problem with zoom levels (Nexus 4), while my older Desire's browser worked well.

Overlaying text over images is a royal pain in the ass for all mobile browsers. (Your standard position:fixed and position: relative thing won't work well unless you write media queries for every single goddamn fucking resolution)

Chrome lags with JQuery animation and that's an issue I'm looking to fix (since I am using Bootstrap's carousel)

Media queries are fucking amazing. Javascript support on most mobile browsers are quite terrible, and even lags (I'm using an iPod touch to test my webapp)

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

The way to get around that is to remove drop shadows as scrolling starts. When the scrolling is complete add the drop shadows back again.

Drop shadows and alphas are the main issue, just need to manage them.

It's easy to do with a single css class added to the main body tag (i.e .isScrolling).

Then in the CSS use .isScrolling .myDiv { / no shadows / }

// On scroll start $('body').addClass('isScrolling');

// On scroll stop $('body').removeClass('isScrolling');

Works a charm!

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

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

The framework author and the post author are one and the same.

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.

I actually think the app is pretty well made; I didn't notice too many of the problems that the other people are critiquing when viewed on my iPhone 5.

Having said that, the bigger question is: why do all that custom work when you can make a native one much quicker and more easily?

I think what this app shows is the lack of a HTML5 framework to quickly put together mobile apps that feel native the way you can with the iOS SDK or Android SDK. In the HTML5 world there are a lot of frameworks and libraries to create a mobile website, but there isn't one that lets you make a native-feeling web app. There are a lot of disparate pieces addressing different issues (PhoneGap/Titanium for native app launching, Bootstrap/Foundation for UI controls, fastclick implementation for faster tap response times, removing the URL header, hiding browser scroll bars, ...).

The UIPickerView is the default control that pops up when you use an HTML dropdown. It's built into the webview/browser.

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.

In reality for the vast majority of apps you'll never notice the limit. By far the most effective thing to use for (hardware accelerated) smooth animation are CSS transitions which run at normal speed like safari.

The only circumstance where missing JIT support for the webview would come into play would be with games, and even here there is plenty of room for performance (check out impactJS)

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.

Reply on news.ycombinator.com