What exactly is hybrid app development? As defined by Sitepoint, "Hybrid applications are web applications (or web pages) in the native browser, such as UIWebView in iOS and WebView in Android (not Safari or Chrome). Hybrid apps are developed using HTML, CSS and Javascript, and then wrapped in a native application using platforms like Cordova" (source). The main advantage of hybrid apps is that they allow developers to develop an app for multiple platforms at the same time - one codebase for several platforms.
In this article we are going to outline some of the costs that are not immediately notable when deciding to develop your mobile application using a hybrid solution.
The first major cost, one that might not be immediately apparent, is that of time and money spent learning a hybrid tool. Often when estimating the amount of time to develop an app, teams will dismiss the amount of time required to learn the intricacies of a hybrid tool. The idea of "one codebase for several platforms" can be all the convincing a team needs to go down the hybrid route.
It is important to understand whether the investment of learning a hybrid tool is worth it. Some questions like "will this tool exist in a year?", "how many limitations will I have to work around?", and "how good is the interface of tool X compared to Google's Android Studio or Apple's Xcode?" should be of top importance when determining if a hybrid solution is appropriate.
Moreover, time spent learning a specific tool might not be a good investment. For example, are you likely to use this particular tool in the future with another project? If not, it's important to note the skills learned by using this tool may not help you in developing natively for either iOS or Android further down the road.
Performance is likely the biggest cost you will pay by using a hybrid solution. For apps that require a specific level of performance (for example, an app that relies on fast interaction or immediate response), a hybrid solution is often not the best choice. In some cases, the hybrid solution will simply create a web view to an HTML / JS solution which will not utilize the platform's native APIs, and thus, be less performant.
Depending on the particular solution, access to all of the hardware (such as the camera or various sensors, or low-level APIs) may not be possible. This means that a hybrid solution often doesn't have access to the same libraries as a native solution might.
It is important to determine early on if your app needs to be performant or not. In the case where it does, it might make more sense to go down the native development path.
Another area of potential cost is in making the hybrid app "seem native." There are a number of differences between iOS and Android. For example, in many Android apps there is not a "back" button, whereas, in an iOS app it is required. Also, on Android often times the tabs (in the YouTube app for example) are near the top but on iOS they near the bottom. An extension of this is overall feel and design. On Android, Material Design is often used in apps. However, on iOS, Apple sports Human Interface Design guidelines.
Since the two platforms differ in terms of UI and UX, time must be spent making the app fit with its platform. Depending on the complexity of your app, the time spent on making your app "seem native" on both platforms may exceed the time it would take to actually develop natively.
While it is somewhat true that only one code base needs to be managed when using a hybrid solution, as mentioned above, cross-platform limitations may add a few kinks to that. For example, some particular changes you make for the iOS version of your code, might become obsoleted by a change in either the hybrid tool itself or by an OS update. In this case, you would need to update all of the "one-offs" you made for iOS, which may be very difficult if you haven't tracked these.
Additionally, if one of the platforms changes their design guidelines, you must be willing to invest time and money into updating the look and feel of your app.
Some hybrid solutions have not been around for very long and are especially suspect. These tools might be a dangerous choice for making an app that will be around for a long time. If the hybrid tool loses support after a few years, you will no longer be able to support new OS versions for your app. In the worst case, you might have to switch to a new hybrid tool or develop natively after all. Android Studio and Xcode, in contrast, will always support Google and Apple's newest operating system updates, respectively.
While this article points out many of the negatives associated with developing a hybrid app, it's important to note that there are several cases where a hybrid app is acceptable and possibly preferable. One such example would be a simple static app requiring low maintenance which needs to be offered on both iOS and Android. Since the app has no performance requirements in this case, it makes financial sense (assuming there is little cost in learning the hybrid tool) to use a hybrid tool to develop the app.