Total revenues from the global mobile app market is set to touch $190 billion by the end of this decade. For all the speculations over the growing maturity of this industry, the fact remains that mobile apps are still growing at exponential rates – and more & more new mobile technologies are coming into the picture. From a developer’s perspective, the options are pretty much clear – (s)he can create native (platform-specific) apps, hybrid (platform-agnostic) apps, or mobile-optimized, responsive websites which deliver most of an app’s utilities.

In 2015, native technologies were being exclusively used by around 20% of all app developers. Cut to 2017, and that figure had already fallen to below 3% – thanks to the rapidly proliferating popularity of hybrid applications. It can be reasonably estimated that, on average, 3-4 out of every 10 developers will start to work exclusively with hybrid technologies (giving up on native applications) within the next couple of years or so. In the following native apps vs hybrid apps debate, we focus on the respective advantages and probable issues of the two app development methodologies:

1. Single platform vs multi-platform

   Native mobile apps are built for single mobile operating systems (iOS or Android). For separate mobile OSes, separate versions of the app have to be created. Native applications can typically access all the functionalities of a specific device, without any glitches. Hybrid apps, on the other hand, are created with standard code languages, and are meant to run on multiple operating systems. While plugins are available for hybrid apps, their customizations are not likely to be at par with native-built apps.

Note: Developers have to use Swift or Objective-C for iOS programming, and Java or Kotlin (in rarer cases) for Android development. For making hybrid apps, C# or Javascript (with HTML5) is commonly used.

2. Frameworks and IDEs

   Depending on the precise type of app that has to be made, developers need to be familiar with the corresponding integrated development environments (IDEs), frameworks and platforms. Developers working on the Apple platform, for instance, need to have relevant experience of working with Xcode (latest version: Xcode 9.4.1) – while Android developers have to be conversant with all the functionalities of Android Studio (latest version: Android Studio 3.1.3). If you wish to make hybrid applications, however, a completely different type of expertise is required – with tools like Facebook’s React Native and Microsoft’s Xamarin. It might be a stretch to refer to the hybrid platforms as ‘tougher’ than the native IDEs – but they present a separate challenge for app-makers.

Note: Hybrid apps typically have a native shell that uses Webview to pull in the code (the shell can also be downloaded). The other important part of these apps is the back-end coding, done with Javascript or HTML5 or CSS.

3. Are hybrid apps cheaper?

   To start off with, hybrid apps are generally less costly, and less time-consuming to build than pure native applications. However, there is a catch over here. The greater the degree of customizations implemented on a hybrid app, the higher the costs are likely to rise. In the long-run, native apps might end up being the more cost-effective propositions – thanks to the higher degrees of personalization options and the superior user-end experience (UX) they deliver. Let’s just put it this way – developers who have the biggest focus on quality should go with native apps, while those who wish to generate the maximum value in a limited time can opt to build hybrid applications.

Note: Hybrid mobile apps can also be viewed as a combination of responsive web apps and native applications.

4. Preferences of end-users

   Delivering optimal user experience is the name of the game for any service provider at present. While native apps do have more natural design flows (and as such, are likely to provide better user-experiences), there is little to choose between them and hybrid applications in this context. In fact, all that final users look for is how well an app performs on his/her device, and whether or not it meets his/her expectations. Provided that the development has been done with due care and expertise, it does not make any difference to the user whether an app has been made with native or hybrid technologies. More often than not, it is pretty much impossible for a random smartphone-user to find whether an app is native or hybrid.

Note: The focus should squarely be on identifying the requirements of target users, and creating apps accordingly. Both native and hybrid apps can fit the bill, depending upon the situation.

5. Development Cycle and Resource Usage

   Apart from being cost-saving propositions in the short-run, hybrid apps also have significantly shorter development cycles than fully native applications. Typically, native development requires higher amounts of manpower and technical resources as well. Since basic web technologies are used in a hybrid environment (like HTML or CSS), they are generally easier to build as well, than their native counterparts. A rather common strategy of many app developers is to go the native way for very simple apps, and consider using hybrid development frameworks (Xamarin, PhoneGap, Ionic, React Native, etc.) if and when that app becomes popular and has to be made available on other platforms.

Note: Native apps require separate coding to be done for each separate platform. Hybrid apps, on the other hand, are made on the ‘write once,run anywhere’ principle.

6. Performance factor

   In terms of speed and micro-level performance metrics, native apps still hold all the aces, by virtue of their more customized designs. While hybrid applications are becoming more and more user-friendly over time, they are still some way off from matching the speed and performance of completely native apps. In addition, developers can rest assured of full access to native APIs (application programming interfaces) for native apps. The degree of API access for hybrid apps is lower. Since hybrid apps need to record web technologies for optimal performance, they do not quite deliver that ‘right feel’ – something that is the USP of native apps.

Note: The functionality of hybrid applications can run into problems if high-level device interactions are required. There is a limit to what native plugins (which manage such device interactions) can achieve.

7. The learning curve

   While it would be an exercise in futility to find whether native IDEs or hybrid frameworks are ‘easier to learn’ – it can be stated that the learning curve for hybrid app development is comparatively less steep. Once a developer gets the proper hang of a framework (say, React Native), (s)he can start making apps for multiple mobile operating systems. Native app development, however, requires full proficiency with the tools and techniques of each platform. That typically takes considerably more time. Not surprisingly, the time to market for native apps is, on average, quite a bit higher than that of hybrid apps. From the earnings perspective though, native apps offer separate financing streams for the different platforms. All the ROI from hybrid apps is channelized through a single stream.

Note: Development of both hybrid and native applications requires stable internet connections – although this requirement is greater for the former. In a native scenario, internet is required for the API-client applications and for updating a particular app.

8. Overdependence on plugins and libraries

   This is something that holds hybrid apps back somewhat. These apps are heavily dependent on external frameworks (Ionic, Cordova) as well as on native plugins. The more plugins are added, the more complex the overall development process becomes. It might also happen that a particular framework/library version is not in sync with the platform – and performance glitches can crop up as a direct result. Native apps have no such dependencies, and hence, they offer a more consistent performance assurance. The availability of native SDKs is a big factor in this regard.

Note: For high-end gaming applications (3D/HD) that require heavy graphics, native development is the correct approach. Hybrid technologies might not be able to handle intensive animations rendering and other performance requirements satisfactorily.

9. The security factor

   Well over 22000 malicious mobile applications get blocked everyday. There are multiple channels via which both native apps and hybrid apps can come under attack – right from code injections and poor implementation of SSL, to data leakes, problems in data storage and reverse engineering. However, hybrid applications do have an extra risk layer – since they have external tools and frameworks for coding. Also, the developer ecosystem for native mobile applications is still much stronger than that of hybrid or web apps. Irrespective of whether separate app codes are maintained (native) or platform-agnostic single code base is used (hybrid), developers have to keep an eye out for probable security threats and manage them effectively.

Note: In a recent survey, it was found that, when faced with adverse app experiences, 48% users were likely to reduce its usage, while a bad word-of-mouth publicity might be started by 31% of them. It’s all about ensuring that final customers are not put off by any feature or shortcoming of an app.

     10. Web technology vs specific technology

The entire native apps vs hybrid apps debate boils down to this. While specific technology is used in native applications (Swift for iOS apps; Java for Android apps), web technology (CSS, Javascript, HTML) lies at the heart of hybrid mobile apps. It also has to be kept in mind that all hybrid apps run in WebView – which can cause certain performance issues as well, if there are any problems with widgets. In terms of performance acceleration capabilities based on the underlying hardware, both types of apps are more or less at par.

Note: Native apps are usually fully compatible with other applications installed on a device. Compatibility issues are more likely to crop up in the case of hybrid applications.

     11. Updating an app

This process is decidedly simpler and quicker, when we are talking about hybrid applications. Everybody does not set up their phone apps to be auto-updated when connected to wifi. Changes made in a native app are reflected ONLY after a user updates the app from the store – and repeated reminders for updation can end up irritating customers. In the hybrid development scenario, it is not necessary to update the apps in the stores. Modifications made on app pages that are loaded directly from the server get displayed immediately. In a nutshell, hybrid app updates generally do not require any additional human involvement, while native app updates can result in unnecessary (and negative) attentions.

Note: The fact that a single source code is used for hybrid apps also makes it easier for coders to make changes in their programs with ease. In most cases though, hybrid apps do not support offline mode.

     12. Companies love Native AND Hybrid apps

In 2012, Facebook CEO Mark Zuckerberg admitted that his company’s mobile strategy was a bit ‘too reliant on HTML5’ – and switched over to native applications. Native-built apps are also used by several other industry biggies, like Instagram, LinkedIn and Redfin. The love for hybrid applications is also increasing – and they are already being used by organisations like Banana Republic, OKCupid, Untappd and HealthTab. The tradeoff here is pretty much apparent – companies that wish to deliver the most optimal mobile experience are sticking with native apps, while those that wish to reach out to the widest possible audience quickly are taking the hybrid approach.

Note: Hybrid apps can also be operated as Progressive Web Apps, or PWA.

Native apps and hybrid apps both have their own advantages and probable downsides, as is evident from our discussion above. At the end of the day, the onus is on the developers to consider their budget, how quickly they need the app, the maximum level of complexity, and the degree of UX optimization required – and then determine whether a native or hybrid strategy would be the best way to go forward. The final choice should depend, not on the technologies per se, but on what you want an app to do – and how such features can be added in the best possible manner.