Mobile app development: hybrid vs native apps
If you’ve ever considered building a mobile app, you’ve no doubt run into the question of hybrid versus native.
At Silverstag Consulting, we have done our fair share of experimentation when it comes to mobile development. We have delved both into the native and hybrid ecosystems, and have come out with a better understanding of both. In this article I’ll be unpacking what they are, and which to favour in which situations.
In order for this to be a fair comparison, let’s assume the following:
- You would like a mobile application that runs on both Android and iOS.
- The application you are building does not require heavy computation such as 3D rendering, Virtual Reality, or any complex mathematical requirements — if this is the case, you are almost certainly better off building native (for the time being).
Hybrid vs Native
Hybrid
Hybrid applications use a single framework (and therefore a single code-base) to produce applications for multiple platforms — the most notable of these frameworks being: React-Native, Flutter, Ionic and Cordova. As with anything, each of these frameworks have their own pros and cons and each needs to be considered depending on your own unique requirements. At Silverstag, we prefer React-Native as we have deep roots in ReactJs and choose to focus our efforts in the area of our expertise (in addition to it being performant, maintainable, and well-documented).
The key takeaway is that hybrid applications will attempt to either convert non-native code to native code in order for it to run on the device (best case), or, in the case of Cordova, run the code within a browser on the phone which gets wrapped in an application to ‘fool’ the user (worst case).
Native
Instead of relying on code conversion / translation, native applications are written in the language of the device’s operating system. In Android’s case this language is Java, and in iOS’s case this language is Objective-C or, more recently, Swift.
The benefits here are generally performance related. Developers also have direct access to all of the device’s native capabilities such as Bluetooth, GPS, NFC, etc. whereas hybrid applications rely on libraries being made available in order to access these features. This could result in significant complexity within the app which is completely dependent on the implementation, and in some cases, native libraries are not available at all.
The comparison between hybrid and native mobile applications can find its root in a single, important difference:
Single code base vs Multi code base
Hybrid development allows for the development of mobile applications targeting multiple platforms using the same code base — this is because the code is written in a single language. At build time, a compiler will translate the code written and produce a separate application for both platforms. In contrast, when developing native applications, each platform requires its own standalone version of code. This presents a few challenges:
Manageability
Maintaining multiple code bases for the same application (one for each platform) has some major drawbacks:
- Each feature must be developed twice. What is developed in Android must again be developed in iOS — there is no code or tool sharing.
- Two development teams, or in the best case scenario, one development team which can develop in both languages. Should the ‘two development teams’ approach be taken, a huge amount of inter-team coordination is necessary in order to ensure that both teams completely understand the requirements otherwise there is a risk of the same feature producing different results on each platform — communication is paramount. If instead we have a single development team, context switching between the coding languages can cause major delays which negatively affects productivity, and the lack of a single focus could result in more bugs in production.
- Two backlogs. It is extremely unlikely that both teams produce the same output regularly. This may result in the need to hold back development on one platform while the other catches up, or even having to manage bugs present on one platform and not the other. Bottom line — more management more of the time.
In order to avoid this, many businesses tend to manage their Android and iOS applications separately — at any given in point in time, feature A could be available on Android, and feature B available on iOS, but neither having all features in common simultaneously. As development continues, these differences tend to become exacerbated, resulting in a continuous game of catch-up by one, or both, of the development teams.
In contrast, hybrid development allows a single feature to be developed once, by the same team, as the code required for development is essentially the same. More often than not, bugs experienced on the platforms are mainly aesthetic, making them quick to track down and easy to fix. One code base managed by a single team results in less ambiguity and ultimately less management effort.
Time
As mentioned above, single features may need to be developed twice. In an ideal world, both of the development teams will be deadly efficient and churn out features on time and within budget — unfortunately, this is very rarely the case.
Chances are one of the teams will be more efficient than the other, causing frustration between the two teams and a managerial nightmare in deciding what to do with the faster team while the slower one catches up. This could cause considerable delays in getting an app to market, negatively affecting the ability to capitalise on first mover’s advantage.
Once a feature has been developed (and tested) using a hybrid technology however, it can be rolled out to both platforms simultaneously — no waiting, no catch up. Technologies such as React-Native also have the advantage of using web components easily within the mobile framework, as the majority of the code remains as is with only minor tweaks to make it compatible — this allows for tried and tested code to be ported quickly and easily.
Cost
Native applications typically cost more than their hybrid counterparts due to the following:
- Time: Time is money, the greater the time, the greater the costs.
- More resources: Two teams, two project managers, more licences, more deployments, more monitoring — you get the picture.
- Scarcer skills: Native applications require more scarce skills than hybrid development and hourly rates are typically at a premium. As an example, React-Native is developed in React which is a widely used web framework — it takes significantly less time to up skill a React developer to develop in React-Native than it would take to up skill the same developer in native Android or iOS.
Testing
Hybrid applications require no testing whatsoever. Just kidding, they require just as much testing as any other application — and it is highly encouraged.
The only benefit hybrid applications have over native in this case is, once again, the fact that tests can be written once for both platforms. There are obviously unique cases in which tests need to be expanded to cover common gotcha’s, but in general, a single test will be applicable to both platforms.
Native requires the maintenance of two separate sets of tests for each platform, and the split code bases could result in one platform having more coverage than the other.
Where Native makes sense
There are situations in which hybrid development would absolutely be the wrong approach. Applications that are highly computational in nature will experience considerable performance loss if not developed natively — this is one area in which native outperforms hybrid applications and I am not contesting this. Hybrid applications are improving in leaps and bounds, but there is still a lot wanting in this area.
Another consideration is whether or not your application requires cutting edge native APIs. Although the hybrid community does its absolute best to keep up with native development, there are definitely points in time when native APIs just aren’t available in the hybrid community yet. If you require these APIs as soon as they are released, or development of a particular feature is dependent on a particular API that isn’t yet available, it may make sense for you to skip the wait completely and build out native from the start.
Conclusion
If you are considering building a mobile application for your business, in our experience, the benefits of hybrid development outweigh native substantially.
Hybrid beats native in terms of time, cost, and manageability as outlined above and this is true for most common business needs. This is not to say that native is not the right choice for your business — you need to understand your own unique business needs and weigh up the pros and cons of each approach.
Performance is typically outlined as a differentiator between hybrid and native applications, but the reality is, unless you are building an application that requires higher than normal performance, the performance difference is negligible.
Modern day technology is slowly bridging the gap between mobile and web development and there is already huge progress being made towards a single code base producing not only mobile applications for multiple platforms, but for websites and soon PWAs (Progressive Web Apps) too — this is another consideration to take into account when considering application development.
Both native and hybrid applications are constrained by the deployment limitations of their respective app stores. Hybrid development still yields an apk and an ipa at build time which makes it possible to deploy your application on the Google Play Store and the iOS App Store — this is something that you cannot get around unless you plan on distributing your application privately.
Has this post got you fired up and wanting to finally build that mobile app or website for your business that’s been on the back burner? Drop us a mail at hello@silverstag.io and let us help you get it done, properly.
