All Articles

React Native - pros and cons


Here are some notes about React Native after using it one year in production in 2017/2018. I’m not in favour of a hybrid or native solution. I have a web background but also some native iOS experience and I will try to be honest on the current situation. Hybrid or native? There is no direct answer, it depends on the app you want to build.

There is a lot to say about React Native (RN). We all know the best advantage which is one code for two platforms and it’s true in 90% of the time and sometimes even more.

You can also share API calls with the web, RN components cycles are similar to react components, CSS can be use in camel case, but for the rest, web and mobile are really different. Don’t expect a senior web developer to become a senior RN developer within a month or two, this is not going to happen. The learning curve is exponential at the beginning but it quickly become hard and the curve becomes almost flat. For e.g, environment variables are not supported out of the box, you will have to use react native config library and only the setup can be a challenge for a web developer.

Adding a library to you RN project is something critical and should not be a 10 seconds decision just because it meet your today’s needs. Let’s take our previous example and let’s decide to go with react native dotenv instead of react native config because it’s easier. All things could go well for a while but maybe one day you will have to access a config variables in native code and won’t be able to do so because it’s not possible with dotenv library. To sump up, keep in mind that every time you add a external library, you add complexity to your app and you should do that wisely with long term vision.

You should also be aware that RN API is evolving quickly and you might end up rewrite some small part of your app every time you want to update npm RN package. Another problem with that is external libraries : they might cause you some troubles when updating RN and be prepared to put your hands in pods and gradle… and believe me, this is not fun!



Problem here, there is no “official” navigation out of the box. There is a popular library used called react navigation and it’s a JS-based solution. This is the best solution at the moment but be careful with it because it’s changing quickly and the API is often breaking things.

A native alternative for better performance could be react native navigation made by Wix.

Ecosystem and community

This is a clear advantage for RN in comparison to Native Script or Flutter. The only competitor in hybrid world is Ionic but if you read this, there is a big of chance that you are looking for a solution with native components and not a webview for better performance.



They are great, and can be very similar to native performances. But getting great performances can be tricky and debugging performance leak is less easy than native. First because your code can decrease performance but also because RN and external libraries can also decrease performance on top of that.

More technical info here.


This can be a reason to not do an app in RN, or at least 100% in RN. If you can find a library doing what you want and well maintained by the RN community, that’s nice. Otherwise you will have to build and maintained the library on your own… Good luck with that! Licence

This was a big concern but now it’s no longer the case and RN is under MIT license, like most open-source project in Github.


If your goal is to build a MVP as quickly as possible or if you want a simple solution and don’t want your hands to get dirty, go for it. Except that, don’t use it, or you will have problem with external libraries.

More info

Should I choose React Native for my next app?


Yes, if you are a small-medium company or a startup, especially if you have react developer in your team.

Yes and no if you are a large company. You have the ressources to go native and you never know what will happen to Facebook. But my advice is that you could use RN in some screens of your app, for e.g for api calls in order to re-use web code and save some development time.