The debate over Native vs Hybrid app development wages on. Each side gaining over the other, leveraging improvements done to their respective technology platforms. Hybrid application development having started out as the underdog in this race several years ago. It has gained leaps and bounds over the years giving steady competition to native app development but the jury is still out on which is better. In this blogpost, we shall look deeper into what makes each of the two better than the other while also examining their shortcomings. Note to reader, this article shall be limited to mobile platforms and amongst mobile platforms, we shall limit ourselves to the top two mobile Operating System (OS), namely Android and IOS.
Sticking to Native App Development
What makes native applications so indispensable? Why do it’s proponents swear by it? And why some of them should continue to do so?
It has always been a known fact that native applications far outperform hybrid applications. Of all the reasons arguing for native applications, performance has always been the hammer nailing down the argument that native applications are better. The simple fact is, apps that perform better, deliver better user experience and user experience trumps all else as the deciding factor for choosing a development technology. Survey have shown that,
“88% of online consumers are less likely to return to a site after a bad experience.” 
Another survey shows that 90% of the users stopped using an application due to poor performance. Performance of an application directly impacts user experience and it’s no surprise that developers would lean towards native application development which delivers better performance. Better performance equals better user experience.
Although the last point is attributed to the developer as a reason for choosing native over hybrid, ensuring a good user experience is the responsibility of the business analyst. A far more pressing reason for developers to go the native way is access to the API exposed by the platform which in this case is the mobile device’s OS. Software Development Kit (SDK) provided by each specific platform allows a developers access to OS-specific API including the device’s hardware. While this can be done in a hybrid application via the Webview, accessing OS specific functionality directly using the SDK would be much faster and less complicated.
If you are developing gaming applications, you should stick with native technology. If you are developing an application that requires communication with device specific hardware such as Microphone, Camera, Ambient Light Sensor, Finger Print Sensor, NFC Sensor, Proximity Sensor, Pedometer Sensor, Accelerometer, Gravity Sensor, and Gyroscopes Sensor, you should stick with native technology. Any application that would require intensive CPU processing, native application would be the way to go.
With that ends the major reasons for which developers would much rather stick to developing native applications as opposed to hybrid. There are of course other reasons that some would point to, such as near native processing speeds and offline support. But these hardly stand to reason anymore and we shall see in the rest of the article as to why processing speeds and offline support are both flimsy justifications for choosing native over hybrid.
Adapting to Hybrid App Development
Besides performance, access to devices hardware and underlying OS-specific API was another reason that most developers would resort to native applications over hybrid. Although it is true that native applications would be the best way to access device hardware, it’s only partially true in that, it’s not impossible to access device hardware via the Webview. Webview expose several API that in turn interact with the device hardware that applications require access to. Geolocation API provides a common interface for locating the device, independently of the underlying technology, DeviceOrientation Event Specification defines several DOM events that provide information about the physical orientation and motion of a hosting device, Generic Sensor API defines a framework for exposing sensor data to the Web platform in a consistent way, Proximity Sensor specification defines an API to monitor the presence of nearby objects without physical contact, Ambient Light Sensor specification defines an API to monitor the ambient light level or illuminance of the device’s environment, Battery Status API exposes information about the battery status of the device. While Web Near-Field Communications (NFC) API and Web Bluetooth are still works-in-progress, hybrid applications have access to almost all of the devices’ hardware that would meet most of the requirements. With so much available to the developer via the web platform, choosing native over hybrid would hardly be an obvious choice.
There are applications that require near native processing speeds such as gaming applications. As suggested earlier in the article, native would be the way to go for such cases. But with the emergence of Webassembly and Cloud Gaming, there is argument to be made otherwise. Webassembly is a fairly new technology. It enables web developers to leverage native processing speeds such as that could be achieved by low-level languages like C, C# or Rust. With such processing speeds, a developer could very well develop games and other Cpu intensive applications without the need for a native application. Cloud gaming services on the other hand takes out the need for high processing power on the local device at all. The game runs on the cloud and served to the user as Gaming-as-a-service (GaaS) over the network.
Offline support would be one other reason to choose native over hybrid. But a relevant question to be asked at this point would be, how many applications today are actually offline? Truly offline. Just about every single application requires registration at startup which means, they all need network access at the very least at the startup. Another interesting trend in mobile application development to be noted is the emergence of Mobile Backend as a Service (BaaS or MBaaS).
Mobile Backend as a Service Market 
This trend lays emphasis on the obvious fact: Data generated from mobile applications has surpassed what would be reasonable to store on the local device. The burgeoning of data has lead developers to push all the data onto cloud storage. This means that applications are rarely offline except in cases where the application’s offline capabilities are it’s selling point. Almost all applications make periodic network calls for various reasons. This begs the question, are native apps entirely offline themselves to make claims that native provides better offline support. In addition, web technologies like Progressive Web Application (PWA) and Service Worker provide offline capabilities to applications making them interoperate between online and offline states seamlessly.
With several of these myths about native applications being better than hybrid applications debunked, there are several benefits to be reaped from hybrid applications as opposed to native applications. First and foremost being, single code base for multiple platforms. Since a standard web browser is essentially the platform that a hybrid application runs on, any mobile device that has a web engine can run the hybrid application, which means a single implementation of the application will work on all mobile platforms – single code fits all. This clearly makes hybrid applications a far more resource-frugal approach.
Another major benefit that a hybrid application enjoys in comparison to native applications is circumventing platform restrictions and regulations. An example for this would be the recent litigation battle between Epic Games (Fortnite) and Apple . Platforms require that in-app paid functionality has to necessarily use In-App Purchases (IAP) which is basically a platform specific paywall. If you wish to provide content within your application to your users at a premium, you’re required to use this paywall which in turn will cut a percentage of the payment as commission. This regulation of payments within the application may not be something that the developers would be willing to grant. A hybrid application on the other hand is not subject to such restrictions. In fact a hybrid application can function without the need for a platform specific app-store at all.
Application updates is one area where hybrid application clearly wins out. Updates can be pushed for hybrid applications which the Webview and the registered service worker (if any) will ensure that the latest version of the application replaces older version. All this without the need for an app-store which means the user need not be manually involved in the application update process. This is a benefit that has largely helped us at Bytize especially with our PosBytz line of products. A look at Facebook and Instagram’s timeline of changes clearly points to how frequent changes to the product is necessary to be able to cater to all customers. Especially when providing a B2B product to other businesses, the number changes and customizations requested by customers is incredibly high. With hybrid applications, such updates will seamlessly be integrated into the customer’s device without interruptions to business. The same cannot be said about native applications.
In conclusion, it is fair to say that native applications can no longer be considered an obvious better choice in comparison to hybrid applications. A lot of the reasons for which native applications were considered better than hybrid applications simply no longer hold true. Some use cases would still warrant using native applications while some use cases would benefit from hybrid application. An impartial assessment would be that hybrid applications are gaining ground while native applications are struggling to hold their own.