It is complex for non-geeks to understand the mobile application ecosystem. We often hear jargon such as mobile apps, hybrid apps, native apps, single-codebase-cross-platforms apps, etc.
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.