There are many reasons to choose either native or a hybrid technology such as React Native or Flutter. And ultimately the choice depends on organization goals, budgets, ambitions, product roadmap, inhouse skills, timelines and many more factors. So, what is the best choice to make? Let’s start the discussion with some pros and cons of both native and hybrid.
The Pros and Cons in general
Native development
PRO
- - Apple and Google have been around for a while and are likely to stay, this gives your project some security around future proofness.
- - Native apps deliver the best performance.
- - Native development allows developers to access the full feature set of the selected operating system.
- - The user experience of native apps is most of the time better than the user experience in hybrid apps. To the user, the flow is more natural because of each mobile operating system’s specific UI guidelines and standards.
- - A native app must be approved by its respective operating system which assures quality, security, and device compatibility.
- - Whenever Google or Apple deprecates a functionality or enforces some policy, they always provide some alternatives and migration guides, while the 3rd party solution needs time to adapt.
CON
- - Native apps use programming languages which require experienced developers.
- - Expenses are more costly upfront for native apps compared to hybrid apps.
Hybrid development
PRO
- - Only one codebase is needed for common business logic in hybrid apps (but not entire app, i.e., biometrics or UI).
- - Fast development
- - Works good for simple apps that don't use system APIs a lot.
CON
- - Hybrid apps tend to be slower than native apps.
- - You might run into issues that stem from both native systems and hybrid systems, which makes bug fixing more difficult.
- - Hybrid apps are more prone to bugs which can end up costing you more money. When working with the latest features released for a particular operating system, bugs can become a huge concern for hybrid app development.
- - The user experience is different with a hybrid app as you do not want to customize the app based on the platform. You probably won’t implement OS-specific things, because you want to stick as close as possible "one code for all systems".
- - The complexity of creating and maintaining the app increases with each complex functionality it tries to use, i.e., push messaging, secure enclave / android keystore usage, biometric authentication.
Implications of choosing hybrid to consider
When you decide to go for hybrid it is important to understand you have to accept some additional dependencies. Onegini delivers the Flutter or React Native wrapper with our native SDKs functionality included. But let’s take the example of push messaging. A nice feature where the end users get a push message as part of the authentication flow.
In our native SDK, and thus the hybrid wrapper, we make it possible to implement push messages. Native developers can use native APIs to make it work. If you use a hybrid technology, it is not always possible to connect directly to the native API. This means you have two options to make push messaging work: 1) use an available open-source plugin or 2) develop your own code. Although both options could work, this is considered a disadvantage of developing a hybrid app.
1. Plugins
Open-source plugins most of the times are quite secure, but nobody is checking what exactly is in a plugin. There is no quality control on these plugins. The second issue with using open-source plugins is that they usually lag behind on bug fixes and updates. Especially if a hybrid technology, like Cordova and Xamarin for example, becomes less popular it takes longer and longer for the plugins to be fixed or updated after the latest Android and iOS releases.
In some cases, this could even mean you cannot update your app, because the plugin does not support the latest OS version or an important library like AndroidX. At the same time, it can mean that the App stores will not allow you to release a new version of your app, because you are not using a high enough version of the OS version or target a high enough level of the Android API. So, because of a dependency on a plugin you do not control, you can get into a difficult situation.
2. Write your own code
So, let’s look at the other option: write your own code. This way you are in control and know it is secure. But it also means you have to update the code every time Android and iOS make any changes. Depending on the number of changes, this can become quite time consuming and costly.
Although we love to support our customers in the development of their mobile applications, we cannot take away the risk of dependencies on plugins. We cannot guarantee that functionalities will work with plugins.
Okay, but what to choose then?
It would be great if we could give you clear advice. But the best decision depends for a big part on your organization, your goals, your ambitions, available capacity, etc.
From just our own perspective we would have a preference for going native. Mobile is getting more and more important for your users. If you want to give your users an excellent user experience and let them use the latest features of iOS and Android, while also making sure that your app doesn't use untrusted plugins, then native is probably the way to go.
In general, hybrid is a good way to go when you need a simple app. If you consider hybrid, you should be aware of the increased complexity (you need to deal with an extra layer) and the increase of dependencies on third party plugins or the need to create your own code to make all the features work.
In the end the choice is up to you! Of course, we are more than willing to discuss with you which option would fit your business and ambitions. Interested in the solutions we offer with our mobile SDK? Download the brochure and learn how you can offer your customers a simpler and safer digital experience with passwordless authentication.
