8 ms·

Xero ditches HTML5 in favor of native iOS and Android apps

44 points by mattquiros 14y ago

leeoniya 14y ago
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.
- t0 14y ago
  This article isn't actually about mobile sites, it's referring to tools that compile HTML5 into native code like Phonegap. But yes, when you're giving all kinds of permissions to strangers, chances are somebody is using your data maliciously.
  - argonaut 14y ago
    Phonegap doesn't compile HTML5 to native. It uses web views (HTML5 embedded in native code).
- mattquiros 14y ago
  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.
  - jiggy2011 14y ago
    An installed application can potentially do a lot more than a cookie. For example, open files on the filesystem, read text messages & phone numbers and upload these to a third party server and sometimes even modify or install other software. The same issues exist with desktop applications of course, for example various spyware toolbars etc so you always have to make some judgement call. The main difference seems to be that when you access a website on your desktop you are much less likely to get some popup nagging you to download a desktop app to consume the content vs a smartphone app. I guess because most desktops are fast enough that you can get reasonable performance from just HTML5 or flash.
  - leeoniya 14y ago
    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.
- kayoone 14y ago
  there are alot of apps that are essentially a webview component showing some website and they still send you push notifications etc. (eg. the old HTML5 facebook app) This is not about App-Store vs Web distribution, its about real Apps and their underlying tech.
- pjmlp 14y ago
  > what web-apps offer me, as a user, is peace of mind in terms of security Are you sure? The browser also has security exploits, being coded in C/C++. With JavaScript you can also do something similar to fork bombs. And lets not forget the plugins as well or the JavaScript APIs to access your data.
  - leeoniya 14y ago
    i would say there's a huge difference between a web browser that happens to have an exploit vs willfully surrendering your own privacy to an app designed to harvest your data. i'll take the former any day of the week.
    - pjmlp 14y ago
      You forgot the part about JavaScript APIs to your data.
      - leeoniya 14y ago
        if anything 3rd party asks for permanent access to my data, it's not getting installed. javascript APIs can be configured to ask you every time for permission, in fact that's the default.
DigitalSea 14y ago
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 14y ago
  How is Apple deliberately hampering performance for web apps? What evidence is there for this?
  - mille562 14y ago
    http://www.tuaw.com/2011/03/18/apple-confirms-some-webkit-optimizations-unavailable-to-ios-apps/ http://www.tuaw.com/2011/03/18/apple-confirms-some-webkit-op... The discussion is about apps written natively vs apps written in HTML (not web pages viewed in safari). The only method available to develop an iOS app with HTML is to use UIWebView, which is crippled compared to Safari.
  - MaxGabriel 14y ago
    He's referring to web apps that are embedded inside a native wrapper. UIWebViews don't use the more performant Nitro JS engine.
  - girvo 14y ago
    Due to security concerns, JIT (also known as "Nitro" in iOS parlance) is disabled for UIWebViews, but is enabled in the browser itself. I assume that is where this is coming from.
  - woadwarrior01 14y ago
    I guess he's talking about javascript JIT being enabled in Mobile Safari, while not being enabled for apps using UIWebView.
  - deleted 14y ago
    [deleted]
rayiner 14y ago
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 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 14y ago
  Saying "$X sucks" sucks. Even when it's accurate, it conveys little to no actual information.
jarjoura 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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.
jacques_chester 14y ago
Storm, meet teacup. Also, "accounting startup"? Xero is a publicly listed company.
- petercooper 14y ago
  The HN-centric redefinition of "startup" relying mostly on rate of growth is taking hold it seems.
- lancewiggs 14y ago
  Worth over a billion in NZD, and approaching that in USD. But when it listed, raising $15m, several years go it was indeed a start-up.
mruniverse 14y ago
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 14y ago
  It is a hack. There is a reason why we have "T" and not "I" in HTML.
Sujan 14y ago
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 14y ago
  Actually, isn't there a name for technologies you use as a stepping stone for some time?
marknutter 14y ago
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 14y ago
  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 14y ago
    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 http://kona.com).
SG- 14y ago
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.
michaelwww 14y ago
From their blog http://blog.xero.com/2013/03/making-mobile-work/ 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.

44 points by mattquiros 14y ago

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.

t0 14y ago
This article isn't actually about mobile sites, it's referring to tools that compile HTML5 into native code like Phonegap. But yes, when you're giving all kinds of permissions to strangers, chances are somebody is using your data maliciously.
- argonaut 14y ago
  Phonegap doesn't compile HTML5 to native. It uses web views (HTML5 embedded in native code).
mattquiros 14y ago
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.
- jiggy2011 14y ago
  An installed application can potentially do a lot more than a cookie. For example, open files on the filesystem, read text messages & phone numbers and upload these to a third party server and sometimes even modify or install other software. The same issues exist with desktop applications of course, for example various spyware toolbars etc so you always have to make some judgement call. The main difference seems to be that when you access a website on your desktop you are much less likely to get some popup nagging you to download a desktop app to consume the content vs a smartphone app. I guess because most desktops are fast enough that you can get reasonable performance from just HTML5 or flash.
- leeoniya 14y ago
  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.
kayoone 14y ago
there are alot of apps that are essentially a webview component showing some website and they still send you push notifications etc. (eg. the old HTML5 facebook app) This is not about App-Store vs Web distribution, its about real Apps and their underlying tech.
pjmlp 14y ago
> what web-apps offer me, as a user, is peace of mind in terms of security Are you sure? The browser also has security exploits, being coded in C/C++. With JavaScript you can also do something similar to fork bombs. And lets not forget the plugins as well or the JavaScript APIs to access your data.
- leeoniya 14y ago
  i would say there's a huge difference between a web browser that happens to have an exploit vs willfully surrendering your own privacy to an app designed to harvest your data. i'll take the former any day of the week.
  - pjmlp 14y ago
    You forgot the part about JavaScript APIs to your data.
    - leeoniya 14y ago
      if anything 3rd party asks for permanent access to my data, it's not getting installed. javascript APIs can be configured to ask you every time for permission, in fact that's the default.

DigitalSea 14y ago

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 14y ago
How is Apple deliberately hampering performance for web apps? What evidence is there for this?
- mille562 14y ago
  http://www.tuaw.com/2011/03/18/apple-confirms-some-webkit-optimizations-unavailable-to-ios-apps/ http://www.tuaw.com/2011/03/18/apple-confirms-some-webkit-op... The discussion is about apps written natively vs apps written in HTML (not web pages viewed in safari). The only method available to develop an iOS app with HTML is to use UIWebView, which is crippled compared to Safari.
- MaxGabriel 14y ago
  He's referring to web apps that are embedded inside a native wrapper. UIWebViews don't use the more performant Nitro JS engine.
- girvo 14y ago
  Due to security concerns, JIT (also known as "Nitro" in iOS parlance) is disabled for UIWebViews, but is enabled in the browser itself. I assume that is where this is coming from.
- woadwarrior01 14y ago
  I guess he's talking about javascript JIT being enabled in Mobile Safari, while not being enabled for apps using UIWebView.
- deleted 14y ago
  [deleted]

rayiner 14y ago

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 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 14y ago
Saying "$X sucks" sucks. Even when it's accurate, it conveys little to no actual information.

jarjoura 14y ago

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 14y ago
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 14y ago
  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 14y ago
    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.

jacques_chester 14y ago

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

petercooper 14y ago
The HN-centric redefinition of "startup" relying mostly on rate of growth is taking hold it seems.
lancewiggs 14y ago
Worth over a billion in NZD, and approaching that in USD. But when it listed, raising $15m, several years go it was indeed a start-up.

mruniverse 14y ago

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 14y ago
It is a hack. There is a reason why we have "T" and not "I" in HTML.

Sujan 14y ago

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 14y ago
Actually, isn't there a name for technologies you use as a stepping stone for some time?

marknutter 14y ago

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 14y ago
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 14y ago
  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 http://kona.com).

SG- 14y ago

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.

michaelwww 14y ago

From their blog http://blog.xero.com/2013/03/making-mobile-work/ 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.