
Xero ditches HTML5 in favor of native iOS and Android apps - mattquiros
http://thenextweb.com/dd/2013/03/18/accounting-software-startup-xero-ditches-html5-in-favor-of-native-ios-and-android-apps/
======
jarjoura
That's been the case all along that HTML5/CSS/Javascript is much harder to
develop for when targeting mobile devices. You have to build for an array of
screen sizes and your assets need to work in the dizzying amount of screen
DPIs.

However, the freedom you gain in designing a common UI across all mobile
devices you will now lose with having to build discreet applications for each
platform.

iOS applications have a really high bar for slick UI and subtle animations.
(If they are going to be featured and successful.)

Android applications also have a really high bar for system wide integration.
Plus, UI that works on iOS will most likely need to be rethought on Android,
though not always.

Then for Windows 8/WP8 devices you're in for a world of hurt. The UI and
strict guidelines are so different from anything common in iOS & Android that
to include them will require what could likely result in an entire different
design team.

~~~
kayoone
Creating a common UI across all mobile platforms is a big challenge as well
and you mention the main points in your post. Your "one-size-fits-all" UI will
look a little alien on every platform because its made to fit all of them at
the same time.

Personally id use Xamarins excellent C# tools to build the core of the app
multiplatform and then utilize the native APIs to build platform specific UIs.
I dont think this approach is alot more/less work than making your webApp work
with all platforms and resolutions, but in the end you have a native
experience on all of them.

~~~
pjmlp
Yes, I did bash Miguel's work a few times, given his inclination to bring
Microsoft based technologies to the UNIX world.

But I have to acknowledge that he has made a very good work with Mono and
although I prefer to use C++ on my hobby Android projects, Xamarin's tools are
a great approach for many developers.

~~~
kayoone
Agree, while MONO is controversial i believe that in the end its a good thing.
I believe its more Microsofts fault for not making the C# platform open, they
would have probably squashed Java by now.

That aside, mostly i care about the best tool for the job and in this case
thats my choice.

------
mruniverse
Not just for mobile, but building a UI in html has always struck me as a hack.
Mainly because the built-in components (dialogs, menus, buttons, etc) are
lacking. And some components (tabs, overlays, etc) are missing altogether.

I think most front-end devs are so used to it now, that it doesn't seem
bizarre to build tabs with a list element, float the items to the left, add a
clearing div below the list, etc.

~~~
rimantas
It _is_ a hack. There is a reason why we have "T" and not "I" in HTML.

------
marknutter
I was not surprised to see the word "Sencha" in this article, but I _was_
surprised to read it took them 12 months to develop the app. Where I work we
actually replaced two in-development native apps with one cross platform
Sencha app which only took about 4 months to develop. This was with only two
developers, and like with most frameworks the first 80% went extremely fast
but we ended up fighting against it for the last 20%. The performance,
especially on older Androids, was unacceptable.

But instead of doing another complete 180 we decided to instead go with a
hybrid approach like LinkedIn did - use native when performance is key, and
HTML5 everywhere else. We just re-launched the app using all custom
html5/js/css and native ui elements and animations where necessary and it was
a complete success. Not only does the app perform really well on even very old
Android phones, but it absolutely flies on newer devices. The best part,
especially when compared to using Sencha, is that all of our code which was
written in angular.js will be used on the web app and native desktop apps. We
are very close to having the vast majority of our code being shared between
every major platform our users may use.

I love when articles like these get popular because it scares people away from
using HTML5 in any way and gives us a clear advantage. Keep fueling the FUD,
we'll keep our productivity advantage :)

~~~
nullspace
Would be great if you can share more details how you went about the hybrid
html5 - native app route.

For instance, did you scrap all the work you put in with Sencha and start from
scratch? And how did you go about combining native elements and html/js/css,
and how did angular js tie into this?

~~~
marknutter
Yes, we did scrap the Sencha app and start from scratch. Because Sencha Touch
is really only designed for mobile devices with touch interfaces, you can't
really re-use the code for web apps, so there wasn't much to salvage. We also
were not very comfortable with Ext to begin with.

For JS frameworks we decided between Backbone.js, Angular.js, and Can.js
(because we had previously used JavascriptMVC on our web app). We fell in love
with angular.js and went that route.

The main reason to use native UI components is to allow smooth scrolling on
older Android devices which don't support fixed elements like top and bottom
nav bars very well. Both on iOS and Android the top navigation bar and bottom
tab bars are done in native code as well as the Facebook-style drawers that
reveal other sections of the app. In all, we use three Phonegap enabled
webViews and three major native UI components (top bar, bottom bar, and a
custom "quick add" control). We pass messages back and forth from the native
app to the javascript app via phonegap's native bridge, like when a user taps
a native button or the javascript app changes tabs and needs to inform the
native app.

We used grunt.js to help manage all our development and build workflows. It
concatenates our files for us, creates separate builds for iOS and Android
(and other platforms now, too), compiles and minifies our CSS, etc. It also
runs our test suite which is another big advantage to using HTML5/JS instead
of native. Most of our code has test coverage and it's very easy to automate
using grunt.js and testacular.js.

If you're interested you can check out the app on the Play and iTunes App
stores; it's called Kona Mobile (it's the mobile app for our main offering,
<http://kona.com>).

~~~
nullspace
Thanks for the explanation! Makes a lot of sense.

------
DigitalSea
Of course web apps aren't ever going to be as fast as a native application
(especially on iOS because Apple deliberately hampers performance for web
apps) but they're by no means a hopeless cause. A HTML5 web app might take a
little while longer to develop, but it'll work out cheaper than building an
iOS application. LinkedIn to this day remain the perfect example of how to
build a straight-up HTML5 mobile app that performs beautifully.

~~~
fjarlq
How is Apple deliberately hampering performance for web apps? What evidence is
there for this?

~~~
monsterix
There is some evidence for sure. For example, iPad Safari doesn't allow full-
screen mode, nor implements fullscreen API as per standards. Another browser
on the iPad (Dolphin) supports it interestingly.

Support for ordinary CSS properties like z-index, position:fixed and iframe is
pathetic. Some of the things that I can recall now. UIWebView takes it to
another level of pain altogether.

------
Sujan
In the comments of the article a commenter points out that they worked mor
than 24 months in total on the HTML5 web app version and says "That was one
expensive mistake".

I would say, that it was actually a great strategy. When they started, the
HTML version was more than enough. They saved lots of time, effort and
resources during these two years while building their product. Now their
mobile user base is big enough to justify dedicated teams for all platforms -
and that's great for them.

But it doesn't say anything about HTML5 as a viable platform for building
apps. If you are a team of 3, where 0 have any mobile development experience,
but years of web experience, it surely is the way to go. And often, it will
even stay this years later.

~~~
Sujan
Actually, isn't there a name for technologies you use as a stepping stone for
some time?

------
jacques_chester
Storm, meet teacup.

Also, "accounting startup"? Xero is a publicly listed company.

~~~
petercooper
The HN-centric redefinition of "startup" relying mostly on rate of growth is
taking hold it seems.

------
leeoniya
what web-apps offer me, as a user, is peace of mind in terms of security -
something i dont get with native apps that ask for broad, overreaching
permissions. there are many many native apps i refuse to install simply based
on those grounds.

if facebook ditches their mobile site, that will be the end of facebook on my
phone for me.

~~~
mattquiros
I don't make a habit of persuading people to change their preferences, but a
couple of questions:

1\. Don't web apps need cookies enabled in your browser, so technically they
can still track your browsing history and behavior, at least to some extent?
How is that different from your privacy concerns with native apps?

2\. How do you think about installing applications on your desktop/laptop
computer then, since doing so grants them certain permissions, and not doing
so prevents you from doing certain things?

3\. More of a comment, than a question. I don't think Facebook will ever ditch
their mobile site. Mobile sites are a replacement of the "desktop" site
instead of the native app. It's just accessing Facebook via the browser but
with a mobile-friendly UI.

~~~
leeoniya
1\. there's a vast difference between a third party simply tracking which
sites i visit vs an app having access to my GPS location, address books, call
history, etc.., whenever it pleases. with a web browser, i can "share my
location" as i desire...if i want to find nearby restaurants on yelp's mobile
site, i'll share my location once. with an app you just say "yes, you have
permission to read my gps", you have no control of when or how often it does
this.

2\. on my desktop, there's no guarantee that any specific info will be in the
same place. for example i use thunderbird portable in an encrypted container
for my email and contacts. on a phone, your contacts are pretty much in the
same place and every app knows how to get to them, there's much less variance.

3\. you may have a point, but without a good mobile site, they can coerce
people to use the app by providing a shitty experience in the browser, cause
an app can get to a lot more of your juicy data which they crave.

------
rayiner
Web apps suck. It's like going back to 1980's lowest common denominator level
of functionality.[1] I'd rather see something like PNACL offer easy
distribution of native apps over the internet, but we'll probably just see
more web apps (<http://www.dreamsongs.com/Files/worse-is-worse.pdf>).

[1] Honestly, that's an insult to the 1980's. Word Perfect 5.x was pretty damn
functional, lack of GUI aside.

~~~
lukifer
Saying "$X sucks" sucks. Even when it's accurate, it conveys little to no
actual information.

------
michaelwww
From their blog <http://blog.xero.com/2013/03/making-mobile-work/>

_Even with frameworks as amazing as Sencha Touch, we’ve found the ability to
iterate as fast as we would like has become harder as our application has
become more complex. The choice to go with HTML5 was very much a choice based
on us – how do we use the skills we already have to build a mobile
application? Unfortunately as the application grew we needed to hire to fill
out the team, and we were never able to hire fast enough to fill those roles.
Ironically those skills were equally as critical for the 'desktop' version of
Xero – we were cannibalizing our own team and slowing everything down._

With Xero, it seems more like a case of not being able to find great HTML5
developers and less an indictment of HTML5. This is good news for me.

------
SG-
I see this a lot where the person/people making the decisions decide they can
make a product that's almost as good but for less resources/money because they
will be able to use a lot of existing 'web' code and be able to use existing
web devs or simply hire another one.

The reality like this article suggests is it will take a long time to get
something that works almost right but isn't right, even if somehow the
performance doesn't matter going forward with much faster devices. It gets
pretty hard to try and get a webapp to work with native parts of the OS and
features that your users might want or expect.

