
Anatomy of a Native Feeling HTML5 iOS App - theseanz
http://justinvincent.com/page/2043/anatomy-of-a-beautiful-native-feeling-ios-app
======
amadeus
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.

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

<input type="number">

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

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
srid68
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)

------
bearwithclaws
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...](http://cheeaun.com/blog/2012/03/how-i-built-hacker-news-mobile-web-
app)

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

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

~~~
napoleond
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).

~~~
chewxy
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

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

~~~
willmacdonald
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...](http://www.codefessions.com/2012/08/performance-of-jquery-compatible-
mobile.html?spref=tw)

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

------
fratis
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/>

~~~
chewxy
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)

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

~~~
jv22222
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!

------
8ig8
DoubleDollar JS Framework: <http://doubledollarjs.com/>

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

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

------
aufreak3
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 :)

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

------
randallu
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!).

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

~~~
tomkit
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, ...).

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

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

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

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

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

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

~~~
skyhook_mockups
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)

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

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

------
Neputys
iOS is about detail. Especially the "feeling".

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

