A Case for Hybrid Mobile Apps
Without doubt, whenever Mobile App development platforms come up in programming discussions, you can be guaranteed that the pros and cons of a Hybrid vs. Native approach will spark a heated debate.
For the layman, Hybrid Mobile Apps are those developed using web-based languages with a “code-once-deploy-everywhere” approach. Native applications are written in the base language understood by the operating system on the device. E.g. Java for Android and Objective C for iOS.
From the start it seems like Hybrid has the advantage, but this approach comes with a performance limitation due to the fact that it’s communicating with the OS through a layer to make it “native”. This is very true, but there are many workarounds that can speed up Hybrid Apps — over the last few years we have seen many interesting plugins and wrappers being introduced to fix the typical latency issues.
In terms of performance, Native will undoubtedly always win. But there’s a catch. A very simple one — cost.
From a development point of view, you will very rarely find a programmer who is equally versed in Android and iOS development — the two operating systems are fundamentally different and equally challenging to master. As a result, many development firms will have specialist Android and iOS developers. This leads to double the input cost.
Our solution? We believe firmly in the Minimum Viable Product (MVP) approach when it comes to developing Mobile (and Web) Apps, especially those that have yet to be introduced to the App Stores.
Many, if not all of our projects involve certain levels of assumptions, all of which look great on the white-board, but haven’t been tested in the hands of actual users. For all we know, the App might be a true game-changer — which would be great if you made your living as a fortune teller — but how do we know for sure?
This is where Hybrid Apps come into their own. The initial development does not require segmented specialists and more often than not, the assumptions being tested can be put into play a lot sooner — which means the App can be put in front of early users much faster.
Typically, in the early days of a Mobile App’s life there will be numerous changes, optimizations and testing new scenarios and assumptions — most of which will come in form the users playing with the App. In this case, Hybrid Apps generally allow for a faster update turn-around time — especially when paired with an Agile development approach (we are massive fans of this approach).
Time to go Native?
After a period of time (every project is different), we will begin to quickly tell if the App is a hit. Be it through user acquisition ramp-up, or positive user retention. Now we know that it’s time to go “all-in” and begin the Native approach. Taking all of the tried and tested functionality uncovered in the Hybrid Phase and committing the time (and cost) towards individually optimised versions of the App.
Sometimes, the Hybrid App will be a great solution in itself. If that’s the case the decision to go Native would be unnecessary — this happens in many cases, especially with Apps which are not graphically intensive of are not relying on too many “Native Features”.