Introduction
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
Updates
2018-06-05: Mentioning SAP Cloud Platform SDK for Android in Native Apps section
Table of Contents
Introduction
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 martingrasshoff.
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.
| Cross-Platform (Android+iOS) | UI Performance | Offline | Customizability | Capabilities | Time to Market | ||
| Mobile Card Kit | ++ | ++ | ++ | -- | - | ++ | |
| Mobile Development Kit | ++ | ++ | ++ | + | + | + | |
| Web App | ++ | -- | -- | ++ | o | o | |
| Fiori Client | ++ | -1 | -- | ++ | + | - | |
| Packaged Hybrid App | ++ | -2 | + | - | + | - | |
| Native App | -- | ++ | ++ | ++ | ++ | o3 |
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. Cross-Platform: Ability to run on Android and iOS. UI Performance: Time to content and responsiveness of UI. Offline: Suitability to build for network resilience. Customizability: Ease of and degree of freedom when customizing by configuration or code. Capabilities: Ease of access of low-level platform APIs.Time to Market: Difficulty of building an MVP in a typical customer setting.
1Fiori apps run in Fiori Client may show higher UI responsiveness than in browsers due to optimized caching
2Packaged Fiori apps may have better perceived stability and responsiveness due to locally stored UIs, but can not increase the execution speed of the UI or business logic as such.
3Time-to-market heavily reduced by tooling (SDK Assistant)
Updates:
2019/02/25 Updated comparison table to reflect current state of roadmap. Hopefully also improved readability.
- SAP Managed Tags:
30 Comments
