Hybrid apps, not as straightforward as you think

I recently had the chance to go out of my comfort zone (server side development) at Skype and work on some client side mobile features. One of the topics that came up a number of times is whether a certain feature should be implemented in pure native code or whether it can be written as a hybrid feature using a mix of native and HTML/JavaScript code.

Developers are very religious about this topic. (It’s interesting how developers feel more religious about topics that they can fully understand, compared to topics that are hard to understand, but this can be another blog post). While some want to implement features in native code fully, others prefer to abstract away as much as possible using HTML/JavaScript as a common language and use technologies like PhoneGap/Cordova to figure out the details on how to run that code on various platforms.

As someone who used to work at Adobe, this reminds me of the discussions around Flash on mobile. At some point, Flash provided a plausible implementation of “Write once, run everywhere” myth on mobile phones. Writing code once and letting a common runtime like Flash to figure out how to run it on various mobile platforms was indeed a nice idea in theory. In reality, every mobile platform is different and they simply could not be abstracted away in a common runtime like Flash. That’s what I learned and that’s why I now believe that “Write once, run everywhere” is a myth.

Even if you don’t believe me that “Write once, run everywhere” is a myth, and even if we assume that technologies like Flash and PhoneGap/Cordova provide excellent frameworks and performance across all mobile platforms, I still think that developers should still be worried about hybrid apps.

Mixing different languages is hard and it increases the complexity of a project by tenfold. When you have a pure native app, you know exactly what IDE to use, what language to learn, what tools to use. You know exactly how to debug and how to test your application. Every native mobile platform has its known and accepted tools for the job.

When you start mixing native and HTML/JavaScript, everything goes out of the window. All of a sudden, you need to worry about this trojan horse sitting within your native code. Testing becomes difficult, debugging becomes difficult, profiling becomes difficult, code coverage becomes difficult…With pure native code, you’re constrained by the boundaries of that environment and that’s a good thing to have, so you can focus on your application. With a hybrid app, you end up spending a lot of time going back and forth between two programming models. It’s not impossible to navigate through but you need to ask yourself: Is it really worth the effort?

Don’t get me wrong. If you need a certain feature and if the most feasible way of doing it is in HTML/JavaScript, then by all means, go ahead and do that. I’m not against the idea of hybrid apps per say. What terrifies me though is how lightly the hybrid vs. native decision is made sometimes. It is not supposed to be an easy decision. While mixing things up, you need to be aware of the complexity you’re introducing on developers and testers. If the complexity outweighs the feature you’re introducing, you need to think again. If you’re going to create a hybrid app, you really need to consider that decision carefully and make sure you’re getting enough back from your hybrid feature for all the complexity it’s introducing.