Tuesday, February 19, 2013

Eating My Own Words: GQueues Switches from HTML5 to Native Mobile Apps

In a guest post on the Google Code Blog back in May 2011 I argued that an HTML5 web app was a viable alternative to native apps for businesses looking to provide a mobile offering for a rapidly evolving product with limited developer resources.

I was wrong.

Well, mostly wrong. At the time I had just finished the HTML5 mobile app for GQueues and earnestly believed this was the right strategy for the product and business. I had a long list of major features I planned to implement and knew that creating several native apps and supporting multiple mobile codebases would significantly slow down development. Iterating quickly had been key to the success of the product to that point, and as a solo developer I had to carefully allocate my time.  A single HTML5 web app that worked on all mobile platforms made the most sense.  At the time, other companies such as Facebook and Google were embracing the same strategy.

Going Native

Two weeks ago I launched GQueues for Android and am currently developing a native GQueues app for iOS - so it's time I eat my own words. Or at least explain my complete change in strategy. Although I am still the sole developer for GQueues, a number of discoveries and changes over the last two years led me to the decision to finally go native.

HTML5 Fragmentation

One of the purported advantages of an HTML5 web app is the ability to write a single app that works everywhere. In theory a mobile web app can work on any device with a browser.  And while this might hold true for the simplest apps, I discovered that apps such as GQueues that utilized the most advanced HTML5 features with offline capabilities faced the same fragmentation challenges as building for multiple native platforms.  Although most WebKit-based mobile browsers supported WebSQL databases (at the time), allocating storage space differed on various devices.  The speed of reading / writing to the database varied significantly by device, as well as the performance of JavaScript engines.  I discovered that no browser on any device was capable of handling an account with 10,000 tasks at the speed expected by typical users.  As users reported bugs with the GQueues mobile app I found myself making changes to accommodate various devices and browsers which defeated the whole purpose of the single web app.  On top of that, documentation for a browser's implementation of HTML5 features was sparse, making support a huge effort of experimentation.  In short, HTML5 is still a nascent technology and significantly behind native platforms in terms of speed, responsiveness, features and maturity.

Background Syncing

I completely underestimated the importance of having automatic background syncing.  With the HTML5 app users had to hit the Refresh button to retrieve any new data from the web.  And syncing didn't happen at all when the browser was closed and the app wasn't loaded.  In developing the web app I reasoned this was a small compromise to make to gain the other benefits of HTML5.  I was completely wrong.  Background syncing is paramount for a task management app like GQueues.  Users on the go expect their data to be current and available whenever they want, even without a network connection.  Meeting this expectation is really only possible by syncing in the background whenever a network connection is available and by utilizing push messaging provided by native platforms.   The limitations of HTML5 provided a poor user experience, whereas the robust background syncing in GQueues for Android is one of users' favorite features.

Mobile Landscape

The mobile landscape has changed quite a bit in the last two years. In 2011 smart phones were just beginning to tip and the market was young and ripe with opportunity.  Many companies were competing for smartphone market share. Android was just beginning to take the lead, while BlackBerry and iPhone vied for the second spot.  Many devices still ran Windows Mobile 6.5 and even Palm webOS was at the table (remember them?). Now the market has consolidated with Android a clear leader and iOS claiming the remainder. Today a business needs their product on only two mobile platforms to cover 88% of all mobile users. This is much more feasible (even for a solo developer like me) than creating 4 or 5 different mobile apps, or betting on the wrong one.

Product Evolution

The HTML5 strategy did prove valuable in one area - it allowed me to continue rapidly adding features to GQueues without being slowed by maintaining multiple mobile apps. GQueues is a much more mature product now than it was two years ago. While I will continue iterating based on user feedback, GQueues has a much larger core feature set now, which makes the initial versions of the native apps more useful and provides a stronger base to build on.

User Demand

The most eye-opening discovery I made regarding native apps was the enormous user demand from GQueues customers. Last May I surveyed all GQueues users and asked what new features they wanted most. A native Android app was at the top of the list (30%), followed by a native iOS app (20%). People had tried the HTML5 app and they weren't satisfied. To grow the product, company and user-base, GQueues needed native apps - simple as that. So I finally set out to build them.

Creating the native Android app was a large undertaking and some complained about the lack of other improvements during the 3 months of development.  But the clear mandate from users gave me confidence this was the right decision, and since launching the app on Google Play most users agree it was worth the wait.  Now as I embark on a similar journey developing GQueues for iOS, knowing the app will be a huge improvement for users motivates me during the long days and nights of coding.


  1. I fully appreciate your hard work, dedication to tasks, creative innovation and ability to genuinely listen to the user base. Gqueues is a fine example of passion meets talent and is a glowing example to the developer community at large. On every occasion I have to recommend your product, I will. Thanks, Cameron.

  2. Glad to hear! I don't use GQueues much these days and thinking about it, the mobile app was one of the reasons. Thanks for admitting your mistakes and sharing your thought process, I look forward to the iOS app and giving it another go!

  3. I love a man who can admit a change is needed. What you have created so far is wonderful. Can't wait to see the future! Looking forward ti iOS app too. Thanks for all your hard work & dedication. I wouldn't call it wrong or a mistake. This field is ever changing. Thanks for keeping up with it and not abandoning the project.

  4. As as software dev who loves and believes in the promise of HTML 5, this makes me a little sad. Hardware and libraries and support are more mature than when you attempted it. It won't be long before you can do most of the native stuff you needed. At least I can hope.

    With that said, I thank you didn't awesome job on the Android app. It is blazing fast, minimal and, beautiful.

    Can't wait for the Android widget.

  5. I have been searching for months for something like this! I plan to buy the paid version! I just left an all mac ecosystem for the note 2. Im leaving omnifocus to be able to manageeverything via google ecosystem.
    Thanks for all the hard work!

  6. Cameron! I am a big fan of Agile and Lean, you are being just that. Listening to your customers, closely, is exactly what you need to be doing to remain competitive in any market these days with so much changing around us all the time. It takes a village! Kudos to you for listening.


  7. Thank you for all your hard work, tough decisions, and flexibility. My wife and I use Gqueues for almost every aspect of our shared lives and recommend it often to friends. It was hard to hear that many of them tried it, liked it, but then wouldn't commit to a system that didn't have a good native mobile app. I hope that when both iOS and Android apps are up and running, you will see a flood of new GQz converts!

  8. Thank you for writing a native Android app. Having a _good_ mobile app is critical, and you pulled it off.

    Re: "Creating the native Android app was a large undertaking and some complained about the lack of other improvements during the 3 months of development."

    You wrote that well-polished app in only 3 months? Hat's off to you!

  9. Hi Cameron,

    You may have written about this in a previous (or, indeed, future) blog post, but I couldn't spot this in my skim through - did you experiment with a hybrid mobile app using something like phonegap? I'd be interested to know that would make a difference to the issues that triggered your switch.


    1. Hey Chris -

      I did not experiment with PhoneGap or other hybrid approaches. Once I acknowledged the HTML5 app wasn't a satisfactory solution, I decided the best way forward was to make true native apps that would actually meet my customers needs instead of cutting corners.


  10. The right decision.

    I stopped using GQueues, despite being a pro user, because of this. Now, I am back to try it up and perhaps sign up for pro as well. I would never do that without the native Android and iOS apps!