Native vs. Hybrid App Development
First of all, I propose to find out what a hybrid app is and what the difference it has from the native one.
The native application is developed in the language proposed by the developers of a mobile platform. For example, there is a choice between Kotlin and Java for Android solutions development, and for iOS app creation, one can select Swift or Objective-C. Through these languages usage the developer gets direct access to the platform’s functionality — the SDK.
The hybrid application in its turn uses the web programming languages that are executed in the browser. They may be something like Cordova, Ionic, Xamarin, NativeScript or React Native, it’s one of the most popular.
Consequently, the runtime environment for hybrid applications is different: WebView for Android and WKWebView for iOS. When running, the hybrid apps create their own components, which look like native ones, have similar to native behavior, but in fact it is a web application that attempts to access the API platform through a variety of plugins, modules, bridges. These modules are written in native code and call platform functions directly.
Why may hybrid application development be attractive:
- Business logic integration.
- Same application behavior on different platforms.
- Smaller development team.
If we look at it in more detail, the first and the most important thing that draws attention is the simultaneous development for two platforms. Since the application runs in an isolated environment, the render of the components and the interface accordingly will be performed by the browser itself in accordance with the platform components. In theory, this should allow faster implementation of the new functionality, since the new code will run on several platforms simultaneously.
Another important aspect is that the logic of functionality fulfillment is the same since, in fact, it’s one and the same code. The displaying of the components, interface elements and further data processing will be the same on all platforms. It’s vital to remember that in this case, it’s important not only to scale functionality but to correct the possible errors in the existing functionality and business logic as well.
The development team may be decreased since there is no necessity to have different teams for Android and iOS. It’s enough to have a team that has experience in the mobile app development on the chosen technology stack.
At the first glance, the cross-platform app development and the usage of the hybrid solutions have serious advantages, however, disadvantages should also be taken into consideration:
- Direct dependency injection on the side modules.
- The difference in the conceptual and architectural approach to the functionality on different platforms.
- Target platforms updates.
- Problematic implementation of the new functionality.
- The budget for development.
- Weak deadlines.
The necessity to use various plugins or bridges creates problems during the usage of specific functionality. These plugins can utilize not the most up-to-date platforms, have challenges of the outdated features or some functional blocks which do not work at all. We have to understand that this is an unevident dependency injection on not only functionality but on the potential bugs from other developers.
It’s essential to realize that though business logic will be the same in the app, the implementation of the interface and applied features will differ. Android and iOS have, for instance, quite different conceptual and architectural approaches to the work with the background processes and push notifications processing. It results in the necessity to create an additional code, which should adjust the logic of the app execution.
When global сhanges to the platform user interface take place, these changes won’t automatically reflect in hybrid apps. The developers will then need time to implement certain changes in design as well as in the behavior of the UI components. The recent update of iOS 13 can be a perfect example in this case, it brought great changes in the user interface. If the native components had been used there would not have been any problems.
Special attention should be drawn to the possible mistakes in the modules work on specific platforms. During the work with video recording and its further rendering, for instance, one may face the situation when there is a mirror imaging on one platform and normal display on the other.
Problematic implementation of the functionality is also possible. While the problems are unlikely to set in with map or points on map integration, the payment system integration or popular in some parts of the world social media networks support may cause difficulties. To integrate such functionality, bridges should be created for each platform. In other words, you should realize such functionality support natively for each platform and create middleware for the technology chosen. It’s essential to keep in mind that in course of the time, the changes will take place in such functional interdependencies, and they will require changes in the newly written modules.
Cost. It’s one of the main aspects important for the client. Though the development team in such projects is smaller, the expertise of each member should be more extensive. A specialist should not only know the target technology but native programming languages as well. It’s necessary to implement changes in the existing modules and possibly write new custom ones. The hourly rate of such experts is usually much higher than the native developers’.
The terms of development. Taking into consideration the constant development of target platforms and setting certain additional restrictions by each platform, it becomes more and more difficult to make estimations as to the terms of a certain functionality implementation. Besides, the risk which will be included for the client during the project evaluation may exceed the cost of the functionality development several times.
The learning curve for the new developers of the extensive apps will be quite high and much more time will be needed to add new features or alter the existing ones, not speaking about the risks of the increasing number of errors subject to the difficulty of the project itself.
To draw a line, I’d suggest to always carefully evaluate the difficulty of such a project, and estimate the cost and scope of it in detail. To my mind, the disadvantages prevail to a greater extent over the possible advantages of the hybrid app usage. It’s important to warn the clients against the situations when the half-ready product would be re-written from scratch on native technologies because of some blockers or inability to realize certain functionality in a hybrid app. Native applications are much easy to support in the long-term projects.
Originally published in Stfalcon.com.
