Hybrid App v Native

When a choice has to be made between native and hybrid development there are several factors to consider: 

The quantity and complexity of business rules

The complexity of the desired interface

The use of certain phone features such as GPS, camera, etc., is not a problem.

The available budget

Business rules

One of the main reasons for opting for hybrid development is the quantity and complexity of business rules.

Indeed, business rules are very often identical for all platforms (Android, iOS, web). 

For example, in a flight booking application, if there is a rule stating that a user cannot book a flight more than a year in advance, it makes perfect sense that this rule applies to all users on all platforms.

Therefore, if an application has a lot of such rules (and moreover if these rules are complex), it is very interesting to be able to share them between all platforms. This way, it will only be necessary to write and test them once. And when a new rule needs to be added or an existing rule needs to be corrected, it will only need to be done once for all platforms.

This also ensures that the rules are the same for all users.

The user interface

The graphical user interface is platform specific. Each system has its own best practices in terms of interface and user experience.

It can be confusing for a user of a certain platform to find that an application uses rules belonging to another platform.

Hybrid development frameworks use different techniques for the user interface: 

Allow the developer to create his own platform-specific graphical user interface. There is therefore no code sharing for the graphical interface. This is the case of Xamarin for example, which only offers to share the business code but not the interface code (except Xamarin Forms which allows to do both).

Allow to write the interface only once and let the framework do the “translation” to use native components at runtime. This method is however quite greedy in terms of performance. This is the case of React Native for example.

Allow to write the interface only once but instead of “translating” it into native components, the framework will draw the components itself with its own graphical engine. This is much more interesting from a performance point of view but there are fewer components available. This is the case of Flutter for example.

The use of a hybrid development framework can be a good idea if the graphical interface of the application is very simple and its quality is not a priority.

Features specific to the phone

Depending on the hybrid development framework chosen, it may be more or less complicated to access certain features specific to the device used (GPS, camera, gyroscope, etc.).

If the application needs to use a large number of native features, it is probably best not to use hybrid development.

`

Budget

In theory, the budget required to build a hybrid application is less than that of a comparable native application. This is due to the fact that the code is shared between the different platforms and therefore it is not necessary to create the same thing several times.

However, this is not always the case. If hybrid development has been wrongly chosen, the budget required may be higher than for native development.

For example, if it has been decided to use a hybrid development framework when the application has complex graphical interfaces, there may be many bugs specific to certain platforms and devices. As a result, a lot of time is likely to be invested in fixing the bugs and the necessary budget is likely to rise quickly.

Conclusion

In conclusion, we can say that it can be interesting to develop a hybrid application when it contains a lot of complex business rules and the desired graphical interface is relatively simple and its quality is not a priority.

In all other cases, it will be preferable to develop native applications because their quality will generally always be better.