Hybrid vs Native app development: What Should You Choose?
Note: This article was written with the help of our front-end development expert Alex Autem.
10 years since the introduction of the Apple App Store and we now have over 2.2 million apps available on this store alone. Because this is tech, and everyone is always looking for a better way to do things, the tools used to build these apps have naturally grown in number and functionality.
In some regards the most important(and most debated) of these advancements is the ability to build hybrid mobile apps. There are some devout believers that native is the only way and others that believe you’re just wasting time if you’re not going hybrid.
For those of you that have no clue what I’m talking about, don’t worry. In this article I’ll explain what hybrid and native means, which side you should choose, and why this topic may or may not even be a debate in the coming years.
Let’s get started.
Native Mobile App Development
When referring to native mobile apps, all that really means is an app is built specifically for the platform that you want to run your app on. If you want to deploy an App to the App Store you would develop the app using Swift – Apple’s development language. On the other hand, if you want to deploy that same app to the Google Play store, you would need to build it in Go (short for google) – which is the primary app development language for android.
If you’re thinking this makes native apps a time consuming endeavor, you’re not wrong. But more on that later.
Of course there have been developments over the last ten years that have made building apps natively a lot faster, more efficient, and powerful on each platform. For example, in 2011 Google launched the language Go, in 2014 apple launched their official development language swift, and there are tools like Xcode(apple) and Android Studio(Google) which have definitely streamlined native app development.
Hybrid Mobile App Development
These ‘mobile development frameworks’ were created shortly after the release of the iPhone by a company named Nitobi, the creators of PhoneGap. Right when PhoneGap (an open-source project) started to pick up some steam it was acquired by Adobe in 2011, taken private, and then re-released to the open-source community as Apache Cordova.
As you can see this is when hybrid apps really started to become a mainstream topic:
This leads us to consider, why would you build an app natively?
Hybrid vs Native App Development
When it comes to this argument it seems as if the benefits of hybrid are the same negatives of native, and vice-versa. So to give you a better idea of whether you should go hybrid or native, let’s take an honest look at both of them.
Starting with native, the most obvious argument for going this route is that you are using the intended language for the platform you are running your app on. Android apps are built using Go, and Apple apps are built using Swift. So if you really want your app to be the best of the best – absolutely pixel perfect and top-notch performance – then you should go with Native.
But, keep in mind this ‘top-notch performance’ probably won’t become recognizable unless you are building a very complex app with some heavy loading graphics. Just think, even Uber is built hybrid.
So what are the downsides of going native? The cost. Just think about it… Imagine if you were going to build an app on iOS using Swift, and the development was intended to take 1,000 hours total, and you had to had to hire a team of two swift developers. Then in order to deploy it on android you had to hire two more developers that are proficient in Go, and pay for another 1,000 hours! Now you have 4 employees, and 2,000 hours of development just to get your app live on both iOS and Android.
Now take into account that you will need to continue to pay all 4 of these employees to write updates and fix bugs for both the iOS and Android versions. Every update is another few hundred hours for both teams.
Getting into hybrid, the obvious benefit is time. That same app that took you 4 employees and 2,000 hours to build natively, would require 2 employees and only 1,000 hours of development.
(note: this is not exactly true, these things are always different for each project, and the second build will probably be a little bit faster than the first one. But nonetheless it’s a reasonable estimate.)
But if some people still choose to build natively knowing that it will take twice as long, there has to be some drawbacks to hybrid development, right? Yea, kinda.
One of the main concerns around hybrid app development is that it’s tougher to access the hardware and internal device in a hybrid app, like the camera and camera roll for example. There are plug-ins that have been built to solve this issue but they can be buggy at times.
Again there is the performance issue I mentioned earlier, which is often the result of hybrid apps being a bit bigger in terms of file size. Unless your application is massive, this probably won’t have any measurable impact. That is, unless you have an inexperienced team writing extremely inefficient code. (luckily we don’t)
So, what should you do?
Knowing all of this, what is the best route to take? I would have to advise you to build a hybrid app. This is how we go about building all of our apps, and it saves our clients a considerable amount of time and money.
Is this really even an argument anymore?
We never really know, they could release an update tomorrow that proves hybrid apps irrelevant!
About Shane Rostad
Shane Rostad is a marketing manager for TriFin Labs that loves to share his knowledge and learnings about tech through writing. When he's not reading you can find him exploring Florida's parks or loitering in a local coffee shop.