Hybrid vs. Native — Here is how you can choose one over the other…
There is no denying it, hybrid mobile development is booming and becoming the main option when considering developing a mobile application due to the lower costs and faster development time. But what are the implications of going for a hybrid approach instead of a native one? What are the advantages and disadvantages of choosing one of the approaches?
At Pixelmatters, we’ve worked with both approaches and we would like to share with you our experience and opinion considering different important verticals behind every mobile application. These verticals will influence the final decision based on the product’s requirements and vision.
Performance 🚀
Without a doubt, one of the more important aspects of any mobile application is performance. Users want fast and reliable applications capable of running on any device available without any problem. Slow internet connections shouldn’t also compromise the application’s speed when on the subway or using 3G/4G connections.
How most hybrid frameworks work is by creating a bridge that connects the frameworks’ code to the native Android and iOS code. Take React Native for example. While the development is done in React Native language, the framework then executes the React Native code by calling the equivalent on the native’s OS code. Having this bridge to connect them will create delays and constant communication between both, generating slower applications in general. A trained eye can identify when an application is native or hybrid just by going through a couple of screens and checking how the navigation flows. This brings us to the next vertical, UI/UX.
UI/UX 📐
iPhone users want the iPhone’s look and feel and Android users want Android’s look and feel. If you have a hybrid application that does not have the same structure and interactions as any other native application, users will feel confused and displeased. It’s important to keep the user as engaged as possible by designing and developing a UI that is consistent with the OS, as well as maintaining the UX that the user expects.
In the earlier stages of hybrid development, frameworks were lacking this very important vertical. They offered bad UI and UX solutions, having the exact same look and feel for both Android and iOS applications. This is now all part of the past as hybrid frameworks started to evolve and invest more in keeping the natural look for each platform. Components like navigation and tabs now look exactly as they should on both platforms.
Nonetheless, hybrid applications will still share the same custom components with both platforms, meaning that apart from the global look and feel of the application, the screens and custom components will still look very much the same. You can still use hybrid and have different components for each platform, but this will have an impact on the applications’ size and performance. A better solution could be resorting to native development, but the time invested in design and development will greatly increase. This takes us to the design and development time vertical.
Design and development time ⌛
Probably the aspect that more impact has in defining the approach to take is how long it will take to design, develop, and deliver an application. Hybrid is a clear winner here. You have a single design and a single codebase to serve two applications, but there is also a very important topic that developers tend to forget which is maintainability.
It’s true that building a hybrid application top to bottom takes less time, meaning that the cost will be greatly reduced and more accessible to most clients. But after delivering an application, it must be maintained and updated to keep compatibility with prior and newer OS versions, as well as keeping the application safe with important security patches. As most hybrid applications are developed with node under the hood, most of the external dependencies come from an immense bucket of node dependencies that are in constant update, forcing developers to stay vigilant.
On the other side, native applications work with a tighter and smaller community, less susceptible to security exploits, and with fewer updates, meaning that the app will require less maintenance.
Speaking of security , let’s jump to our next topic.
Security 🚓
Nowadays, reverse engineering an application is fairly easy and accessible to most internet users, and let’s face it, there is no flawless way to protect your application. Important keys can be discovered and used to access critical information about the application and its users.
However, native applications already provide great solutions to deal with security issues by using methods like encryption and obfuscation of code without developers having to do extra work for it. If developers want extra security there are also native tools that bring that extra layer of security into the application. Local storage is also better handles and configurable using native code, as it’s more connected with the OS, offering more implementation options.
Hybrid frameworks don’t offer the same level of security, and most of the time we need to resort to external third parties to do the job for us which can be like a two-edged sword. Let’s talk about that on the next topic, third-party services.
Third-party Services 🔧
There are a ton of third-party services available for hybrid development each offering different solutions for the same problems, giving developers a lot of options. This will greatly reduce development time and give the application a service backed by a big community that constantly updates and improves those services.
The only downside comes when these services don’t offer all the features that you are looking for and you are left off with three options: 1. Find other services that fulfill your need, at the risk of compromising other features, 2. Workaround the service, creating more boilerplate and have your code coupled too much with the service, 3. Go with native and implement the solution yourself, but this will also have an enormous impact on the development time.
Furthermore, most of these services offer a bridge to connect hybrid applications to some native features like biometric authentication, NFC, notifications, or others, and in many cases that integration is not compatible with all the different devices and brands available, meaning that a lot of bugs will appear. If you choose native development you have more control over those native features and the ability to adapt and configure to your liking.
Conclusion 🏁
Many verticals might indeed hint that going native is the best option, but the simple fact that hybrid development can take half the time it takes to develop two native Android and iOS apps is a good enough reason to choose it. You will have the extra time to do the necessary adjustments and workarounds to build a flawless hybrid app.
Nonetheless, remember that a hybrid application will struggle to scale and grow as you put more functionalities into it. If you’re planning to build a non-MVP product, consider also going native as you will have more control and scalability options in the near future.
