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.
Nice blog, Robin. What about consumer-grade apps, destined for a public app store? Native might be justified in that case, perhaps with both iOS and Android native apps required
Hi Mike, I fully agree. Especially with consumer-grade UX, I believe a native app is the recommended way forward, simply because of the better user experience; while corporate app users might have no alternative for an app with a poor UX, consumers will simply abandon your app after one or two attempts.
In any case, whether you’re targeting corporate users or consumer users, they simply don’t care whether you created a hybrid or native app — both of them expect the best user experience. 🙂
Hi Robin,
Thank you for this blog, as it raises some important topics for customers to consider. Especially in relation to the HTML vs Hybrid vs Native debate.
I thought I’d share my own opinions, based on my experiences working with a mobile team over the past few years. Whilst I applaud SAP for bringing the native option back to the table, I’m not as enthusiastic about the SDK for iOS as I would like to be. Here’s why …
Seems like I’ve written a blog here in the comment stream. Anyway just wanted to contribute my thoughts to the discussion. Thanks for starting the conversation.
Cheers
John
Hi John,
Thank you so much for this insightful and thought provoking Blog-as-a-Comment, and adding fuel to the conversation. While I do agree with almost everything you mentioned, there’s one thing I have to disagree.
As much as I wholeheartedly embrace the native feel of Xamarin and ReactNative, I strongly believe the UI should not be a one-size-fits-all-platforms solution. An Apple iOS users wants its apps to look, feel and behave uniformly, and so does an Android user and Microsoft user. However, the look and feel of these platforms are significantly different, which makes it impossible by default to create a UI that fits naturally on those platforms.
Of can of course create separate web-based UI’s for these platforms with a look and feel matching that of the host OS, and have a shared underpinnings. But that’s a perfect case for native iOS (Android? MS?) SDK, more or less: have a lightweight, responsive and performing native UI, and have SAP Cloud Platform do the heavy lifting and expose any business logic via API’s and services.
Im my view, regardless of technology or development paradigms being used, the most important aspect of app creation is The User, not The Technology behind or even The Business Process you’re streamlining.
But then, as Njâl Stabell likes to rub me in the face every time, I guess I’m more a designer than a developer 😉
Hi Robin,
I can’t speak for the fine grained nuances of ReactNative, but I am quite familiar with Xamarin at a coding level. Xamarin comes in two approaches, a light abstraction approach which is offered as Xamarin.iOS & Xamarin.Android, as well as a heavier abstraction approach which is known as Xamarin.Forms.
With Xamarin.Forms, you code a single app with a single code base to generate both iOS and Android apps. Page layouts are defined using XML. And yes because there is a higher abstraction level here you do end up with more of a ‘common denominator’ user interface approach, much like you do with UI5 (except with native performance). That being said, I’ve noticed the Xamarin.Forms implementation is intelligent such that (for instance) a date picker can be rendered closer to the mobile platform on which it is running. See example here https://developer.xamarin.com/api/type/Xamarin.Forms.DatePicker/.
However with the lighter Xamarin.iOS or Xamarin.Android, you can choose to code very closely to the mobile operating system, whereby any given UI element for that operating system and all their associated properties and methods are exposed as equivalent properties and methods in Xamarin via C# classes. This means that anything you do in iOS or Android you can absolutely achieve the equivalent look and feel using Xamarin. With this approach you can still achieve some code reuse by separating model logic into reuseable portable class libraries that you share across both your iOS and Android apps. Whereas the logic you write for your views is platform-specific to achieve the platform specific look and feel. Depending upon how you architect things, this means that 30-70% of your logic might be in reusable classes, and the rest is platform specific. But when I say platform specific, I don’t mean Swift for iOS and Java for Android. I mean C# for iOS and C# for Android. So you still benefit from some code reuse, as well as a single language across both iOS and Android (and Windows if you want to port to Windows 10).
So in this regard I don’t agree that Xamarin locks you in to a one-size-fits-all platform solution. Sure Xamarin.Forms does, but you can instead choose to use the Xamarin.iOS or Xamarin.Android approaches. To illustrate, all the iOS UIKit classes are described here https://developer.xamarin.com/api/namespace/MonoTouch.UIKit/ . You will see references to things familiar to iOS developers such as UIButton, UIDatePicker, UILabel, UIScrollView etc. These are the exact same objects as you would control using Swift. I’ve been involved in projects where the UX designer produced a greenfields iOS app design and the Xamarin developer was able to deliver an app conforming precisely to that design using Xamarin.
Anyway I just wanted to add that for clarification. If SAP had continued with the Xamarin partnership and built the enhanced Fiori controls into that SDK, then I feel customers would have been better served. Just my opinion anyway.
Cheers
John