Why Platform-Native Frameworks are Better Than Mobile Hybrid Frameworks

There are many ways to build an app.
Let’s take a look at frameworks of mobile development.

The easiest way to develop a mobile application is to not develop one. Every mobile device has a web browser and email client. So, we can interact with our users through these channels. Of course, this would not produce the best user experience in most cases.

History of Hybrid Frameworks

Cordova

The first widely used hybrid framework was Cordova, created by Apache Foundation. It allows us to ship local website in application shell. However, because of internal local WebView, Cordova doesn't produce the best user experience either. In short, Cordova is slow and limited in functions, but hybrid and free. Because of that, we can now see tons of hybrid frameworks built on top of Cordova.

Xamarin

In 2012, the Xamarin project proposed to build native apps for both platforms from a single project. The C# code compiles to native (binary) code, which theoretically, can be faster than platform-native applications. Now, Xamarin belongs to Microsoft and all apps are developed completely in the framework in C#. Even though it's hybrid, developers still should be familiar with platform specifics.

In around 2014, many entrepreneurs came together and concluded that we will never develop two versions of the same app (or third - Windows Phone, which existed at that time) because we can develop one app and compile it for each platform. In 2017, no one's developing apps using Xamarin. Here are the main reasons in my opinion:

1. Very slow compilation time
2. More bugs (in addition to Native platform bugs, you’ll get hybrid framework bugs)
3. Lack of tools — profilers, debuggers, IDE end-to-end refactoring from views definition to usage, plugins, instant run, custom build tools, libraries, written for mobile etc.
4. Platforms are very different

I believe my last point was the main problem — most platforms have different guidelines and permissions. They are essentially two completely different ecosystems. In most cases, there are no ways to create an abstraction – in big production projects, we started to see two versions (3 at that time) of UI, platform interactive modules, background work modules, and so on. In the end, these projects actually took longer to develop because of the lack of tools (native frameworks were ~7 years old at that time). Furthermore, in many cases, sharing API calls and abstracted business logic did not compensate for this disadvantages in the long run.

Keep in mind, I've left out problems with regard to runtime performance and application size.

The first two problems can be fixed relatively quickly. If Microsoft really wanted to tackle the other two, it would have to spend more than what Google and Apple has spent on platforms development in the last 8 years, combined. That is unlikely (considering that Microsoft cannot even implement pushes in Skype to work reliably after all these years.)

Most Populat Hybrid Framework: React Native

In 2015, Facebook announced React Native framework.

React Native compiles dynamic JavaScript code to native views at runtime. The rest of the code runs in the additional virtual machine, packaged inside of application itself.

Facebook learned from Xamarin’s pain of trying to abstract platform specific APIs. So, in React Native, platform specific code are written in platform specific technologies (in Java-Kotlin (XML views)/ObjC-Swift). Instead of two projects, we now have one project written in at least 4 different languages. This project does not have end-to-end refactoring and consist of different platform modules that are glued together.
In my opinion, it still has the same problems as Xamarin, except compile time.

If so, why has there been such a hype of React Native in the last few years?

Because people usually compare React Native with Cordova and its family. They like to pretend that Xamarin never existed. They also don’t talk about Flutter (which is 3 years old and still alpha when I last wrote it). And React Native is a lot more popular among web developers.

Web developers know that Cordova allows them to pack web projects into mobile app shell and they love React frontend library, which is widely used. On the other hand, Xamarin is not very well-known in the web world. As a result, web devs can now create mobile apps with all the know web best practices and approaches.

Pros

The main advantage of React Native is its popularity and wide usage. Most small startups might have one Android developer, one iOS (working with the same codebase) developer, and a couple of web developers. They might even hire another specialized mobile developer that knows platform APIs, guidelines, and best practices (See Why You Should Quit Looking for Ninja Developers) very well. With React native framework, the bar for mobile developers has to be raised — now they not only have to know native mobile tools, but also React Native framework. The good thing about this is, if any developer's down, the rest of the team can at least do some fixes and improvements because all of them would, ideally, use the same language, library/framework, approaches, and some of the best practices.

This is a huge advantage that makes startup teams much more flexible. It gives them the ability to move members between teams and help each other out.

Cons

On the other hand, if the team consists of developers who are specialized in each platform, there would be no need to move people from platforms to platforms. Developers may not know each platform well and may not collaborate effectively. Having two apps in one codebase, with a small amount of shared code, will be more of a problem in terms of merge conflicts.

Mobile apps usually don’t have much of a difficult logic for two reasons:

1. Performance/battery consumption: Mobile devices are still much slower than normal computer
2. Security: Client side is often more vulnerable than server side because hackers can search it without any limitations, brake, and debug it. On the other hand, the server is a black box and is much less accessible to the malefactor.

But sometimes, we do need some complex logic in the device (e.g. Google Maps). Those complex and performance-critical tasks developed in the platform-independent binary library, mostly in C++, are attached as external dependencies to both mobile projects.

Conclusion:

Hybrid frameworks may allow developers to create prototypes faster, but in long-term, the project will most likely become more expensive, compared to platform-native apps. If you disagree with me, please, comment below. I'd love to know how you'd profile performance problems with shared element transaction animation between screens (according to material guidelines) using Xamarin or ReactNative.

The hybrid framework is not about the codebase.
It’s about sacrificing tooling advantage in exchange to solving HR problems.

And this is the main issue you should keep in mind when deciding how you want to develop a new app. More flexible team vs. long-term stability and productivity.