Introduction

Today, March 30, 2017, the much anticipated SAP Cloud Platform SDK for iOS is available for every SAP developer to try it out. You can find the SDK here.

Not part of the SDK download, but no less integral part of the SDK, is the SAP Fiori Mentor app, available from the Apple App Store here. In case you haven’t downloaded it to your iPad, do so now, explore it a bit, and then read further.

Tried it out? So, what do you think? If you’re like me, most likely your first thought was:

What’s the point?

Ok, let’s recapitulate:

If you ticked both checkboxes, hurray, this blog is definitely aimed at you! And in case you did not immediately removed the app, you might still wondering why SAP and Apple chose to browse the controls using a native app instead of a web-based solution like the SAPUI5’s Explored app. With this blog, I’ll try to explain why the chosen approach actually makes perfect sense.

What’s in it for me?

Imagine you are an application developer — if you have downloaded the SDK, you probably are anyway.

Let’s assume you are tasked to sit together with the UI designer and business analyst and come up with a user interface for a mobile application running on iOS devices which should perfectly balance between being desirable for the people who will use the application, viable for your business and feasible to design and develop.

— obligatory image depicting the Design Thinking core motivations (and drawn on an iPad)

After a short introduction the business analyst will concoct a blasphemy of a UI which encompasses all user requirements, and every exception to those. The UI designer, who happens to know a thing or two about UX as well, then minimises everything to the bare minimum, accusing the business analyst’s UI from resembling R/3’s Create Sales Order screen and 90’s web design’s love child.

You, the developer, listens to both UI designer and business analyst, ask a few questions and maybe throw in a few ideas as well.

Then the inevitable happens, and both UI designer and business analyst turn their heads to you and ask:

“Can you develop this?”

Sure you can! Well, if…

If you were a Web Dynpro developer…

…you would probably draw a layout on the wobbly whiteboard in the corner, drawing the Dynpro controls as best as you could. Both the designer and business analyst shake their heads in disbelief over all the things not possible, and decide a couple more meetings are needed to get to something that fits the framework. After a couple of weeks where the three of you designed, redesigned, started all over and started all over again twice, no one is happy with the final results and everyone blames anyone for it.

Things might look a bit better if…

If you were an SAPUI5 developer…

…you flip open your laptop, navigate to SAP BUILD, and you start building your UI. The UI designer, now slightly more interested, battles with the business analyst over details on how the Object List Item should look. You set up your SAP BUILD layout so it already shows it as if it were on a mobile device.

The business analyst asks to add a subtitle to the lists, and a minute later after your project has been regenerated you show the final results.

The designer then asks if you could add relevant images to the List Items to make it more appealing as well as easier for the users to distinguish between the list items. You download a placeholder image somewhere and add that to the list.

In the end, everyone is happy the first designs could be cast in stone during the first 2-hour meeting, which leaves you the rest of the day figuring out how to translate the SAP BUILD design into clear, reusable code for your project.

But wait a minute!

Weren’t we tasked with creating a mobile application running on iOS devices?

Yes!

So, Web Dynpro is out of the question. Actually, Web Dynpro is out of the question for a couple of years now for any solution.

SAPUI5 could easily be used, but the application has some specific requirements with regards to performance and usability. Everything could sorta-kinda be solved by building the application in a hybrid Cordova or Kapsel container, and use a couple of plugins for the device camera and accelerometer, but it would never be perceived as snappy as a native solution.

Luckily, if…

If you were an iOS Swift developer…

…then things are looking much, much better! Instead of flipping over your laptop and start using a web application for designing something that will result in something native, you pick the device the envisioned application will eventually run on.

The UI designer, half thinking you will head to the mobile browser and run SAP BUILD from there, isn’t paying much attention when you tap the SAP Fiori Mentor icon on the home screen.

After one or two seconds the app is fully loaded and both the business analyst and the designer — who’s now fully interested in what’s coming next — glance over the iPad’s screen:

“Can you tap ‘See All’ next to the UI Components? I want to see what’s available“, the business analyst asks.

Sure, you think, and you tap the requested button.

The UI designer, now enthusiastic, asks “Can you scroll down a bit? There seems to be a lot more!“

You scroll down a bit until the UI designer suddenly yells in your ear, “There! That Timeline Cell control or what it’s called! That looks more or less like what I want! Can you open it please?“

Being the obedient developer you are, you tap the Timeline Cell tile, and the details for the control are shown, as well as a live preview:

Both the UI designer as well as the business analyst are now firing requests at you: “Can you show us how it looks like without a subtitle?” “What are those icons, we don’t need that!” “Can we change the time to something else?“

That’s when you tap the round button with the 3 dots in the lower right corner, and the Settings panel pops up.

“Ok guys, one at a time please — what do you want to remove or look different?” you ask.

As you quickly flip switches and toggle buttons in the Settings panel, the control preview instantly follows your changes.

And within a couple of minutes, both the UI designer as well as the business analyst are happy with the results.

The business analyst excuses himself and leaves for a call with the remote dependance in Trans-Kerbleckistan, confident in the imminent success of the project.

The UI designer, now alone in the room with you, asks “Well, er… now we agreed on the look and feel of the controls, how long will it take for you to implement?“

“Oh, no more than 3 to 5 minutes” you respond.

After a few seconds of utter silence, the UI designer hesitantly murmurs “…but… I don’t understand… How would you get from what we agreed on on your iPad to a working application?“

“I’ll show you. In fact, if you have three to 5 minutes, I’ll show you how I will go from our design to a working example on my iPhone.” you answer with confidence. “See this round button down here with that funky XML-ish icon? Look what happens when I tap it.“

“Hmmm,” the UI designer groans, “that’s just sample code… what good is that?“

“No, it’s actually pretty great! Yes, it is sample code, but it’s sample code based on the settings we tweaked. And it’s astonishingly simple to transfer it to my development laptop too! Look, if I tap the ‘Select All’ button and then choose ‘Copy’ from the popup menu, it is copied to the Universal Clipboard. If I now open Xcode on my MacBook…” you say, while you grab your laptop and fire up Xcode, “...I can paste what I copied from my iPad right into the Xcode project. I just need to bind the control’s properties to the underlying OData proxy classes which represent the data model, and we’re ready. Wait a sec.“

Within 30 seconds, you have changed the hardcoded strings in the pasted code with your object’s getter methods, after which you grab the entangled iPhone lighting cable from your laptop bag and hook up your phone to your MacBook. You hit ⌘-R to build and deploy the Xcode project on your phone, and wait for the app to start.

“Look, this is what our control looks like on an iPhone 7 Plus” you say, as you hand over your phone to the UI designer.

The designer, now genuinely surprised by the speed things are going, takes your phone, tilts, twists, and scrolls through the list in both landscape as well as portrait orientation.

“Sweet, it even behaves responsively!“

He hands you back your phone, hits you on the shoulder and trumpets, “never, ever have I seen a design being implemented that quickly! Well done pal! Come, let’s grab a latte.“

Bottomline

Ok, the above might be slightly exaggerated, but you can’t deny the following facts:

• By browsing and previewing the UI elements on the device it will end up on, you get a much better feel for the final result, something previewing on a non-iOS device is never capable of.
• You might think of the SAP Fiori Mentor app as a native counterpart to SAPUI5’s Explored app. However, the latter does not allow for tweaking of every parameter of every control.
• Being able to generate clean code from the settings you tweaked, and copy that code to your development machine works quite natural. It may seem odd to make an iPad a more or less integral part of your development workflow, but then again, when developing native iOS application you probably already have an iPad hooked up to your machine for deployment and debugging anyway.
• By sitting together with the key people who have something to say about the design, it’s much more productive to decide over designs using the more tactile iPad than a less-enticing laptop.
• Last minute changes can be made, decide on and implemented in no time.
• Deducting from all of the above, you can imagine this approach will perfectly fit Agile and Design Thinking teams.

If you really thought the SAP Fiori Mentor app was just a gimmick, think again. You’ll see it will make an integral part of your development workflow by acting as both an enabler as well as an accelerator for your native iOS projects.

Oh, and don’t forget to let me know what you think in the comments.

Happy designing & coding!