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.

But how do you compare projects? I decided to use line counting. It can seem obvious or simplistic, but the number of shared lines of code will easily show how much work has been done once instead of twice. I took the two most recent Xamarin projects that we worked on Ticketcorner Ski and together.

I used the following method:

• Use the well-known cloc tool to count the number of lines in a project.
• Count only C# files.
  • Other types such as json configuration files or API response mocks in unit tests do not matter.
• Make an exception with Android layout files.
  • Our iOS layout is all done in Auto Layout code and we don't use Xcode Interface Builder.
  • To have a fair comparison, I included the Android XML files in the line count.
• Do not count auto-generated files.
• Do not count blank lines and comments.
• Other tools like Fastlane are also shared, but are not taken into account here.

If you want to try with one of your one project, here are the commands I used for the C# files:

cloc --include-lang="C#" --not-match-f="(([Dd]esigner)|(AssemblyInfo))\.cs" .

For the Android XML layouts, I used:

cloc  --include-lang="xml" --force-lang="xml",axml Together.Android/Resources/layout

Here is what I found:

We can see that on those projects, an average of one third of code can be shared. I was pretty impressed to see that for Ticketcorner Ski we have the same number of lines on the two platforms. I was also pleasantly surprised to see that the project almost shares 40% of its code.

In a mobile app, most of the unit tests target the business logic, which is exactly what is shared with Xamarin: business logic and their unit tests are only written once. Most libraries not directly related to business logic are also shared: REST client, Database client, etc...

The code that is not shared is mostly UI code, interaction, etc... But it is also platform specific code: how to access the camera, how to handle push notifications, how to securely store user credentials according to each platform's guidelines.

It would not be fair to conclude that doing those projects in native would have been 30% more expensive. The shared code has sometimes to take into account that it will be used on two different platforms, and it gets more generic than it would be if written twice.

So... how do you choose one or the other ?

My goal with this blogpost is not to start a flame war on whether Xamarin is good or bad. I have shown here that for those projects, it was the right choice to use Xamarin. I want to share a few things we think about when we have to make a decision. Note that we use Xamarin.iOS and Xamarin.Android, but don't use Xamarin.Forms.

• Does the application contain a lot of business logic, or is it more UI-based?
  • With one Xamarin project we worked on in the past year, a specific (and complex) use-case was overlooked by the client and it resulted in paying users being pretty unhappy. We were very pleased to be able to fix the problem once, and write the related unit tests once too.
  • As a counterexample, for the Zürich Zoo app, most of our job was writing UX/UI code. The business logic is solely doing GET requests to a backend.
• Do you plan to use external libraries/SDKs?
  • Xamarin is pretty good at using .jar files on Android.
  • Native libraries on iOS have to be processed manually and it can be tedious to do. It is also hard to use a library packaged with CocoaPods that depends on many other pods.
  • For both platforms, We encountered closed-source tools that are not that easy to convert. As an example, we could use the Datatrans SDK, but not without some trial and error.
  • There are however other Xamarin libraries that can replace what you are used to when developping on both platforms. We replace Picasso on Android and Kingfisher on iOS by FFImageLoading on Xamarin. This library has the same API methods on both platforms which makes it easy to use.
• Do you plan to use platform-specific features?
  • Xamarin is able to provide access to every platform feature, and it works well. It is also known that they update the Xamarin SDKs as soon as new iOS/Android versions are announced.
  • For Urban Connect however, the most important part of the app is using Bluetooth Low Energy to connect to bike locks. Even if Xamarin is able to do it too, it was the right decision to remove this extra layer and code everything natively.
• Tooling, state of the platform ecosystems:
  • In the mobile world, things move really fast:
    • Microsoft pushes really hard for developers to adopt Xamarin, for example with App Center, the new solution to build, test, release, and monitor apps. But Visual Studio for Mac is still really buggy and slow.
    • Google added first-class support for Kotlin, has an awesome IDE and pushes mobile development with platforms like Firebase or Android Jetpack.
    • Apple follows along, but still somehow fails to improve Xcode and its tooling in a meaningful manner.
  • Choices made one day will certainly not be valid one year later.
• Personal preferences:
  • Inside Liip there are very divergent opinions about Xamarin. We always choose the right tool for the job. Having someone efficient and motivated about a tool is important too.

I hope I was able to share my view on why and how we use Xamarin here at Liip. I personally enjoy working both on Xamarin or native projects. Have a look at together and Ticketcorner Ski and tell us what you think!

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

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.

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.

I have this discussion every week with new clients, and I thought it was time to share our reasoning here at Liip in order to give you a clear answer if you still hesitate.

Do You Want To Reach Your Users, or Bring Rich Features to Them?

When clients come with a mobile app request, I explain them that most of the time, a web application is more efficient in terms of investment, as well as in term of reach.

The second question I get after this answer is: “When would I need a mobile app, then?”

In my point of view, mobile apps are useful when they are crafted to be rich — vs. the reach that web applications can provide. Rich in terms of features that are only available on mobile devices, and that can't be achieved via web technologies.

Here is a non-exhaustive list of smartphones features that could be useful to your product:

• Bluetooth — to connect to a supply chain system
• Geolocation/geofencing — to contact only the employees you need (i.e. avoid information overload), such as with the TPF Houston product
• Beacons for indoor localization — to guide a user based on its location context
• Push notifications — to inform people in a timely manner like goals scored in the UEFA Champions League app
• Camera usage — to scan a barcode to identify a drug such as in our Patchie medical project
• Augmented Reality — to enhance human capabilities like the Daqri innovative tools which we investigate currently
• Fingerprint authentication — to improve the User Experience by shortening the “painful” steps such as entering your password
• Offline capabilities — like the offline local search in our Schindler app for elevator repairers

Loyalty vs. Visibility

If you are already established on the digital market, a mobile app is a great loyalty tool to invest in, as it engages your audience more. From the comScore 2016 App Report, one can learn that users spend 20x more time on apps than mobile website visitors. A bit like if an app created a bubble of attention focus. Something that the web, by essence with its linking nature, doesn't provide to visitors.

Users spend 20x more time on mobile apps than on mobile websites (Credit “comScore 2016 U.S. Mobile App Report”)

However, if you aren't known yet, a website viewable on smartphones/tablets/desktops might help you to stand out as the average monthly audience is 3x more important on websites than on mobile applications.

Mobile websites reach 3x more visitors than mobile apps (Credit “comScore 2016 U.S. Mobile App Report”)

It's Not a Religious Choice

The time when you needed to choose one way or the other is behind us. Both solutions have their pros and cons, depending on your needs. In an ideal world with unlimited budgets and no deadlines, both solutions should be implemented for different purposes.

If you're not in this comfortable solution, you better start with what is the most critical to your business: engage more an existing audience? Or expand your audience reach?

Rich vs. Reach — The Summary

If your objective is to provide a rich experience to your clients, using the full native features offered by the latest smartphone, then you should go for a mobile application that will allow you to retain them longer.

If you're in the B2B sector or have internal needs, then there are even more chances that a mobile app is a good choice for you. A choice that can leverage smartphones' native features that are often what can bring more efficiency and productivity in industries.

If the goal of your new product is to reach as many customers as possible, and that you don't need to access to specific smartphones capabilities, then you should go for a web application.

“Mobile apps engage an audience. Mobile web expand audience reach.”

I'm always interested to challenge assumptions when it comes to choose between a mobile application and a responsive website, so don't hesitate to share your use cases in the comments section below, or come to our office to chat around a coffee.

Animating your logo with After Effects

The first part is creating the animation with Adobe After Effects. After Effects is a powerful tool that is used to create digital visual effects and motion graphics. Starting with After Effect is fairly easy. Animating a logo for example will take you a few hours. Read my last blog post and go for it:  Adobe After Effects: how to get started?

This tool is mainly used in film and television production although is also popular to create UI/UX animations among designers.

If you need inspiration, you can see many examples of animations in the popular website dribbble.com.

In this tutorial we won't cover how to create an animation, but how to use it in your app.

To export and use an animation in your App, you can use  Bodymovin and Lottie. As we will see in this post, both of them have advantages and limitations. It's better to be aware of them before starting your work on your animation.

Exporting the animation with Bodymovin

Once we have the animation created the next step is to export it with Bodymovin.

Bodymovin is an After Effects plugin for exporting animations into a JSON file. Bodymovin is an open-source project. We can follow the current state of its development.

There are different ways to install Bodymovin plugin. The easiest/recommended way is to download the zip file from the github repository, then extract the contents and get the .zxp file from ‘/build/extension', and finally use the ZXP installer to install it in After Effects.

After this, the process to export the animation is simple and straightforward. Follow these steps:

1.- Open your After Effects project and select the Bodymovin extension on Window > Extensions > Bodymovin .

2.- Click refresh to get a list of all your project compositions, then select the composition you want to export.

3.- Select the destination folder for each of the compositions you want to export and save the JSON file.

4.- And finally click render .

5.- Hooray! Animation is exported into a JSON file so we can move to the final part of our tutorial.

Using Lottie to import the animation in your project

Once the animation is created and exported into a JSON file it's time to import and render it into to your App project. Thanks to AirBnB now we can do this with Lottie .

Lottie is a new open source library coming from the AirBnB Engineering department which helps you to add high-quality animations to your native app.

The basic idea of Lottie is that renders an After Effect animation in real time, allowing you to use animations as easy as adding a new view/layer to your iOS, Android or React Native App.

Continuing with our example, at this step we are going to import the data.json file that we have exported from the previous step into the iOS project.

The next step is to add the Lottie Library to your project.

Including Lottie in your iOS project

This can be done easily using CocoaPods since the project is CocoaPods compatible.

pod 'lottie-ios'

Then import the framework in your class.

import lottie

Once the framework is imported, it's time to add the LOTAnimationView to your view.

let animationView = LOTAnimationView.animationNamed("data")

self.view.addSubview(animationView!)

And finally play the animation.

animationView?.play(completion: { (finished) in

 // Do Something

})

Including Lottie in your Android project

To include it in your Android project start by adding the dependency in your build.gradle file.

dependencies {  
  compile 'com.airbnb.android:lottie:1.0.3'
}

After downloading the library, it's time to add the view your your project and play the animation.

LottieAnimationView animationView = (LottieAnimationView) findViewById(R.id.animation_view);
 ...
 LottieComposition composition = LottieComposition.fromJson(getResources(), jsonObject, (composition) -> {
     animationView.setComposition(composition);
     animationView.playAnimation();
 });

Including Lottie in your React Native project

To get started install the node module in your project.

npm i --save lottie-react-native

For iOS, add the pod your Podfile.

pod 'lottie-react-native', :path => '../node_modules/lottie-react-native'

For android, you can react-native link as well.

react-native link lottie-react-native

Example of how to use it in your code.

import React from'react';
import Animation from'lottie-react-native';

export defaultclassBasicExampleextendsReact.Component {
  componentDidMount() {
    this.animation.play();
  }

  render() {
    return (
      <Animationref={animation=> { this.animation = animation; }}style={{width:200,height:200,        }}source = {require('../path/to/animation.json')}
      />
    );
  }
}

Why Lottie?

The main advantage of using Lottie is that animating CALayers (iOS) to generate complex animations is a tedious and very complicated job, instead it's more user friendly to create the animation using After Effects.

Current Limitations with Lottie

At the current time of writing this post, there are some important limitations when using After Effects+Bodymovin+Lottie combination.

One of the most important limitations are that there is no support for animating text layers as well as animating image layers using Lottie.

Because Lottie library is an open source project we can see for each platform the current development status and the list of feature requests for iOS, Android or React Native.

Conclusion

Creating a visually complex animation with After Effects takes time but it takes even more time to code it in a native app. From my point of view there is no need for small and simple animation to use the After Effects+Bodymovin+Lottie combination. On the other hand I do recommend using this animation stack for more complex animations.

Furthermore, before designing an animation with After Effects is very important for the designer to be aware of the current limitations of Bodymovin and Lottie at the time of designing it so there are not any visual differences of the final result.

Manuel Escrig @manuelescrig