Skip to Content

SAP Cloud Platform Mobile Services Development Options


In this blog post I would like to shed some light on the development options at your disposal when building mobile apps. There is an abundance of use cases that dictate how an app needs to be built, and SAP offers a multitude of tools and approaches to achieve that goal. In the following sections, I am going to introduce the various pieces of technology and their strengths on a high level. Finally I am going to assume the role of a decision maker and give some guidance on when to pursue which approach. More detailed information on the individual topics can be found in dedicated blog topics, which I am going to link as they become available.

Fig. 1: Application development options around SAP Cloud Platform Mobile Services



2018-06-05: Mentioning SAP Cloud Platform SDK for Android in Native Apps section


Table of Contents


SAP Mobile Cards

SAP Mobile Development Kit

Web Apps

Native Apps

Hybrid Apps

SAP Fiori Client

What to Choose?

SAP Mobile Cards

Our Micro App platform “SAP Mobile Cards” (formerly known as “SAP Content to Go”) allows you to mobilize virtually any data source with little to no custom development. Each piece of information is rendered as an individual card and displayed in the personal Passbook-style iOS* Mobile Cards app. The data displayed in the app is fully offline-enabled and Mobile Services will automatically track changes and push updates to the individual users. Whenever additional context for a card is required, users can easily navigate back from the currently displayed card to its origin application. In addition, the Mobile Cards app comes with additional commonly expected features, such as the ability to share cards between users – of course only those that they are allowed to see.

In order to enable Mobile Cards in Fiori applications, no additional development is required. Building on top of Fiori Smart Templates, we provide a Fiori Launchpad plugin that allows you to easily enable Mobile Cards in your apps simply by means of configuration. And if you are looking for a more flexible means of integration Mobile Cards into your system, there are also back-end facing APIs that allows you to easily publish data in the form of Mobile Cards cards or even actions that can be performed on those cards. Last but not least, if you are not happy with the default look and feel of the cards, you can easily design custom templates in the Mobile Services administrator cockpit.

*Android support is a roadmap topic

Fig. 2: An example of a Mobile Cards card


SAP Mobile Development Kit

With the SAP Mobile Development Kit (formerly known as Enterprise App Modeler), our Rapid Mobile Application Development (RMAD) solution, we provide the technology and tools to build cross-platform applications* with a native look-and-feel, but platform-agnostic logic. There are application templates that get you started in no time, and the tools, which are integrated with the SAP Web IDE, enable you to visually and declaratively model your applications, which further reduces time to market. However, you are not limited to static definitions, but you can extend the application by means of custom JavaScript snippets. Those can be either hand-crafted by developers or be put together by Citizen Developers by means of visual programming tools. Team collaboration is also supported since SAP Web IDE neatly integrates with Git source code repositories, where the application model definitions can be versioned and shared within your organization. Testing tools are provided in the Web IDE as well, to make sure you can deliver top-quality apps. Once you are confident that your application will work, you can roll it out directly to your users via Mobile Services.

The resulting application models can be loaded into the Mobile Development Kit iOS application, where a native UI is rendered based on the application definition. Device-native features, such as contacts, and sensors, can be leveraged by means of platform-independent APIs that are exposed via the client application. In addition, the client implements the established Mobile Services features, such as Push and Offline.

Please note that we just released the first version of the Mobile Development Kit, so stay tuned for more features and content to come!

*Cross-platform applications are a roadmap topic

Fig. 3: Mobile Development Kit development and technology


Web Apps

Web apps are inherently cross-platform due to browsers being available on all major platforms, and they are very easy to build and distribute. Frameworks such as SAP UI5 even make them responsive, so that it is possible to target both desktop and mobile devices with the same app. A great example of this style of application is what we provide with our Fiori applications, which you can also build on top of the tools that are integrated with the Web IDE. While the browser largely isolates web apps from the underlying platform in a way that they can barely leverage native features, such as native Push, Mobile Services can act as a secure proxy for your internally available apps. This way you can expose web apps from your intranet to eligible employees on the internet, without putting your data at risk.

Fig. 4: High-level web app architecture. Please note that the “Mobile Web App” is only hosted on the Cloud Platform, but actually runs on the device.


Native Apps

In contrast to web apps, that are built to run in browsers and will, therefore, run on any platform, native applications are built to run on one specific mobile platform. While this typically makes development for multiple platforms more costly than going for web apps, native apps offer best performance and platform integration. If you need to secure your data with biometric features, access device sensors or need a blazing fast user interface, native apps are your best friend.

In order to integrate with Mobile Services capabilities such as Push and Offline, we provide the SAP Mobile Platform SDK 3.0, which is available for Android, iOS and Windows. It comes with a number of reuse components for common tasks such as authentication, enables you to transparently take your OData data sources offline, and provides a number of utilities that makes it easier to integrate with Mobile Services overall.

Furthermore, with the SAP Cloud Platform SDK for iOS and SAP Cloud Platform SDK for Android, we released modernized SDKs written in Swift and Java, respectively, and that were developed in cooperation with Apple and Google. They implement the same server-side features as the Mobile Platform SDK but offers additional extension concepts that enable you to build customizable standard apps. In addition, we put a lot of effort in the tooling around the Cloud Platform SDKs, which includes proxy class and sample code generation based on your Mobile Services application configuration. With this SDK, we also released the SAP Fiori for iOS Design Guidelines, and implemented native UI components to enable you to easily implement native Fiori-style apps on iOS and Android.

Fig. 5: An example of a screen implementing the SAP Fiori for iOS Design Language.


Fig. 6: An example of a screen implementing the SAP Fiori for Android Design Language.

Hybrid Apps

Hybrid apps are a breed of application that seeks to combine the flexibility of web apps with the power of native apps. The term typically refers to applications where the application itself is built with web technologies, such as HTML and JavaScript, but runs in a specific container rather than an off-the-shelf browser. These containers implement cross-platform interfaces for capabilities that are typically available on mobile devices, which is why hybrid apps can access device-native features that web apps cannot. An example of this kind of technology is Apache Cordova, which we also use to build this type of application. Cordova runs applications in a WebView on the device and exposes native capabilities via plugins that inject platform-agnostic APIs into the JavaScript runtime. In addition to the abundance of standard Cordova plugins that have been made available by the open-source community, we provide the Kapsel SDK, an additional set of plugins specifically for the Mobile Services integration. It is part of the Mobile Platform SDK 3.0 and builds on top of the same native libraries that you would use to build platform-specific native applications. When installed locally alongside the Cordova tooling, you can create hybrid applications using any frameworks of your choice, e.g. Angular (or Ionic), or even just plain JavaScript, as shown in our Mobile Interactive Tutorials. Furthermore, there is dedicated support around the Web IDE so that you can easily go from a web-based Fiori app to a hybrid application that is packaged in its own installable app.

Fig. 7: High-level Cordova app architecture

Now, speaking of SAP Fiori, there is a number of additional consumption options at your disposal. First, however, I would like to introduce the notion of “packaged” and “online hybrid applications”. Cordova lets you specify from where the application should be loaded that is displayed in the container. Typically, the assumption is that your app is packaged into the Cordova container, which means that all of the application code and assets are physically on the device. However, it is also possible to specify a remote URL pointing, e.g., to a Fiori Front-end Server, from which the WebView will load the application itself. There are some implications to those approaches:

Online hybrid apps allow you to open applications from both a browser and a Cordova application. While this makes distribution very easy, it does mean that the app should be context-aware. Otherwise, the app would break if it tries to access Cordova APIs that are unavailable in standard browsers. However, it is not possible to take these applications offline, because all your users are going to see when there is a network outage, is a blank screen.

Fig. 8: Online hybrid applications, using the example of SAP Fiori Client (see below). Note how the web app is hosted on the Cloud Platform, while the hybrid container is installed on the device.

Packaged hybrid apps, on the other hand, can easily be offline enabled. For one thing, all of the application code is on the device, which means that it can handle network failures, such as users experience under bad network conditions. Secondly, the Kapsel SDK allows to take OData-based data sources offline, which can then be accessed by the application even when there is a network outage. This would not work with online hybrid apps since even though the required data is on the device, the application itself needs to be downloaded online from servers.

Fig. 9: High-level packaged hybrid application architecture. Note how the application is physically located on the device, and only data flows between the device and the Cloud Platform.

Lifecycle-wise, both types of hybrid apps are similar in that the Cordova container needs to be deployed to an app store at least once. Online hybrid apps can then easily be updated by deploying a new web app version to the origin web server. Packaged apps, however, need to be deployed via the app store again. Alternatively, there is the Mobile Services AppUpdate feature that allows you to update the packaged application contents via our cloud platform, which alleviates one of the most common issues with packaged applications.


SAP Fiori Client

The SAP Fiori Client is a freely available standard application that enables you to run web apps as online hybrid apps. As opposed to typical Cordova applications, where the origin of the web app to display is hard-coded, the Fiori Client lets you specify an endpoint URL of the application to display. As described above, that will enable any app opened in the Fiori Client to access device-native features. Since the Fiori Client comes with the most commonly used Kapsel and Cordova plugins, it is a potential way to improve the user experience of your web apps and integrate with Mobile Services without needing to implement your own Cordova container. Due to its optimized caching mechanisms, applications feel more stable and faster since UI components are reloaded less often during user interaction. In addition, combining the Fiori Client with Mobile Services enables your users to securely access applications from the intranet without resorting to VPN. The additional monitoring capabilities also make it easier to maintain control over the data and applications leaving your premises. If you require additional features or want to customize the appearance, there is a Custom Fiori Client template at your disposal in the Mobile Platform SDK.

Fig. 10: A Fiori Launchpad opened in the Fiori Client.


What to choose?

With that amount of development options at your disposal, picking the right tool for the job at hand becomes somewhat tricky. Alas, there is no silver bullet, and it depends very much on the use case which option will yield the best results. Therefore I would like to give a couple of guiding questions that will help you decide which approach to pick. I also provide a summary by means of a table below.

The topic “Hybrid vs. Native” has also been discussed in a dedicated blog post by Martin Grasshoff.

Are you targeting several platforms or only a single one?

Native development is fine for single-platform deployments but becomes costly when multiple platforms are targeted. In those scenarios, any of the other approaches may be preferable.

Is a native look-and-feel important to your users or is a web interface sufficient?

Native applications, Mobile Cards and Mobile Development Kit work best for offering your users what is considered a “native” UI experience. Many users consider web-based UIs alien when compared to the average app, and therefore it may not be the best option. However, web-based UIs are cheaper to develop, so when your users are fine with them, hybrid apps or web apps may be the way to go.

Are offline availability and stability a strict requirement or will online-only do?

This is one of the most underrated questions, since Mobile really is about accessing your data anywhere, under unpredictable network conditions. Failing to meet users’ expectations regarding the availability of your application even under poor network conditions puts adoption at risk. However, offline-enabling your data requires additional planning, e.g. around dealing with process-related issues such as concurrent modification in CRUD scenarios. Therefore validating the requirement is an important step, since for occasional use online-only access may be sufficient.

If Offline is required, Mobile Cards is your best bet since it offline-enables your data out of the box. Mobile Development Kit, native and packaged hybrid apps can also be offline-enabled by means of the Offline OData support in our SDKs, while giving a higher degree of freedom than Mobile Cards. On the other hand, online hybrid apps and web apps, especially when used in conjunction with Fiori Client, can provide a satisfactory online experience when offline enablement is not required.

Is the app business-critical or only occasionally used?

Business-critical apps have very high requirements concerning availability, performance, and stability of an application, whereas occasionally used apps (or “productivity apps”) do not require the same amount of meticulousness. As an example, there is little business impact if a purchase order approval app cannot be used without an active network connection. On the other hand, a failing service technician app can cost you several man-days worth of working time. Depending on the criticality of the use case, it may make sense to invest in a fully offline-enabled, blazing fast native application rather than in a cheap but unreliable web app. For anything in between these extremes, Mobile Cards and Mobile Development Kit provide you with tools to quickly mobilize data and to develop stable and fast applications.

Is a super fast user interface required or are your users okay with slight delays?

Another aspect to consider is the responsiveness of the user interface. Let’s face it, there is nothing faster than a native application, and if your users’ activities are centered around an unresponsive web app, they sure are not going to be happy. If you require response times of just a few milliseconds, consider Mobile Cards, Mobile Development Kit or native applications. You should also keep offline enablement in mind. If those aspects are not an issue, a hybrid or web app may suffice.

Is freestyle development required or will a framework address your needs?

If your use case is, plainly and simply, making information available on a mobile device, Mobile Cards is the easiest and fastest way to achieve that goal. However, apart from the actual card style, it offers little in terms of customizability. Mobile Development Kit apps, while being confined to the client application, allow you to design custom screen flows and custom logic by means of JavaScript code exits. However, neither of those approaches is likely to satisfy the branding needs of a business-to-customer lifestyle scenario, where full control over every aspect of the application is required. In that case hybrid, native or web apps are your best bet.

To what degree do device-native capabilities matter?

As was pointed out in the discussion of web apps vs. native apps above, it is nigh impossible to have a web app leverage the native features mobile devices have to offer. To some extent, web standards are catching up so that it is possible to interface with the location service and even the camera. The majority of features, however, are only accessible by means of hybrid and native applications, and native apps clearly have an edge when it comes to very specific capabilities that are not commonly available across platforms. Mobile Cards gives you little flexibility but does implement some basic features such as Push and Sharing. Mobile Development Kit and Fiori Client apps can interface with whatever capabilities are exposed in the container application, and additional features can be included in custom clients.

Is time to market a driving factor?

Typically the decision is not purely user-driven, but business factors come into play at some point. Time to market is one such factor that is especially important in Mobile scenarios since the Mobile ecosystem is rather fast-paced when compared to other development areas. In order to minimize time to market, Mobile Cards and Mobile Development Kit are clearly the tools of choice, followed by web apps, hybrid apps and, finally, native apps.

Fig. 10: Comparison of the various options with respect to some select qualities. The range goes from — (least suitable) over o (neutral) to ++ (most suitable). Fiori Client and Online Hybrid Apps have been collapsed into one category. Fiori Client and Packaged Apps may increase network-related UI performance, but can not increase the execution speed of the UI as such.

1Roadmap item, currently only iOS is supported

2Fiori apps run in Fiori Client may show higher UI responsiveness than in browsers due to optimized caching

3Packaged Fiori apps may have better perceived stability due to locally stored UIs

4Time-to-market heavily reduced by tooling (SDK Assistant)

You must be Logged on to comment or reply to a post.
  • Micheal, thank you for this informative blog.

    One area which I am missing and which will play big role in decision making process is the licensing costs. Current pricing model for Mobile Services seems to be based on “per user” formula and various development options make it slightly confusing.

    Are mobile devices registered with Mobile Services classified as “users” of SAP Cloud Platform and license is paid for each device? If that was the case, mobile friendly Web Apps deployed on SAP Cloud Platform without Mobile Services could become much more interesting option despite obvious limitations.

    Would you mind clarifying if with any of the methods you described here the devices onboarded by Mobile Services automatically become classified as users from licensing point of view?

    • Hi Mark,


      Licensing questions are really tricky, because the terms may vary based on your sales region. I will try to answer that one, but please keep in mind that you should verify this with your local Sales or Account Representative.

      Generally speaking (and with the disclaimer out of the way), when we say “users” we are in fact referring to actual individual persons. That means that when one person has three devices, you would only have to purchase a single license for that user. On the other hand, when three users share one device, you still have to purchase three user licenses. This is regardless of the actual development scenario, but I can see how this is confusing with web apps that cannot quite put the “meat” of the platform to good use. This is why I like to say that pure web apps are a sort of corner use case, where you are really just interested in using Mobile Services as an authentication proxy, in addition to other use cases. Purchasing Mobile Services just for that purpose may be somewhat over the top, but it may make sense when additional apps are being planned down the road.




  • Hi Michael,


    Thank you for prompt response.

    It is sad to say that based on your explanation I feel that SAP shot themselves in a foot as I can’t imagine big companies wishing to use Mobile Services to deploy mobile apps to a bigger community, let alone using it for B2C scenarios. The latest  SAP vs. Diageo ruling may be the final nail in the coffin as even connecting via web apps may be deemed inappropriate from licensing point of view.


    I feel sorry for you guys at HCPms because what you are doing is very cool, but it must be understood that people using mobile devices should be classified differently from standard HCP users as the functionality they use is a fraction of what the whole platform offers. We should be reading valuable blog posts like this one thinking which development method is the most suitable for our scenarios without worrying about the price tag associated with deploying apps to a wider population.


    Unfortunately as it stands the “SAP content to go” is a platform not only for micro apps but also for micro user base.




    • Hi Mark,


      I think there is a slight misconception. Let me try to individually address your statements:


      It is sad to say that based on your explanation I feel that SAP shot themselves in a foot as I can’t imagine big companies wishing to use Mobile Services to deploy mobile apps to a bigger community, let alone using it for B2C scenarios.


      I assume this is related to your previous remark concerning user-based licensing. To my understanding, there is a dedicated B2C offering which has a different pricing structure than the “regular” offering. I would like to use this opportunity and repeat my recommendation to check with regional Sales in order to determine how much your scenario would actually cost.


      […] connecting via web apps may be deemed inappropriate from licensing point of view.


      I think the confusion herein lies in that you do not need to use Mobile Services in order to build a responsive web app that can be displayed on mobile devices. What I was saying is, there are very specific B2E scenarios in which Mobile Services may function as a secure proxy. Those would typically be intranet applications that are available to a select set of employees. Any other app can just be exposed directly from within Cloud Platform.


      I feel sorry for you guys at HCPms because what you are doing is very cool, but it must be understood that people using mobile devices should be classified differently from standard HCP users as the functionality they use is a fraction of what the whole platform offers.


      This one is a bit of a puzzler as well: Mobile Services is an individually subscribable service, among many others. You do not have to purchase subscriptions to “what the whole platform offers” in order to implement mobile scenarios, so you can actually tailor your subscriptions to what you need for the scenario at hand.


      I hope that those clarifications remediate at least some of your concerns.




  • Hi Michael,


    Let me respond to some of your comments first and then try to put things into perspective.


    To my understanding, there is a dedicated B2C offering which has a different pricing structure than the “regular” offering. I would like to use this opportunity and repeat my recommendation to check with regional Sales in order to determine how much your scenario would actually cost.


    This is correct however, the dedicated B2C offering can only be used if the client can quantify orders which then become the chargeable item (instead of Named Users). The are a lot of scenarios where orders are not used.


    I think the confusion herein lies in that you do not need to use Mobile Services in order to build a responsive web app that can be displayed on mobile devices. 


    I understand that but I would like to host my mobile apps on SAP Cloud Platform. How can I be sure that SAP will not try to classify the users of those web apps accessed on mobile devices as Named Users of the platform? As much as I appreciate the regional differences in license costs, the definition of Named User must be consistent regardless of the location. Let me just say that I keep getting mixed messages in relation to that.


    You do not have to purchase subscriptions to “what the whole platform offers” in order to implement mobile scenarios, so you can actually tailor your subscriptions to what you need for the scenario at hand.


    Here is when we get to the point where real life example may help to see why I feel that development methods are very highly linked with the licensing costs and how difficult it is to overcome the obstacles.

    The loud message about HANA Cloud Platform was that it could be used by thousands of developers who can easily implement their ideas and immediately monetize on their solutions. As a small software house we we thrilled and technically the HANA Cloud Platform looked like a great enabler. Our mobile solution used to connect directly to SAP Gateway and now we were able to offer more mature architecture with tight security, full offline and push notifications capability. On top of that we could expose data from on-premise to HANA Cloud and avoid using on-premise resources to analyse data that could now be synched with the cloud. In essence both us and our clients who saw our PoC were excited. Now comes the reality check.

    As all users of the old mobile app which exchanged data with SAP Gateway were Named Users, there were no issues with licensing. However, introducing HCP with Mobile Services proved to be clunky. Our clients had no intention to purchase HCP for their enterprises and pay extra fees for each user connecting their mobile device, as many were using it rarely. Additional resources to administer data exchange between HCP and on-premise would also be needed. Hence my company started exploring options to take ownership of the HANA Cloud Platform and connect our clients’ systems to our instance of HCP. According to local Sales team mobile devices registered on Mobile Services would be classed as Named Users and in consequence incur full cost. It is fair to say that our fees per user that our clients had to pay us were a fraction of what the HCP’s cost per user is so we had to quickly abandon this idea.

    We made our app work as a web application hosted on HCP (without Mobile services) and this would allow us to purchase resource based package. We did not have offline, Push option was limited and the biggest downside was a difficulty to identify devices connecting to HCP. But we only had to pay for the resources used, which was mainly related to the amount of data we would expose from our clients’ on-premise systems. Things were looking promising and we wanted to take this route until the next huge blow – SAP vs. Diageo ruling. After this litigation no client, and I mean no one, wanted to speak to us about exposing data from their system to the cloud. Ironically, it is SAP’s own cloud and SAP is the biggest loser here. Sadly I don’t see it getting any better until SAP makes a clear distinction between Named Users and mobile devices (including IoT) in the licensing strategy. It is rather pathetic (sorry I can’t find a better word) that we found bypassing HCP and Mobile Services the most viable option for our customers despite so much development effort from people like yourself who try to build a solution that addresses the needs of mobile generation.




    • Hi Mark,


      I see. Thanks for sharing this story, I think this goes a great length to explain how you came to this conclusion. I appreciate straight and honest feedback like that because this is what we need to know in order to address shortcomings in our offering.

      So far I have not realized that you were, in fact, reselling the platform, and I do think that our partner program might be the right thing for your use case. I have reached out to our partner management team and they are keen on discussing matters discretely with you. If you don’t mind, I’d suggest continuing this discussion via PMs.

      Edit: I think we need to follow each other in order to exchange PMs.