Native or Hybrid mobile app?

Native or Hybrid mobile app?


In the mobile world, programming for an smartphone is divided in native or non-native (i.e. hybrid). But … what is it?

Each OS manufacturer (i.e. Google’s Android & Apple’s iOS) develops their platform to be programmed in a certain way with a certain language using a defined set of instructions, known as APIs (application programming interface). For Android that language is Java, for iOS is Objective-C and Swift. As with the web case, only people who know how to program in these languages are able to understand and develop for these mobile platforms. Java is quite a popular language, Android is very flexible on how to program it. This means the pool of developers for Android is fairly large.

iOS is strict on only allowing Apple’s APIs to program it, and Objective-C isn’t that simple to understand (thus Swift was born). These challenges make developing for iOS tougher, as it demands an specific knowledge, which -in turn- allow developers to charge more for their time, due to the fact they’re in hot demand.

The same as with web, a developer needs only to know one or two languages to make a living. For the mobile world is even more narrow, normally a mobile native developer specializes in either iOS or Android. Why? Because they can afford to! There are developers who program for both platforms, but this is an exception rather than the rule.

One big factor in all this is that when Apple and Google introduce new features to their respective OSs, those features are meant to be programmed/exploited by using their native code. More on that, later.

Web World comes to the rescue

On the web world there is a big resource pool of capable people who doesn’t know neither Java nor Objective-C, because they make their living programming for the Web, which uses other types of languages. So, how can the humanity benefit from this enormous pool of programming knowledge in the web world?

Well, for this case of web programmers who don’t want to, can’t or don’t have time to learn native coding, there are hybrid developing platforms. On these platforms web developers program in web languages (JavaScript & HTML5. Java & JavaScript are different, they only share a part of their name, go figure!), then the IDE (integrated developing environment) translates the web language into native code. As if things were not already messy, native coding also allows JavaScript & HTML5 coding within them, however with limited reach. Ohhh and these IDEs deploy to both platforms, so -ideally- the web developer makes the mobile app by using HTML5 and JavaScript and -in theory- it all works out on iOS & Android. Yeah … right.

The reality is that each platform has its way it sees the world, so even if an app is made with standard HMTL5 & JavaScript, iOS & Android will interpret those differently. This situation raises development cost significantly.

There are many hybrid IDEs: TiTanium, PhoneGap, Meteor (eww!!!), Xamarin, etc, etc. etc. Each one with its advantages and disadvantages. All aiming to provide web developers the opportunity to deploy their work on the mobile world. These platforms work! The devil is in the details.

The details …

The thing is, because hybrid IDEs do a code conversion from HTML5 & Javascript to either native or embedding a web view, their results is not as straightforward as it is programming with native. Another big factor is that hybrid IDEs don’t have direct access to hardware, this could be relevant or not, depending on the app objective.

Benefits of going hybrid

  1. A bigger pool of programmers thus …
  2. Lower cost of development
  3. Deploying for iOS & Android is a little easier, as they share code

The previous is really good under an scenario of building an MVP, simple app, or needing to quickly deploy the first version of the app. Also, developing with a certain IDE forces the project to be married with that IDE, in case of changing the IDE, complete redoing of the app on the new IDE is mandatory (i.e. any possible cost savings are lost).

Benefits of going native

  1. App performance is the best
  2. Complete access to the phone hardware functionality
  3. App compatibility with different and older phone models is easier

Nothing is set in stone, for certain things is easier to go hybrid, for other, native is the only way.

Go Native!

With all this said, if you can, start from the beginning in native. Yes, it is harder, slower and costlier to do it native. On the long run is better. The app will be easier to update and adapt to new version of the OS. Putting new features on the app will also be easier on native than with hybrid. Yes, all the previous can also be made with hybrid environments, however it is not as straightforward as it is with native.

Best of lucks! 🙂

Image source: