buchachon - Fotolia


Assessing the SAP-Apple iOS development partnership

Until specifics are released about the SAP-Apple SDK, native apps and Fiori development, it's best to tread carefully. And the race will not necessarily go to the Swift.

Early in May, Apple and SAP announced a partnership for creating native iOS applications as well as a software development kit based on the HANA Cloud Platform. The SAP-Apple announcement triggered conversation in the SAP community on several topics that are relevant to the decision-making process of SAP customers, including the focus on HCP, iOS, the place of native vs. Web-based development and the impact on SAP Fiori when it is extended to native iOS applications.

The SAP-Apple announcement itself laid out several commitments:

  • A new SAP HCP SDK for iOS, based on the Swift programming language.
  • A new SAP Fiori for iOS design language to extend Fiori to native iOS apps.
  • An SAP Academy for iOS to help the SAP developer community tool up on iOS development.
  • SAP will develop native iOS applications.

Steve Lucas, global president of the SAP platform solutions group, later added in a blog that SAP is developing "dozens" of native iOS applications built on Swift, presumably using an early version of the iOS SDK. (Disclosure: I own stock in Apple.)

Questions about the SAP-Apple announcement

The announcement itself (read the Apple statement, and SAP's) sounds good, but there are several angles of analysis that SAP customers and developers should keep in mind.

First, it is worth noting that this announcement and the accompanying blog posts and developer information talk only about planned SAP-Apple development. There is no SDK, and there are no native Swift-based iOS apps from SAP that accompany the announcement. The closest thing to a product that was released at the time of the announcement was the Fiori Design Guidelines for iOS, where developers can explore SAP's Fiori design principles for iOS and look through the library of widgets and UI elements provided. These design guidelines appear to be in an early state.

Another oddity of the SAP-Apple announcement is that it appears SAP carries the brunt of the commitment in this partnership. This is not surprising, as every aspect of the announcement, from the SDK to the Academy to the development of native iOS applications, is something I believe SAP could have technically and legally accomplished without the partnership. Other companies routinely develop iOS SDKs without corporate partnership agreements in place with Apple. This is in contrast to the Apple-IBM agreement from 2014, which included a commitment from Apple to a cooperative offering of AppleCare services and an iPhone and iPad reselling agreement.

Others have questioned what this means for Web-based and non-iOS development -- on Android, for example -- under the Fiori design language. I don't see any danger to SAPUI5 and OpenUI5 -- SAP's Javascript UI frameworks -- from this announcement, and I expect that if native iOS apps are a success for SAP, Android apps will follow shortly. While Web-based applications like the existing Fiori apps are often preferable in the enterprise due to their superior platform portability, there is a place for native applications when better performance, battery life or offline capabilities are required. John Moy is recommended reading on these topics.

Lastly, the focus on HCP as the target of the new iOS SDK may be troubling from the perspective of existing customers, most of whom are not HCP users. I don't hear a lot of customers clamoring to develop and support native mobile applications, but of those who are interested in developing such applications on top of their SAP systems, a relatively small percentage will be HCP users. If the SDK requires HCP use, then that may drastically slow adoption in the existing SAP user base.

What it means for SAP users

There is a real question as to whether SAP users should be developing applications in Swift at all. Swift offers significant advantages over Objective C, but it is also a young and fast-moving platform. Application binary interface (ABI) stability has been deferred from the upcoming Swift 3.0 release, meaning that a compiled version of Swift and the Swift standard library still needs to be packaged with any Swift app. Further, source compatibility will change with Swift 4.0 (likely to be released in 2017), meaning that people who develop Swift apps will be on a somewhat forced upgrade march through at least 2017. Timely upgrades are an area in which SAP customers have historically struggled, so it will be interesting to see how SAP approaches structuring its SDK to ease this pain.

For customers, I believe we are currently in wait-and-see mode. More information about the plans for the SDK and native app development was shared at the SAP Sapphire conference earlier this month, but the proof will be in the pudding -- specifically the SDK and native applications that are delivered. Does SAP have the iOS competence to deliver high-quality apps and SDKs on that platform? We won't know until we see the product. Until then, I would not recommend committing to using it.

So what should SAP users who need to develop mobile strategies do now? That is going to depend on the user. A purely Web-based strategy, whether based on Fiori, another platform or a combination of platforms will continue to be a good bet. If native apps on mobile devices are required, then a mobile device management platform such as the SAP Mobile Platform, SAP's HCP Mobile offerings or a third-party platform may be a good option. Make any such plans with SAP's iOS commitments in mind, but with a healthy degree of skepticism.

Next Steps

Read more on the Apple-SAP partnership

Get a different take from the Brian Madden website

See a handbook on SAP mobility

Dig Deeper on SAP UX