Skip to Content

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.

To report this post you need to login first.

5 Comments

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

  1. Mike Doyle

    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

    (0) 
    1. Robin van het Hof Post author

      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. 🙂

      (1) 
  2. John Moy

    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 …

    • Restricting the native use case to customers who have decided that their only corporate issued devices are iOS devices is very limiting.  I have worked with a customer for instance that started with corporate issued iOS and then decided that it needed to branch into corporate rugged Android devices.  There are no rugged iOS devices – and if we think putting a hard case on an iOS device is sufficient, in many cases (eg. mining, oil & gas etc.) it just doesn’t fly.  You can get rugged Android devices with hot swappable batteries.  I worked with a logistics company years ago that struggled with battery life in mobile scanners – what you want there is a device where you can swap the battery (and these days the rugged Android options can stay ‘on’ whilst you make the swap) and where you really want a proper integrated barcode scanner rather than relying on a camera (which burns batteries) or an attachment scanner.  Often people use these devices in conditions which go outside the standard operating temperatures of an iOS device.  Rugged Android devices work in extreme temperatures.  I had a meeting with Apple about this and they had no solution other than referring us to third party solutions (eg. someone building a case for an iPad with a fan in it … I mean, seriously).  Anyway, for a subset of industries going iOS-only doesn’t fly.
    • Secondly, its important to understand that native experience and all native features can be achieved with what I call ‘hybrid native’ techniques.  That is solutions such as Xamarin, ReactNative and Appcelerator.  The litmus test I use for whether one of these techniques provides a ‘native experience’ is if someone showed you an app which uses these techniques and you found as a user that you couldn’t distringuish whether it was built using native Swift or using Xamarin (for instance).  Even SAP has partnerships with some of these techniques, but the big fanfare about SDK for iOS is because of my next point …
    • In my personal opinion, the SDK for iOS announcement was conceived as a cross-marketing strategy between SAP and Apple.  SAP would support Apple’s desire to uplift iOS devices into the enterprise.  Apple would help SAP sell more SAP Cloud Platform licenses (since the SDK for iOS is hardwired to the Cloud Platform).  Of course I don’t really know if this is true for sure, it’s just my guess. The concern I have with this is that it is a strategy to service SAP and Apple, but not necessarily the customer.  As evidence of this, I’ve had customer meetings with Apple (ironically about rugged device options) and the Apple representatives couldn’t stop name-dropping the existence of the SDK for iOS.  In this regard SAP has cleverly engaged Apple’s sales force to indirectly sell SAP Cloud Platform.
    • So what do I prefer?  Right now I’m working with a customer on a Xamarin-based strategy.  Xamarin isn’t new to SAP, indeed SAP struck a partnership with Xamarin years ago which includes an SDK that connects to SCP (if that is your preference).  What I like about Xamarin is you code in C# (a language I’ve learned to love, and if you come from a Java background it isn’t difficult to make the leap) and from there you can share code across iOS, Android and (even) Windows apps.  With Xamarin.Forms you can code something that end to end works multi-platform but still gives you a native experience.  Enterprises typically are more likely to have .NET developers that can tackle C#, rather than learning Swift.  And whilst with Xamarin you have the choice to incorporate an SDK that can connect to SCP, you are not hard-wired to that platform either.  It is interesting that the Fiori (SDK) for iOS announcement came out only a few months after Microsoft announced the acquisition of Xamarin.  In my mind SAP’s partnership with Xamarin took a back seat after that acquisition.  After all, Microsoft was going to be less likely to promote ongoing connection of Xamarin to SCP, but would instead be more interested in evolving it’s existing SDK that connects Xamarin to Azure (mobile) App Services.  To-date, I’ve been very impressed with the Xamarin path, because it is mature, (several years old, which also includes many solutions on forums and stack overflow), it works, it uses a language existing enterprise developers are more likely to be familiar with, and with that language it supports multiple native platforms.  Whilst I mention Xamarin here, one could just as readily raise similar advantages for ReactNative or Appcelerator (both of which are JavaScript-based).  I feel that if SAP had a similar technology of it’s own, it would be promoting that … except it has been lagging to this degree and so has fell in with Apple to coding with Swift.
    • I did investigate the SDK for iOS a few months ago.  What struck me was how much of it actually related to SCP connectivity and associated services (eg. offline sync) as distinct from Fiori UX.  As you mention in your blog really the SDK for iOS is based on Apple’s Human Interface Guidelines.  Apple has pioneered UX for mobile devices – anything SDK for iOS adds to that would not be ground-breaking otherwise Apple would have included it in the standard iOS offering.
    • I do think there will be a niche area for SDK for iOS.  Some customers will mandate it, and that is fine.  There is nothing wrong with coding native Swift for iOS, if the customer so desires it and wants to support that.  But I just want customers to ensure they have their eyes open and understand pros and cons of the decisions they make.  To cement the niche idea, if anyone has seen the 2017 Gartner mobile application development platforms magic quadrant, they would see that SAP is now in the ‘Niche players’ category.  I know many people don’t place much emphasis in Gartner magic quadrants .. but then again years ago SAP presentations included slides showing it in the ‘Leaders’ category … so it cuts both ways.  In any case, such is the pace of change in mobile that it is difficult to keep up.

    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

    (5) 
    1. Robin van het Hof Post author

      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 😉

      (2) 
  3. John Moy

    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

    (2) 

Leave a Reply