Skip to Content
Technical Articles
Author's profile photo Marco Eidinger

Simplify iOS mobile app onboarding with SAPFioriFlows

Most enterprise mobile applications have a common set of repeating tasks when a user starts the app for the very first time or restarts it.

For a user, who is opening the mobile application for the very first time, you might want to

  • greet the user with a welcome screen
  • let the user authenticate
  • get user’s consent for usage analytics and/or crash reporting
  • force the user to specify an application passcode

Once a user is onboarded there are still a set of steps to take off, e.g.

  • ask for biometric authentication or application passcode to unlock the app
  • re-authenticate (if necessary)
  • check for security policy changes and ask the user the application passcode accordingly.

As part of the SAP BTP SDK for iOS you can use SAPFioriFlows framework to develop such complex onboarding processes just with a few lines of code. The framework binds together the SAPFiori UI components with the SAPFoundation components to provide default configurable implementations for the most common tasks. As with other components in the SAPFoundation and the SAPFioriFlows frameworks, any components can be configured or even replaced with a custom implementation if it is necessary.

The following onboarding flow can easily be created (and customized) with SAPFioriFlows.

WelcomeScreen Authentication (here: SAML) Get confirmation of data privacy Get consent for usage analytics Get consent for crash reporting Request user to setup passcode

I highly recommend to read the documentation to get more info about the capabilities and built-in features of SAPFioriFlows.

There is another advantage, besides all the end-user related features you can get for free by SAPFioriFlows, which I want to point out in this blog post.

Without SAPFioriFlows you have to write quite some boilerplate code, e.g. you have to setup an SAPURLSession with all the necessary observers and authenticators to ensure that network communication between your iOS mobile application and Mobile Services works correctly.

For example, Mobile Services require that all incoming HTTP requests contain X-SMP-APPID and X-SMP-DEVICEID header fields. SAPFoundation framework provides the SAPcpmsObserver which can add those header fields to each HTTP request of the SAPURLSession. But there are other observers (LanguageObserver, CorrelationObserver) which are also useful and even required for certain use cases. It is easy to forget to set those observers manually. And then you face problems like “Why are my OData requests failing with HTTP error code 403 while authentication was successful??” because you missed to register SAPcpmsObserver.

SAPFioriFlows comes to the rescue by conveniently bundling those tasks into a single onboarding step (SAPcpmsDefaultSteps) which can then be applied.

public var onboardingSteps: [OnboardingStep] {
  return [
    // ...
    CompositeStep(steps: SAPcpmsDefaultSteps.configuration),
   // ...
  ]
}

I highly recommend to use the BTP SDK for iOS Assistant which leverages SAPFioriFlows and generates the onboarding code based on your application settings in Mobile Services. The example onboarding flow above (screenshots) was generated by the Assistant without that I had to write a single line of code!

P.S. I am eager to know about your questions and feedback about SAPFioriFlows so don’t be shy and leave a comment.

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Alexandre Giguere
      Alexandre Giguere

      Hi Marco

      great blog, here are some of my feedbacks

      we develop additional onboarding steps that I should probably blog about it, I think they would be great addition in your SDK

      • user consent to use the camera
      • user consent to use push notification

      also I embedded the what’s new controller as an embedding steps

      for enterprise apps, we don’t see the need to bother the user with

      • data privacy
      • usage collection
      • crash report

      we enable them by default, we don’t want to ask the user for it

      I understand their purpose but if the user deny them, they can’t enter in the app

      also the passcode is overkill for us, imagine having 10 enterprises app on the same phone, switching from one to another and having to enter a passcode,

      it would be nice if we could have an option in the macOS assistant to disable it, I know we can disable it in Mobile Services, but the preview in the app switcher is a black screen instead of the real preview so I had to tweak the generated code to not show that

      thanks

      Author's profile photo Daniel Douglas
      Daniel Douglas

      Really helpfull 🙂