The temptation of React Native

Developing a mobile application has become very complex. The tools are legion and the native environments are more and more evolved. In this context, React Native seems to be an elegant solution.

React Native’s logo

What are all these React* things?

React Native is a Facebook technology that allows you to create native mobile applications on Android and iOS from the same code. It should not be confused with React that is used to create client side web apps, or even ReactiveX, a set of tools for processing data flows.

Name Author Also known as Language/ecosystem Goals
React Facebook ReactJS JavaScript Create client side web applications
React Native Facebook JavaScript Create cross-platform mobile applications
ReactiveX Netflix/Microsoft RX, Reactive programming Multiple (JavaScript, Java, Python…) A set of tools to process data flows

React Native is a technology inspired by React. It’s synthax is only similar to the one of its web cousin. There are numerous things that are different between these two:

  • Context, you can’t, shouldn’t and (trust me) don’t want to develop the same way on the web and on mobile
  • Development environment (debugging tools)
  • Technical environment (database, navigation, security…)

React is a web technology while React Native is a mobile technology. Keep this in mind while picking libraries or you’ll get into many troubles. Unlike solutions like Cordova, this is not about abusing webviews to display UI. It’s the native components of each platform that are used to render UI.

Conceptual problems

Cross mobile platform technologies (React Native, weex, Cordova, Xamarin…), however good they may be, are not ready to replace native technologies. Today, the only delay between the release of a new feature of a target OS and its re-implementation in a cross platform framework can justify a disqualification. It should also be noted that being multi-platform forces you to make a choice: re-implement certain features specific to a single platform by explicitly detecting it or pay the price of a less good integration on the system in question. It is also necessary to be careful and systematically test on all platforms with each new feature at the risk of unpleasant surprises: a very repetitive operation.

I have already heard several times an argument in favor of cross-platform: it seems to emerge a model of applications that would be more conducive to this type of implementation. Simple, ephemeral, without any particular need for security… A POC in a hackathon actually.

Another argument in favor of such tools is that you can implement the bidges yourself if they are missing. But, what would be the point of these tools in this situation? It will be necessary to learn the native framework at the slightest difficulty.

However, these conceptual problems are limited and sometimes non-blocking. They are not always obstacles.

Problems specific to React Native

In the case of React Native, sluggish in development phases, badly integrated debugging tools, heavy JavaScript ecosystem and a significant delay before re-implementing new features mean that the time initially saved is lost, all for a worse result.

React Native’s stacktrace

Personally, I also find that the choice of JavaScript causes many difficulties in the development phase, mainly because of the lack of typing. I am not convinced by flow either, which only adds a layer of complexity and imposes nothing. Why not in a personal project, but good luck to do something with this in a team, and if you try to use this in a professional context, you’ll face a wall.

Also, React-Native needs to run a whole server per app, which ultimately leads to worse performances than native.

Note that, some libraries are very unstable. Just look at this score of 68% as of 2018 on NPMS, a JS tool that allow to check dependencies' quality. It’s just unusable in a professional context.

As an Android developer, I also note that the “wrapper” app that reads JavaScript requires android.hardware.faketouch permission which can lead to quite serious security issues.

Specific to the technology used, these problems stem just from a lack of maturity of the ecosystem.

Advanced React Native

Let us not forget that despite its defects, React Native remains a technology that has brought many innovations in the field of cross platform. This is the first time we have had the opportunity to make native applications with a common code base in this way. Using syntax and concepts from another already more established environment makes it easier to learn the technology, even if there are subtleties. Finally, the concept of components, which has already proven itself, makes it possible to build a readable and efficient architecture.


In the end, there are still some blocking elements before having a correct working environment with this kind of technology. They would surely have a future if there were more mobile environments, but today there are only two that are significant enough for enterprises (Android and iOS). So it is the cross platform frameworks that adapt to the native, whereas it would have to be the opposite for a convincing result.

Let’s take a step back on cross-platform technologies. A few years ago, Cordova was using a unique code base. Now we are using React Native that requires to build on each architecture and is designed to handle platform specificities. Now, Kotlin native seems to be the new thing, at least from an Android developer point of view. This technology is once again reducing the quantity of code that will be used on both platforms. Let’s face it: the more code we share between unprepared platforms, the more problems we face.

So should we resist the temptation of the cross platform? With the current ecosystem, yes, in the vast majority of cases. But there are still small use cases on the margins. Anyway, be aware of the limitations of these technologies before starting a project with them.