Mobile App Development – Hybrid vs. Native

In my role as Product Manager for the SAP Cloud Platform Mobile Services, customers and prospects seek my advice whether they should build their app as a Hybrid app based on Apache Cordova or using native app development, e.g. with Swift on iOS. While we do support both options with our SAP Cloud Platform SDK for iOS and the SAP Mobile Platform SDK, customers don’t want to invest three months’ worth of development into the wrong technology.
But what are the criteria which should be used to determine which is the best approach? The following discusses the pros and cons and gives guidance.

tl:dr
In the end it is a matter of available skillset – maybe Hybrid does not provide the best possible user experience, but it may be good enough. Native has many advantages, and is very efficient, but no choice if you do have only JS and HTML5 know-how.

The usual suspects

The following matrix describes the typical and well known characteristics which are discussed while deciding between the two choices and I will not explain every bit of it in all detail, but you can read the full explanation in Michael Jess’ blog post here: https://blogs.sap.com/2017/06/21/sap-cloud-platform-mobile-services-development-options/

As you can see, there are many dimensions to discuss this topic and depending on your situation, you need to weigh each point differently.

Another perspective

Hybrid is considered the best choice if you need your app to be supported by different device platforms at the same time. In my discussions with different customers and especially partners I would like to bring up one point that is not too visible in hybrid projects: Situations in which going the Hybrid way backfires and does more harm than good. Let me explain this with an example:
You develop a mobile app that runs on iOS and Android using Apache Cordova. Your iPhone users demand Touch ID support. Browsing the Cordova plugin repository you find a couple of plugins which let you add Touch ID to your application easily. At the time I wrote this article, I got nine results for the search term “touch id” using the Apache Cordova plugin search.

The first hit seems to be reasonably active and maintained with 3k recent downloads and an update just 69 days ago. I don’t want to discuss the risk of using outdated, no longer maintained plugins in your enterprise product – this is all up to you. My point here is that once you start using this plugin, you add to your app something like the following pseudo code:


window.plugins.touchid.isAvailable(
function(type) {alert('TouchID type: ' + type)}, // success
function(msg) {alert('TouchID unavailable: ' + msg)} // fail
);


So far so good. Your app does support touch ID if available on that particular device and the success callback does represent everything you do in your application.
Now, after a couple of weeks of users happily using your application the Android user base demands to have fingerprint support as well. No problem you think, with the right cordova plugin you can easily bring that in.
First, our current plugin does not support fingerprint on Android, so we either need to add another dependency or find a plugin that supports Touch ID on iOS and fingerprint on Android. So let’s do a quick search for “fingerprint”:

Actually, I think the fourth hit is the best fitting in our situation, it seems quite frequently being used, seams active and supports both platforms. So “just” replace this one with the one we used before.
Here’s the API of the new plugin:


Fingerprint.isAvailable(isAvailableSuccess, isAvailableError);
function isAvailableSuccess(result) {
alert("Fingerprint available");
}
function isAvailableError(message) {
alert(message);
}
Fingerprint.show({
clientId: "Fingerprint-Demo",
clientSecret: "password" //Only necessary for Android
}, successCallback, errorCallback);

function successCallback(){
alert("Authorization successful");
}
function errorCallback(err){
alert("Authorization failed: " + err);
}

That looks quite promising. It looks like a clean, easy to use API that can be used to access this feature on iOS and Android the same way.
But the devil is in the details. It starts with simple optional parameters, some are for Android and some are for iOS. But there is a thing on iOS, starting with iOS 9.x, where you can check whether a new fingerprint has been added to the database and you should implement this check as well. This plugin does not support this check and we do have couple of options now:

1. 1. fall back to individual, device specific plugins, which usually supports each platform best, then provide device specific code
   2. just ignore the requirement
   3. fork the plugin and contribute

Regardless of your choice, you will need to add significant device platform specific code in order to support multiple platform at the same time – either in your app, or in the plugin. This, in turn, requires skills similar to Native developers, which, to some extent, defeats the purpose of going Hybrid.

Here’s another example. You want to read/write a simple file in a common location on Android and iOS with the same line of code. So in which of the following locations you want to store it? https://cordova.apache.org/docs/en/latest/reference/cordova-plugin-file/index.html#where-to-store-files
Even here you need to provide device specific code, even if it is not that much. The more you support device specific features, the more expensive your app development becomes – lowering the value of hybrid app development to the point where two native projects become cheaper.
And this observation has been seconded by many partners in recent discussions I had.

Another reason for using a hybrid approach for mobile app development is the idea of reusing the code for a web application and on the mobile device at the same time. This is, of course a reasonable request, as long as two things will be kept in mind:

• The app on the mobile device is an online application (using caching mechanisms) only
• The app is not using any device-specific features

Let me explain this in more details. If you are going for an enterprise-grade, offline-capable app there is NO WAY of extending a given online webapp to support offline functionality. I will not go into the details, but here are some talking points why: error handling and conflict management in offline cases, input validation and offline business rules (favorite example: offline price calculator), logon and authentication while offline, multi-user support, and additional user interfaces for some of those. These are some aspects that need to be added to an existing online, webapp to make it fully offline capable. And experience told us that this is typically not an easy task. In general, you could say that extending an online web-app with enterprise offline capabilities is more expensive than creating a second application designed for offline from scratch. And since this is the case, you can consider an online-to-offline migration scenario as a valid case for native app development, too – you can barely reuse the existing code anyway.

More or less the same applies to device-specific features, but here it is not that expensive. Let’s expand the Touch ID example from above. You can extend your web-app to support Touch ID if the JS code is running in a Cordova environment. This can, for instance, easily be achieved using the SAP Fiori Client to run your application. The SAP Fiori Client acts like a browser, by providing the runtime environment of Apache Cordova for your web application. Let’s assume that you develop your app in Web IDE, using the Hybrid App Toolkit plugin, which mocks some common Cordova APIs so that you can preview common functionality in your browser. Sprinkled throughout your code, guard clauses like this are going to grow like weeds, increasing the code complexity:


if(window.cordova // to check if we are in a Cordova environment...
&& window.plugins.touchid) { // ...and our plugin is available, which may not be the case in Web IDE!
// use plugins as before
}


Things tend to become even more chaotic when you are doing this as part of a web app extension – i.e. the original web app was meant to be run in the browser, and you extend the component in order to more closely integrate with a device. If you design your app to run in both environments from the very beginning instead, it can be a viable solution.

If you consider the best mobile user experience and the discussions from earlier in this blog, choosing the optimal approach for your mobile app favors a dedicated approach for your device platform. If you need to build your mobile channel individually, using a native approach results in best user experience.
Nevertheless, if you are lacking either the budget or the skillset – it is a viable solution to go Hybrid.

Please take your time and make sure that you fully understand the implications of going Hybrid or Native in your scenario. A good decision can vastly improve your project outcome and turnaround time.

Have fun,
Martin