Skip to Content

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.

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:

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:

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) {
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. 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?
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,

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Mike Doyle

    Thanks for sharing your thoughts Martin.  You raise some interesting points.  I would agree that trying to add offline capability to an existing online-only web app will certainly be a challenge.  In contrast trying to write an app from scratch to do both should be viable (using Fiori Mobile/Cordova for the mobile app), given some careful planning.  That would certainly bring significant benefits in some cases.  Of course, if you don’t need offline then a web app running (sometimes) in Fiori Client is a good option.

    It seems clear that Android and iOS are winning market share from the other platforms.  For most enterprise customers, supporting these two will be sufficient and that does make a difference in the native/hybrid debate.  If we use the SAP Mobile service as middleware for an Android native app and an iOS native app then the development time is certainly not doubled because the back-end work can be reused (i.e. OData service and CPms config).

    Like many other people (I’m sure) I’m keen to know when we might see a new Android SDK from SAP and I’m keen to really get to know the Mobile Dev. Kit (mdk) and see that come to maturity.  If it delivers on ‘write-once with native UX’ then it could be very popular.




    1. Martin Grasshoff Post author

      Hi Mike Doyle,

      thanks for the comment. I completely agree that you can create a offline app and use it for the web-channel is possible. But if you are on this, I’d challenge you if you really want to deliver the same use cases, and UX on both channels. It makes sense for a use case, like leave request. But what about sales force automation? If I’m in front of a customer and want to close a deal on the iPad quickly and with superior UX (the customer is also looking at the iPad screen) – would you just reuse the ordering screen the back-office user sees?

      If you answer this with no – then do a separate mobile app (regardless of technology). If the you say yes, then a quick, cheap reuse is the right approach.



  2. Holger Schäfer

    Hi Martin,

    last year i wrote a nice blog and Fiori kapsel Test Client as an example of what can be done with UI5.

    Since i played with Google Firebase which support browser support for Progessive Web Apps (PWA) and also offline DB support with Google Firestore, it would be good to know, if SAP will support something similar in the Future.

    Even Apple startet to implemented PWA into IOS and in the near future offline will be possible with browser based applications without the need for Cordova Container or maybe Native Apps.

    Are there any plans that the Mobile Plattform OData offline Sync services will be supported by SAPUI5 browsers out-of-the-box?

    Regards Holger

  3. Richard Shaffer

    When I was need to create an app, to optimize my work, I thought that it will be too easy. I began to look for some websites with information about creating applications by your own, with detail instructions to create something like that, what I wass need. But over the time, I decided not to reinvent the wheel, and just turn to the company that have a deal with developing exactly that, what I was interested in. So after, I found android mobile app development, they saved my situation with development a software for my requests. Now it works for me like a clock, I achieved the goal.

    Only with help, because by myself, I would have broke my head over this task of creating an application. Thank you for sharing your experience. For you it turned out more easier, than for me.


Leave a Reply