The SAP Cloud Platform SDK for iOS is now out for a couple of months, and is already gaining some significant traction. However, most people are still righteously wondering,

“Why should I care? Why not simply build a hybrid app?”

Indeed, when building a hybrid app, you can utilise most, if not all, of the hardware of the mobile device. You’re not restricted to one platform (iOS devices). You may even use the web developers you already have in your development team, instead of hiring an outside Swift developer.

However, there are definitely use-cases where building a native, single-platform app if highly preferred over a hybrid or web app. With this blog, I would like to point out a couple of these use cases.

First and most importantly, I would not recommend building a native iOS app for ByoD scenarios. By default, people bring all kinds and brands of mobile devices to the work floor, so by default this would fit the hybrid or web app approach much better.

However, if there’s a specific role or function in your organisation which would benefit from a mobile app in order to carry out their tasks in a more streamlined / fail-proof / quicker / cheaper / etc way, your organisation most likely decides on a single platform already. And if that platform happens to be iOS, then there are a couple of benefits where building native has a couple of benefits over building a hybrid application:

User Experience

People want their devices to work constantly and reliably. A poor mobile application user experience will annoy its users, and eventually they will abandon it and find other ways of doing their tasks. Especially if your app needs to access various (hardware) layers of the mobile device, the hybrid app needs to incorporate one or more plugins to access those layers, naturally resulting in a less-than-snappy UX. In addition, the development team should be constantly aware of any updates for those plugins (many of which are third-party), avoid incompatibility between plugins, or find replacements for deprecated plugins.

A native app can access those hardware resources directly, resulting in a much better user experience. You can access the camera, accelerometer, GPS, contacts, Touch ID, etc directly without having to worry about which third-party plugin to deploy.

Since a hybrid app is basically just a browser, any hybrid app you create behaves just like in a browser. If your hybrid app is heavy on page components, gestures such as swiping, pinching etc will feel less ‘natural’ and ‘direct’, resulting in a worse user experience. To make this “feel right” is much easier to achieve in native apps.

In addition, the SAP Cloud Platform SDK for iOS comes with a growing set of Fiori controls. They look more like Apple iOS controls and not so much like the controls you see in the SAPUI5 SDK or in any of the SAP Fiori apps, but you recognize them as Fiori controls nevertheless. That’s because the SDK’s Fiori controls are created with Apple’s Human Interface Guidelines in mind, and are building up on these. This ensures an application built with these Fiori controls has a much more native feel than a Fiori web app or hybrid app, yet still embraces the Fiori design language and paradigms. For a user, the native app looks, feels and behaves much more “native” to the device than a web or hybrid app, which increases the initial “getting familiar with” period for the app. In other words, the user will know how to navigate and operate the app faster.

Security

A native app has less means of introducing security risks, simply because there are less layers in the application architecture compared to a hybrid application. These extra layers are added by plugins which need tp bridge the web part with the device’s native features. And plug-ins almost always owned by third-parties, which potentially makes it harder to understand any security implications they may have.

Currently, iOS is the most secure mobile platform. Developing enterprise app with native code using the SAP Cloud Platform SDK for iOS, along with Apple’s best practices for developing applications ensures the most solid, secure results.

CPU heavy processing

If you need an app that does lots of CPU heavy tasks, such as image or video processing, manipulating 3D objects or Augmented Reality / Virtual Reality or rely on other data processing on the device itself, you’re much better off with a native app.

Utilising other native device capabilities

Geofencing

Your device is always on, and you can have your app always on if you want too (or at least have it run in the background). One of the benefits of being always on is that your location is always known, which is of great value in geofencing scenarios. Imagine you’re a mechanic in a factory, and a machine in a factory is down. You look at the app and on the map you see instantly in which part of the factory it’s located and how long it will take you to get there from your current location. If the machine utilizes some sort of smart sensors, you might even see what the root cause of the downtime may be, for instance a worn-out bearing.

You could also use geofencing passively. Imagine a large building which sets of the fire alarm. Using geolocation service you would know if there’s still people in the building. Of course, you still need to check, but if you notice someone stuck in an elevator, you may rescue them quicker.

External displays

If you hook up an iOS device to an external display or monitor, it will mirror the app’s screen by default. However, you can define a completely different screen which is only visible when connected to an external display, to show additional or even completely new data. Think for instance of a mobile app which displays only 4 KPI’s per page, and has 8 pages to browse through. But when connected to an external display or beamer it shows all 32 KPI’s at once. Or imagine a predictive maintenance app which shows the most relevant info for a certain machine on the app, but when connected to a 2nd display, it pulls up the live logs on that screen.

Using the latest iOS API’s

As with any hybrid application, you are dependent on third-party vendors to create plugins support the hardware and iOS features. With the latest iOS 11, you instantly get access to API’s to Core ML (Machine Learning), Core NFC, Augmented Reality, Computer Vision, and Apple Watch functionality.

Other

Be cross-platform via SAP Cloud Platform

What if you still feel a cross-platform hybrid approach would be best? What if you have decided on one platform, but you want to have the freedom to swap to a different mobile vendor in a couple of years without too much effort and cost?

When most people think of a cross-platform application, they think of web or hybrid applications. But think about this: if you have a common platform, such as SAP Cloud Platform, where you expose the relevant API’s to various user interfaces (web / hybrid / native), wouldn’t that be cross-platform as well? After all, mobile applications are just user interfaces to a multitude of servers (ERP, databases, other on premise and cloud environments, etc) and services (web services, IoT services, micro services, etc).

So while saving a couple of dollars upfront by building a hybrid app might be a good idea at first, think of all the annoyed users who need to deal with a less-than-optimal user experience which may end up costing a multitude more in the long run:

If you have other or different feedback or insights, or additional use cases for native iOS developments, I would love to see them in the comments!

And if you’re not yet familiar with the SAP Cloud Platform SDK for iOS, go to https://developer.sap.com/ios-sdk, download the latest SDK and familiarise yourself with the available tutorials.