First thoughts on Native Enterprise Fiori iOS Apps

On May 5, SAP and Apple announced a partnership to deliver native iOS Apps that will connect into SAP business suites:

Apple & SAP Partner to Revolutionize Work on iPhone & iPad

My personal first response on this news was astonishment and non-understanding. Since 3 years SAP is full promoting SAP Fiori build through SAPUI5 (or openUI5) web-technology as THE future-proof way to build user-friendly SAP Apps. SAP applies itself in all new and updated product developments, as SAP HANA Analytics Apps, NetWeaver Business Client, SAP Enterprise Portal. SAP made and evidently applies the decision to go full-stream for web-based UI in favor of the platform-specific native product developments (of which SAP tried several variants, most notable through the Sybase Unwired Platform). And now all of a sudden, SAP appears to return on this decision and [also] to put full steam on platform-native development. Starting now with first Apple/iOS, and already communicated plans to follow later with Android.

I expressed my surprise and concerns on a SAP post in which Steve Lucas communicated on the SAP-Apple partnership. His responses gave me more insights in the why of this renewed native-attention, and the positioning towards web-based. Not to say that I in all agree.

Steve in particular replied with statement ‘There’s a big different between “semi” native and native’. On this I disagree, regarding the qualification ‘big’. I do acknowledge that for interactive consumer Apps this may still (and likely remains to) hold, as those may need the local computer power and platform-local capabilities. Games are a good example that really benefit from direct access to the local resources and computing power. But I personally doubt that platform-native capabilities add considerable extra value for business / enterprise Apps.

(Source: [Salesforce Developer] Native, HTML5, or Hybrid: Understanding Your Mobile Application Development Options)

As a true architect, I made a Pro/Contra enlistment for Fiori-native and Fiori Web-based:

Fiori-native
Pro	Ability to use device-local capabilities (e.g. geolocation, camera, local storage)
	Rich UI
	Consistent UI for the specific device-platform
	Optimal local performance (power)
	Fast graphics
	Push-notification supported
	Possible to run / continue in background
	Data-integration possible with other local Apps
Con	Need to build + support per device-platform
	Mobile-Only
	Version-upgrades must be explicit brought to each individual end-user device
	Requires SAP HCP
Fiori web-based (SAPUI5/openUI5)
Pro	One version usable on all device-platforms
	Mobile-First / Mobile + non-Mobile
	Easy deployment: Version upgrades only on central webapplication level, transparent to end-user devices
	Via Fiori Client or Kapsel: possible to act as semi-native App, direct user-launchable from the device
	Via SAPUI5 and other frameworks (jQuery), possible to use device-local capabilities (GPS, Camera)
Con	Functionality limited to common denominator across the platforms
	UI is not on-par with the device-specific experience (e.g. Fiori UI differs considerable from iOS native UI)
	Push-notification is complex (and requires Fiori Client or Kapsel [Hybrid App]
	Local file storage not available (although from security perspective, this is not per se a disadvantage for business / enterprise Apps. Dependent on the business App, it may be prohibited to locally store sensitive / business-critical data)
	Not possible to run in background
	Less performant due browser javascript engine + interpreted rendering

Based on these (and more) pros/contras, individual companies/architects can decide whether to go for web-based SAP Fiori or platform-native Fiori. Noticable especially is the HCP dependency in case of Fiori-native. Implication is that companies that are no subscriber [yet] of SAP HCP, cannot go the Fiori-native path. But they can expose their on-premisse SAP Business Suite(s) via web-based/SAPUI5 Fiori Apps.