Rocking with hybrid apps

How we chose hybrid for mobile and results turned out even better than expected

Boudewijn van der Velde
7 min readJul 23, 2014

At some point a lot of businesses go through a process of deciding it’s strategy for mobile development: web based, native, hybrid, some other cross-platform solution? We did just that about half a year ago.

We decided to go for hybrid (for techies: a mix of Cordova, Angular, Ionic, and custom native plugins) and found that — partly to our surprise — it’s now possible to build native quality apps with hybrid speed of development. For us, hybrid actually comes very close to the best of both worlds. Here’s our story.

Exploring mobile development

First off, this isn’t about how you should never develop native or web apps for mobile. Obviously there isn’t a one-size-fits-all solution and the right strategy depends on things like: app requirements, team skills, budget, business needs etc. This is about how hybrid worked really well for us and why going hybrid might be a better move than you currently think.

What we needed

To understand our process, here’s a little about our company. At TrainTool we enable companies to train soft skills online. Think, for example, employees in sales or customer service that need to be trained on how to interact with customers.

For our mobile apps, here’s some of the key features we needed:

  • Being able to follow a course anytime, anywhere: including theory, different types of questions, feedback from peers and coaches
  • A special exercise where the user sees a short video of an actor and then directly records a response
  • Sync content and responses with a backend
  • Be able to do exercises offline
  • Fluid, (near) native experience to make sure practice is fun and the experience is on par or even better than our existing web apps

Other considerations included:

  • Support a wide range of platforms and devices: iOS, Android, handheld and tablet (yes we really need this, believe me on this one)
  • Our current development team is skilled in HTML5 and Javascript, not in Java or C
  • Less than €50K budget.
  • Being able to further develop and improve the apps over the next years

The native option

For only a little while, we considered native. There were two import reasons why we decided it wasn’t an option for us.

First of all the cost of developing and maintaining the apps didn’t seem to fit our company at this time;

  • Having a big firm (like ArcTouch) develop the apps would easily cost €100K+ (based on quotes I’ve seen of apps with similar complexity).
  • Hiring native developer(s) at our stage was a no go.
  • Contracting native developers. We’re based in the Netherlands where rates start around €65 for native developers so this would go out of budget quickly.
  • Lastly, there’s the option of hiring contractors in low-rate areas like Eastern Europe or India (Polidea is one of the companies we talked to). Rates vary between €20 (India) and €40 (some of the better developers in Poland). Budget wise this might have fit, but considering we wanted to continuously improve and enhance the apps this wasn’t an attractive option.

The second reason is that we feel really strong about the DRY principle. Introducing multiple code bases for client-side apps would introduce lots of repetition of code — at the cost of slower (or costlier) further development and/or degraded consistency between platforms.

A web app then?

So we considered making a responsive web app. Most of the functionality we need would actually be possible with just HTML5. But one of our core features, an exercise where a user is recorded while reacting to a video of an actor just isn’t supported. This day might come (WebRTC? HTML5 camera API on mobile browsers?) but just isn’t there yet. So again, not an option.

Hybrid it is

Hybrid, or at least some cross platform solution was the obvious choice. I’ll be honest with you. I was disappointed. From what I had seen, hybrid apps wouldn’t allow us to deliver a really great user experience. Based on Phonegap and Appcelerator showcases, I didn’t find examples that:

  • perform great
  • look great
  • were stable
  • and connect well to the OS design guidelines

Some ticked some of the boxes. But not all. At this point I know they are out there, it’s just a bit hard to find them. Check out Adds for a nice example. Still, the apps that we did find showed enough potential that we decided to go for it.

Options in hybrid land

Ah yes, more choices to make! Once you decide to go for some cross platform solution, there’s tons of tools, platforms and frameworks out there. Fundamentally I think these are the big lines:

  • Cloud based app builders like Appery.io. Most of them don’t require coding. For us, this wouldn’t allow us the build the app we need.
  • Frameworks that provide an API for both native UI components and device functionality, like Appcelerator Titanium or Appgyver. They promise hybrid apps with native performance. I tried to find the best apps out there and then used them — the Appcelerator showcase is a good starting point. In reality I found that they have a lot of cross platform issues, the apps are often buggy and really don’t perform that well. The Titanium meetup in Amsterdam I attended didn’t change my mind. Overall the level of the apps and community was lower than I expected.
  • Frameworks that provide an API only to access the device functions and rely on HTML for the UI, like Phonegap or Cordova. Based on the apps that I tried (I downloaded a lot of apps built with Phonegap) this route seemed to have the most potential. We decided to give this a serious try and start to build some prototypes — hooray!

Using Cordova (or Phonegap)

If you wonder what the difference is between Cordova and Phonegap, the technology is the same but Phonegap adds services around it (like a cloud build service). In our case we found it quicker and more flexible to build apps locally instead of using the Phonegap build service so we used Cordova.

Basically once you decide to go with Cordova, the tools and frameworks you choose can be anything used for HTML/Javascript/CSS web development. Cordova just launches a index.html in a native app container. It provides a Javascript API to access the device functions (like storage, GPS, camera, etc) from your HTML.

So there’s literally thousands of tools and frameworks to build your HTML based app. Let’s call this out of scope for this article ;). Instead I’ll share what we ended up with and what looked for.

The stack

  • Cordova 3.5
  • AngularJS
  • Ionic — used as CSS framework
  • IScroll — JS library for scrolling
  • Karma — awesome test runner
  • Jasmine — for writing unit tests
  • A custom written plugin in native code — for things we couldn’t do with the existing video/camera plugins.
  • Some custom responsive CSS — adapting UI for different screen sizes.

What we looked for

First of all, based on hybrid apps we tried we realised you basically start with a handicap when it comes to performance and UI. To make a hybrid app appear native you have to make an extra effort and keep it in mind every step off the way. So as we were trying different frameworks and libraries we kept looking at:

  • performance
  • native like UI
  • and maintainability of the codebase for a complex app

The combination of tools we used ticked all of these boxes for us.

So how did it go?

In short: we (and our users!) are really happy with the results. Once we really started developing there was a bit of a learning curve, sure. There are a lot of things to figure out and documentation is not great. Als you have some cross-browser issues, yes. But the overall result was under budget, on time and met the app requirements. To give you an idea, here’s a short video showing the app in action.

https://www.youtube.com/watch?v=vGXvYPuUBPI

We first released an iOS version because generally hybrid apps perform better on iOS and implementation is a bit easier. After we released and tested this app and were happy with the results we started working on the Android version. If you don’t include work on the native plugin, it took about a week of testing/fixing cross-platform issues.

In our case it appeared possible, at least for modern devices (iOS6+ and Android 4.2+) to develop apps with near native performance and appearance with all the benefits of a cross-platform codebase;

  • faster implementation
  • easier maintenance (only one codebase)
  • better consistency across platforms
  • HTML/CSS/Javascript skills are more widespread

Of course it’s not only positives;

  • documentation for building modern, high-end hybrid apps is scattered and scarce
  • there are quite some performance/cross-browser pitfalls, advanced HTML/CSS/Javascript skills are desirable
  • for older devices performance will be noticeably less than native apps

The next step might be that we’ll reuse the same codebase for our web app as well. This would give us one share code base (mostly in JS) with a responsive UI for both mobile, tablet and web. On top of the code base we build native plugins only when we need to.

I’m planning to write up a technical article with more details later. Thanks for reading!

--

--

Boudewijn van der Velde

Excited about building digital products that matter. Currently on a mission with TrainTool to help people improve soft skills online. Tweets at @boudewij