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.