On May 5, SAP and Apple announced a partnership to deliver native iOS Apps that will connect into SAP business suites:
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.
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.
