Websites have extra UI that you don't want in your app

Websites always have extra content which is not needed, when wrapping them in an app. They have a header title, a navigation menu, and a footer with extra links. Depending on how much "native" you want your app to appear, you will show a native navigation bar, a custom navigation flow and certainly not a footer under each screen.

If you are lucky, you can ask the website developer to create a special template for the app to remove those extra features and only show the main content. Otherwise you'll have to inject javascript to hide this content.

If the website contains a special "app" template, make sure you always use it

We built an app where the website had a special template. Each page could be loaded with the extra parameter mobile=true like http://www.liip.ch/?mobile=true. This worked great, but each link contained to the page did not have this extra parameter. If we’d simply allowed link clicks without filtering, the user would see the non-app pages. We had to catch every link that the user clicked, and append the extra parameter "manually". This is quite easy for GET parameters, but it can get quite tricky when POSTing a form.

Making sure users cannot go anywhere

By default a WebView will follow every link. This means that as long as the web page shows a link, the user will be able to click on. If your page links to Google or Wikipedia, the user can go anywhere from within the app. That can be confusing.

It is easier to block every link, and specifically allow those that we know, in a "whitelist" fashion. This is particularly important because the webpage can change without the app developer being notified. New links can appear on the application and capsize the whole navigation.

WebViews take a lot of memory

WebViews use a lot of RAM compared to a native view. When a WebView is hidden — when we show another screen or put the app in background for example — it is very likely that the system will kill the Android Activity that contains the WebView or the whole iOS application.

As it takes a lot of memory, it matches killing criterias to making space for other apps in the system.

When restoring the Activity or application which contains the WebView, the view has lost its context. This means, if the user entered content in a form, everything is gone. Furthermore, if the user navigated within the website, the WebView can’t remember on which page the user was.

You can mitigate some of the inconvenience by handling state restoration on Android and iOS. Going as far as remembering the state inside a WebView will cause a lot of distress for the developer :)

WebView content is a blackbox

Unless you inject JavaScript to know what is inside, you cannot know what is displayed to the user. You don't know which areas are clickable, you don't know (easily) if the view is scrollable, etc...

WebViews don't handle file downloads

On iOS, there is no real concept of file system, even with the new Files app. If your website offers PDF downloads for example, the WebView does simply nothing. An option is to catch the URLs that are PDFs and open Safari to view them.

On Android, you can use setDownloadListener to be notified when the WebView detects a file that should be downloaded instead of displayed. You have to handle the file download by using DownloadManager for example.

webview.setDownloadListener { url, _, contentDisposition, mimetype, _ ->
  val uri = Uri.parse(url)
  val request = DownloadManager.Request(uri)
  val filename = URLUtil.guessFileName(url, contentDisposition, mimetype)
  request.allowScanningByMediaScanner()
  request.setNotificationVisibility(DownloadManager.Request.VISIBILITY_VISIBLE_NOTIFY_COMPLETED)
  request.setDestinationInExternalPublicDir(Environment.DIRECTORY_DOWNLOADS, filename)
  val dm = context?.getSystemService(Context.DOWNLOAD_SERVICE) as DownloadManager
  dm.enqueue(request)
}

WebViews don't handle non-http protocols such as mailto:

You will have to catch any non-http protocol loads and define what the application should do.

The Android back button is not handled

If the user presses their back button, the standard action (leave activity, ...) will happen. It will not do a "previous page" action like the user is used to. You have to handle it yourself.

webview.setOnKeyListener { _, keyCode, event ->
 if (keyCode == KeyEvent.KEYCODE_BACK && event.action == MotionEvent.ACTION_UP && webview.canGoBack()) {
    webview.goBack()
    return@setOnKeyListener true
 }
  return@setOnKeyListener false
}

There is no browser UI to handle previous page, reload, loading spinner, etc...

If the website is more than one page, you need to have the possibility to go back and forth in the navigation history. This is important if you removed the website's header/footer/menu in particular. On Android, users can still use the back button (if you enabled it) but on iOS there is no way to do that.

You should offer the possibility to reload the page. Showing a loading indicator so that users know when the page is loaded completely, like in a native application or a standard browser helps.

This is no default way to display errors

When an HTTP error occurs, if you don't have a network connection for example, the WebView doesn’t handle it for you.

On iOS, the view will not change. If the first page fails to load, you will have a white screen.

On Android, you will have an ugly default error message like this one:

WebViews don't know how to open target="_blank" links

WebViews don't know how to handle links that are supposed to open a new browser window. You have to handle it. You can decide to stop the "new window" opening and load the page on the same WebView for example. But by default nothing will happen for those links.

iOS and security

iOS is — rightfully — very conservative regarding security. Apple added App Transport Security in iOS 9 to prevent loading unsecure content. If your website does not use a recent SSL certificate, you will have to disable ATS, which never is a good sign.

It is hard to make code generic

Since every page can be different, having different needs, it is hard to make code generic. For a client, where we show two sub-pages of their website on different screens, we have two webview handlers because of the various needs.

Once you have thought through all these things and believe you can start coding your webview, you will discover that iOS and Android handle them differently.

• On iOS every page load if caught by webView(_:decidePolicyFor:decisionHandler:) and can be treated by our code
  • Except target="_blank" links which have to be handled by webView(_:createWebViewWith:for:windowFeatures:) which is actually another delegate!
• On Android, only a subset of page loads are handled by shouldOverrideUrlLoading()
  • The first URL loading programmatically is always loaded
  • Only GET loads go through the filter. When POSTing a form, the handler is not called

There is a strong dependency on the website

Once you faced all challenges and your app is ready to ship, there is one last thing that you cannot control: You are displaying a website that you did not code, and that is most likely not managed by someone in your company.

If the website changes, there is a high chance that the webmaster doesn’t think of telling you. Mainly because he doesn’t think one change on the website is enough to mess up your app completely.

Conclusion

WebViews can be used for wrapping upon existing websites fast, but it is never "just" a WebView. There is some work to do to deliver the high quality that we promise at Liip. My advices for you:

• Use Defensive programming.
• List all features of each page with the client, and define the steps clearly, like for any native app.
• Get in touch with the website developer and collaborate. Make sure they tell you when the website changes.

You surely received many companies’ emails about your data privacy during last weeks. That’s due to the new European law (called GDPR for General Data Protection Regulation) that became enforceable on the 25th of May 2018.
This is a major step towards a more responsible usage of personal data by companies, as you can now request information on how your data is being used, and ask to change it.

Nevertheless, as James Aschberger (Founder & CEO of One.Thing.Less AG) noticed, many people didn’t understand how they can concretely claim their rights using this new regulation.

"It’s overwhelming, where do I even start?"

"I am worried about my data, but I don’t have the time or knowledge to contact companies individually or read through all the privacy policies and terms of use they put in front of me."

"I receive so many messages regarding data privacy, but I don’t understand all of it and don’t have time to read the fine print."

There is an app for that now

We at Liip have worked hard during the past four months to make the One.Thing.Less dream of James happen — a free and simple way to take control over the use of your personal data.

You can now download the app on the Apple App Store (and in June on Google Play for Android) and make your voice heard by companies.

One.Thing.Less mobile app Homescreen

Keep It Simple, Stupid (aka KISS)

When James first came to us, he made it clear that the User Experience had to be simple. That was one of our main challenge: solve this complex legal problem via one click.

This is what we did.

Ask companies about the use of your personal data, in one tap.

On the above view, you can just press the “Send request” to ask a company seven (simple) questions about the use of your personal data. Companies have to provide a response within 30 days under GDPR.

Then you can request them to change how they make use of your personal data, still one click away.

Change the way companies use your personal data

A trustful partnership

We can’t stop talking about trust here at Liip, as we believe that’s one of the core element of successful products and companies.
This project was a great example of how one of our mottos “Trust over control” can lead to extraordinary results, in less than four months.

"Successfully launching our platform in such a short time was only possible because we established and earned mutual trust along the entire journey together. If I had not been able to trust that each of the Liip team members delivers, we would have failed." James Aschberger, Founder & CEO at One.Thing.Less AG

"It was a chance to craft such a meaningful product, in a trustful and solution-oriented partnership." Thomas Botton, Product Owner at Liip

From idea to product

This product idea comes from James Aschberger, Founder & CEO of One.Thing.Less AG, who saw the opportunity in the new GDPR regulation to bring back balance in the personal data “crisis” that our world currently faces. Their mobile app will allow you — in one-tap — to ask for visibility on what some companies such as Facebook or Google or Starbucks have and do with your data. More importantly, once they answered, you will be able to act and request changes on how they deal with your personal data. The goal of the product is that you are in control of the use of your personal data.
I loved to hear such a pitch, and so did my mobile teammates. We hence kickstarted our collaboration back in January.

One.Thing.Less-Liip team during a User Experience workshop.

Finding a strong mobile partner, with the right (startup) mindset

One.Thing.Less’ challenge was their lack of an internal technical team. We solved their issue by putting up a cross-functional team tailored to their needs — composed of mobile and backend developers, as well as designers.

On top of this, and that’s maybe the most critical of all, we answered the need of James to find a trustworthy team with people having the right startup mindset:

“Once our idea was clear, the biggest challenge was to identify the right UX and technical team to bring it to life. Being a small startup, the chemistry needs to be right and the team mindset needs to be diverse. After our first meeting with Liip I had a strong feeling about the team and their know-how. It was after the second meeting that we were totally convinced that they not only have the technical expertise but also the right spirit and determination to bring this idea into a tangible product.” — James Aschberger, Founder & CEO of One.Thing.Less AG

We at Liip are all entrepreneurs, and the way we are self-organized allows us to act as such on a daily basis. This reassured and convinced the CEO of One.Thing.Less that Liip was the right choice.
It’s been only three months that we work together, but we already feel like we are one unique team, with one common goal — that is to launch a product that will impact lives positively.

Development of the One.Thing.Less mobile app and platform.

Data, public or private, should be controlled by whom it belongs to

If you follow us since a while, you surely know that the data topic is part of our DNA. From API to allow interoperability of IT systems, to Open Data to give back transparency to citizens, we were always involved in such domains and will remain for the long run. This collaboration with One.Thing.Less confirms it.

We can’t wait to put this product into your hands on the 25th of May. Stay tuned and sign up for a launch notification at www.onethingless.com

Within this past year, we successfully shipped two applications using Kotlin exclusively, with another one to follow soon. We decided to also use Kotlin for previous Java apps that we keep updating.

I took my chance when the Mobile Romandie Beer meetup was looking for speakers. I knew that I had to show others how easy and fun this language is.

It turned out great. We had people from various backgrounds: from people just curious about it, UX/UI designers, iOS developers, Java developers to people using Kotlin in production already.

You can find my slides below:

I would like to share a few links that helped me learn about Kotlin:

• Kotlin Koans: a step by step tutorial that directly executes your code in the browser
• Kotlin and Android: the official Android page to get started with Kotlin on Android
• Android KTX: a useful library to help with Android development, released by Google

See you at the next meetup!

The golive happened successfully last week — yeah!, and while we prepare our celebration lunch, I thought it is maybe interesting to share the challenges we faced during this purposeful project, and how we overcame them.

Make The User Use The App The Least Possible!

This product development was particular because we soon realized that for once, we were crafting a mobile app that should be used the least possible. That’s for a goal when all what we hear nowadays is about user retention and engagement.
The point is that Urban Connect service is about providing a bike solution with a smart lock that can be opened with your smartphone (via Bluetooth technology). People want to use it to book a bike and go from a point A to a point B, with the least friction possible — including with our mobile app software.

This key discovery was possible thanks to our UX workshops that focus on the user problems first. Concretely, it means that we went to the Google Zürich office to analyze and listen to how real users were using the solution, and which problems they had. That’s when we got that users wanted to use the app the least possible, and that it works automagically without getting their smartphone out of their pocket.
It’s only afterwards that we started to draw the first wireframes, and iterated on prototypes with Urban Connect and its clients to be sure that what we’re going to build was answering the real issues.
And finally, we developed and applied the user interface design layers.

This resulted in one of the Google users stating:

“Wow, that’s like a Tesla!
I never use the key, but it’s always there with me, and it just works.”

Again, we looked at the problems first, not at the design aspects. It may sound simple, but it still isn’t such a mainstream approach as one could think.

On Third-Party Smart Locks, Fancy Android Phones, and MVP

Most of the struggles we had to overcome were linked to the Bluetooth connectivity between the smart locks from Noke, and the Chinese Android devices.

The issues we faced with the Noke Smart Lock solution were that the company is still a startup, and as such, there are still some perks to their product such as outdated documentation, or hardware reliability.
Nevertheless, our solution was to not enter in a blame game party with them and Urban Connect, and rather contact them directly to fix the problems, one at a time. We must say that they were really responsive and helpful, so much that all of our main blockers were removed in less than a few days each time.
But that’s something to take into account in the planning and investment margin when you do estimation — thankfully we did!

Testing Session of our Urban Connect Mobile App.

As for the fancy Android phones, that’s the same story one hear everywhere: Android devices’ fragmentation sucks. We’re prepared to face such issues, and bought many different Android devices to be sure to have a good coverage.
Nevertheless, there are always corner cases such as a fancy Chinese phone with a specific Android ROM — one that is obviously not sold anymore to simplify the thing.
We overcame this issue thanks to a simple tool: communication. We didn’t play the blame game, and got in contact with the end user to figure out what was the problem on his device, so that we could understand it better.

Although communication is a good ally, its effect is the most effective when you start to use it as early as possible in the project.
As we use the Minimum Viable Product approach to develop our products, this allowed us to focus on this critical points upfront from day one, face them, and find solutions — vs. building the entire thing and being stuck at the golive with unsolvable issues.

Trustful Partnership as a Key to Success

On top of the usual UX and technical challenges that we face in every project, one key to the success of this product launch was the people involved. And the trustful collaboration between Urban Connect and us.
We faced many different challenges, from unexpected events, to sweats about planning deadlines (we made it on time, be reassured). And every single time, Judith and her team trusted us, as we did all along the way. Without this trust, we could have failed at many points during the project, but we both chose to remain in a solution-oriented mindset, and focus on the product launch goal. It proved to work, once again.

A Trustful Partnership as the Key to a Product Success.

What’s next for Urban Connect?

Now that we happily pressed the “Go Live!” button, we’re first going to celebrate it properly around a nice lunch in Zürich. It was intense, but we love to work on such purposeful products which will help cities get more healthier thanks to less pollution and more physical activity for its users.

Then, we’ll have plenty of features to work on in 2018, including innovative ones like integrating IoT modules to the platform. We’ll make sure to share such new cool stuff with you.

In case you want to learn more about Urban Connect e-bike fleet service, feel free to contact Judith to get more infos and a demo of our solution.

A successful startup

Judith Häberli founded Urban Connect in 2013. As CEO, her first concern was to test the market as soon as possible with a real product. For this reason, the team developed its initial minimum viable product. About a year later, the startup found its market and matured into an established enterprise in the mobility market. Today the proof-of-concept is achieved. Optimizing the user experience, improving the system stability, and having a better software evolutivity are the next challenges.

On Urban Connect office’s terrace in Zürich for our partnership kick-off (from left to right): Judith (UC), Noé & Darja (Liip), Luting (UC), Jonas & Thomas (Liip) and Robert (UC).

Towards a robust and scalable software base

In order to ensure the next maturity level of the company, Urban Connect asked us to partner on the development of their product: new iOS and Android mobile applications connected to a hardware device, a new Fleet Management System, and a new API. The deadline is tight, in order to keep their customers satisfied. At Liip, we will put a strong emphasis on a flawless user journey, backed-up by a robust technical implementation. It will provide Urban Connect with the basis needed to grow during the upcoming years.

Our commitment to delight Urban Connect users

Our UX process will support Judith and her team to craft a new solution that is designed around the users. We will then develop it iteratively in order to receive user feedbacks as early as possible.
We are excited to start this new partnership as it is exactly what we love. Indeed, we like to be fully involved from the start, and to work in an entrepreneurship spirit.

The major components

So how's Houston working? Here is an overview of the major components. Houston is a distributed system composed of:

• Two Mobile Apps that fulfill the specific need of bus drivers and team leaders
• A Web Client used by the operators to create any type of call
• A Cloud Communication Platform to establish Voice over IP (VoIP) and standard phone call over the Public Switch Telephone Network (PSTN) without having to deal with the complexity of building and maintaining a communication infrastructure. The cloud platform used in this system is Twilio (more details on that later)
• A Public API : implemented by a backend server used as a bridge between mobile apps, web clients and Twilio. It is connected to a database that stores user identities and bus planning. The database also keeps traces of all performed calls.

A deeper look inside each component of the system and how each of them interacts together will help to understand why Houston was a huge challenge.

Mobile Apps

Each of the two mobile apps provide specific features for busses and team leaders. There is no specificities in how the app is built. The apps are a set of views that allow to perform calls by communicating with the public API using standard HTTPS requests and JSON formatted messages.

The real challenges were the following:

• How to allow drivers to use an app without losing eyesight of the road?
• How to integrate the app with the existing busses microphone and loudspeaker?
• How to manage and upgrade a set of more than 200 devices remotely, as they are installed in busses dispatched in different locations?

How to tackle the usability problem?

To tackle the usability problem, we organised workshops with the end-users (e.g. drivers) to find out the best way to interact with the app without having to look at the screen. The solution found, was to implement a carousel screen with voice feedback at each screen change.

The integration with the existing microphone and loudspeaker has been solved with the installation of a bluetooth amplifier. The big problematic here was to ensure that the app was automatically connected with the amplifier at any time.

Finally, we decided to use Android4Work and MobileIron to manage the 200 devices distantly.

About the importance of user testing

We started with a prototype running on a server and on real devices. It was working like a perfectly in our offices. However, we should have installed the busses applications in real busses and let final users try it in their daily business. Even though we made many workshops with end users, a sketch on paper doesn't replace the real experience.

Deploying the prototype in the real environment would have save a lot of time! In fact, we ended up implementing some features that have not been used as much as we initially thought.

Another important lesson learned by our development team of mobile developers is that working with physical devices such as microphones and loud speakers is not trivial. We underestimated the impact of the environment on the device. Indeed, we had quite a bad surprise when we discovered after months of development that the volume in the busses was fare too low. Again, making a prototype working in a real environment would have helped.

Web Client

The web client is a single page application built using backbone JS. The challenge of the web client development was less in its technical aspects than in the definition of the features needed by the operators. In fact, it was difficult to make a system working similarly as a radio in a web browser.

To help operators understand what was happening as they created calls, we decided to display as much information about the state of the call as possible. For example, operators know – from the start of the call – which users are included in it as well as their current state.

Twilio

Twilio is a cloud communication platform offering an elegant way to perform any type of call such as a telephone conference. It offers a RESTful API that completely hides the complexity of the infrastructure behind. Thanks to Twilio, the Houston public API offers the possibility to create conferences between more than 50 users in only one request.

Twilio API offers tons of features. The most used one in Houston are the followings:

• Getting real time information about ongoing and past calls.
• Muting / Unmuting users
• Adding / Removing users to an ongoing conference

But this is not all, Twilio can register calls and offers a nice administration web client allowing to retrieve all records as well as the detailed logs of all performed calls. In addition to that API, Twilio offers libraries for web clients and mobile applications. This helped us a lot to handle incoming/outgoing calls.

Heroku

The public API offers a standardised set of endpoints to serve requests from the mobile applications and from the web client. We hosted it on Heroku in order to get rid of the hosting complexity.

Heroku allowed us to easily scale when the amount of user of the system raised. With Heroku It has been a piece of cake to integrate our system with Twilio and It solved lots of security issues.

Conclusion

Lessons learned during this project are numerous. The most important to remember is that innovation requires to start with a simple feature and to make it work in the final environment. User workshops and controlled environment testing is not enough. It is essential to test prototypes in a real environment with real users.

Finally, I think that what had most impact on the success of the project is the way we worked hand in hand with the client. From the beginning, we collaborated as one team. We were able to share challenges and issues. We did not hide problems, but talked about them openly to find the best solution together.

What's next

Hundreds of people use daily Houston. Of course there is still many improvements to bring. Today, we are still working on the project by analysing its use in order to improve it by bringing additional or improved features to make this system even easier and powerful to the end users.

Once the system will be stable enough, the door to many developments opportunities will open. Other sectors might be interested to implement similar systems. The good thing is that our team has become very experienced with these topics.

Finally, our team was delighted to be awarded 4 times in 2016 for this awesome project : 2 awards at the Best of Swiss Apps 2016 (“Silver” in Enterprise category and “Gold” in Innovation category) as well as 2 award at the Meilleur du Web 2016 (Winner in UX and in Technology Categories). These awards will just continue to fuel our appetite for more innovation and success! :)

With the project Houston, we took the challenge of replacing the old radio network of the Transports Publics Fribourgeois (TPF), a swiss public transportation company by a system using existing data network and running on mobile applications. This solution solved the problem of maintaining a dedicated radio network. It also improved both the global quality of the communication and the availability of the system.

Initial situation: communication based on radio system

Since decades, employees of the Transports Publics Fribourgeois (TPF) have been using standard radio to communicate between them. The radio system is meant to cover the needs of the users. It is spread over more than 200 busses, 30 team leaders and the operation center). There are three types of users, with specific needs:

• The operators – working in the operation center – use the radio to speak to a specific bus driver, or to broadcast messages to all or part of the running busses.
• The team leaders are dispatched at different locations. They use the radio to manage daily events – such as the replacement of a driver – or to inform many drivers of a change in the network – for example in case of an accident.
• The bus drivers use the bus radio as the main means of communication while driving. They can call other busses, the team leaders or the operation center.

The project: replace the old radio system

The radio system used by the employees of the TPF had some drawbacks :

• The poor quality of the communication,
• The low coverage of the network (about 60% of the territory. This is because it is too hard to cover the all territory since busses drive all over the countryside),
• The exploitation and maintenance cost of the a radio network were expensive (antennas were installed in strategic locations, all over the canton).

The goal of the project Houston was to improve the former system by replacing the radio communication system.

The challenge was to provide at least all already existing features and possibly add some new one enabled by the geo localisation of the busses. The possibility to call all busses currently in a given region was one of the new requested feature. 

Screenshot of the app Houston

The solution: a mobile application

A mobile app would allow the system to modern technologies. With a mobile app, we also expected to drastically reduce the exploitation cost. Indeed, with a mobile app, it is not necessary to install and maintain radio antennas all over the Fribourg region.

We decided to create a mobile app, because they are easy to develop in comparison with dedicated embedded devices. The cost of 200 smartphones is more than justified by the flexibility and development cost that this solution offers.

We started by building trust

The way we worked hand in hand with the client had a huge impact on the success of the project. From the beginning, we asked all stakeholders and end users to explain us how they worked together with the former system. We asked what the strengths and the weaknesses of the system were. We asked them how they would like to use it.

As a result, we had a good idea of what the main features to implement were. Most importantly, we also gained the trust of the end users.

The fact that there was such a level of trust, was a good basis to develop the project. We were not hiding problems, but we were exposing them directly to find the best solution possible together. This collaboration mindset helped a lot during the development of the project.

Additional Information

Best of Swiss App 2016: Houston wins Silver in the «Enterprise» category and Gold in the «Innovation» category (read here)

HOUSTON: The first VoIP Communication System for Swiss Public Transportation (read here)

Meilleur du Web 2016: HOUSTON awarded in the category UX and Technology (read here)

Some clarification is needed.

The Difference Between Native and Hybrid Apps

In this article, we talk only about apps that one can download from an app store (and not about mobile websites).

Native apps are mobile applications that are written in a native language such as Swift for all Apple iOS apps, and Java for all Google Android apps. You have to write the code two times, once for each platform, which results in more development and maintenance work.

Hybrid apps are based on a single codebase that produces mobile apps for both Apple and Google platforms.

Both native and hybrid applications are on app stores. Both are downloaded on your iPhone or Android smartphones. Both can be opened. Both can send push notifications. Both can be deleted from your smartphone. No matter what's inside.

Native or Hybrid App, Which One Should I Build?

“All this is very interesting, but what should I use for my next mobile product?”, you may wonder.

At Liip we use the following criteria to guide our strategy:

Internal Business Logic If the app contains more than 50% business logic stored on the smartphone directly (vs. business logic stored at a backend server), then it's worth investing into a hybrid solution as the mutualization of code will have a significant financial impact on the project. An example we worked on is the Schindler elevators mobile app with its offline requirements that required to store the logic on the smartphone app.

In the other case, we favor native mobile apps.

Custom Design When the app has a lot of custom visual components (e.g. not the default list views proposed by Apple or Google), then we recommend to craft a native app as the hybrid approach wouldn't bring any mutualized value here because you anyway have to build custom User Interface for each platform.

On the left is a list using standard Apple iOS visual components, and on the right the example of the UEFA Champions League mobile app with a custom list view.

Reliance on Third Party Plugins If your project relies on one or more third party plugins (aka SDKs), like for instance Tealium (a data management tool including Analytics monitoring), then we recommend to build a native app. These plugins are written in Swift and Java so you never have compatibility issues with native apps.

This criteria comes from an experience we had where we spent a lot of time integrating a third party plugin within a Xamarin hybrid app project.

It is a Weighting Game

As we often claim, we are not religious with technologies here at Liip. There is no magic formula that can be applied to all projects; we always have to ponder each criteria together with the client in order to find the best fit for his situation.

Do you have experience with one or the other kind of mobile application? Bad or good, share your story with us.

We booked a one-day hands-on with Noé in our ThinkSpace war room with the objective to have a demo app up and running and plugged to the SAP Cloud Platform (formerly known as SAP Hana). This may sound like an easy goal but honestly, knowing SAP, we thought that it was already ambitious.

Lesson learnt #1: One can easily create a SAP Cloud Platform demo account

We imagined it would require many days to have our Liip's SAP Cloud Platform up and running with validation processes and all. That's old-thinking. It took Noé less than half an hour to have it ready.

It may be different with a production environment but still, the developer experience was great as one can have a playground and try to build a Minimum Viable Product (MVP) straight away.

Lesson learnt #2: The SAP SDK provides a skeleton app — really — ready to play with

When we browsed the tutorials on the SAP blog, we're again (positively) surprised to see that the SAP team crafted a demo app that was supposedly ready-to-use. And it was!

In less than 3h, we installed the app, and connected it to our Liip's SAP Cloud Platform from which we could read and write data. It actually required more time to register and activate all needed modules in the SAP Cloud Platform than to actually deploy the app on Noé's iPhone!

Lesson learnt #3: iOS SAP SDK documentation is not centralized enough

One drawback SAP has to fix if they want developers to catch-up on their new tools is the documentation. Although the skeleton app works out-of-the-box, we had hard times to follow the setup steps which were spread over the main homepage, various tutorials, and other articles. For instance, there are several modules and settings to configure and we took a lot of time to figure it out. If some SAP engineers read these lines, please keep up the good work and remove the complexity from your documentation.

Our SAP iOS mobile application demo

Lesson learnt #4: “SAP Fiori for iOS” documentation is complete and well structured

Compared to the previous point, the User Experience and Design documentation of SAP Fiori for iOS is impressive: it is well structured, complete, and easy to get through. All usual business use-cases are covered in a deep manner with all needed details about user flows.

I can't help but recommend the development department at SAP to follow their path as it would help the community to engage more, and as a result their products would take off more quickly!

SAP Fiori for iOS User Interface Example (credits: SAP website)

Lesson learnt #5: User Interface customization will take you more than a day

Once we got the app and SAP environment ready, we dived into the code in order to play with screens' layout and data flows. As one might expect, that's what the demo app is for: testing in a playground. But when we wanted to customize the design to match our Liip corporate identity, we saw the limitation of the demo app: although it's not a blocker at all, it's good to know that it will require you more than a one-day workshop to get it implemented.

Summary

Below is what we achieved in less than a day with this new iOS SAP SDK:

• Setup of a Liip SAP Cloud Platform demo account with sample data
• Running an iOS demo app on our iPhone
• Live synchronisation of data between the app and the SAP Cloud Platform
• Dive into the “SAP Fiori for iOS” documentation

Did you play with the SAP SDK for iOS yet? Or even better, did you already release publicly an iOS app based on SAP? I'd be glad to share on the topic around a coffee or via the comments' section below.