Should I use React Native in my project?

Here’s a quick guide that might help you and your team make a decision about whether React Native is a good choice for you:

1. You’re starting a new app from scratch in React Native, where you expect to build almost the whole thing in JavaScript

People who do this are usually pretty happy and get good results. Expo is great for this, and gives you access to a ton of built-in native modules that let you do almost anything an app needs to do without having to use Xcode or Android Studio; makes upgrading to new versions almost painless; and lets you easily push updates to your app code whenever you want, without having to submit a new build to the store. If you need to build one or two screens in native code for one reason or another, and the boundaries of those are well defined, then that usually works well too. If I were starting a new app from scratch, I would use Expo / React Native right now.

2. You’re using React Native for a handful of secondary screens

If you’re thinking of using React Native for a few things like a settings screen, an FAQ, or something like an About page — the kind of things where you would often just stick in a WebView — you’re likely to have good luck. Whole screens for things that don’t need to be intimately connected to the rest of your app in terms of experience, but which you’d rather have look and feel “native” rather than “webby”, usually work out quite well.

3. You have an existing app written in Swift/Java/Obj-C/Kotlin, and you want to start writing parts of it in React Native (and maybe switch over)

This “brownfield” case — where you have an existing, living app written in Swift & Java, and you want to introduce React Native into it in a meaningful across many views and screens — is much harder to navigate. I’m not surprised Airbnb ran into a lot of frustration on this path. Experienced native programmers get frustrated when they have to learn a second, different technology stack. It’s also really annoying and hard to keep track of client-side state if you’re using native views and React Native views on the same screen — typically you keep all your data in JS objects in React Native, and would keep them in Swift/Java data structures on the native side. Because React Native currently has only an asynchronous bridge, it can be very complex, inefficient, and annoying to get things to work together at this depth of integration. Now imagine 10 other similar problems kind of like that (navigation, layout, delegate methods, versioning, etc…). It’s easy to end up in a no-man’s-land where developers using each technology have to deal with the worst of the other one.

3b. Your organization has both an iOS team and an Android team

Even if you’re in one of the first two use cases, organizations where there are people who identify themselves strongly as iOS programmers and Android programmers have a really hard time being happy with React Native. iOS programmers in particular are very unhappy with it and generally regard JS as an infestation of the company’s codebase, while Android programmers have more mixed feelings.

Even if you’re using React Native for things that it’s good at and having success, it can still be hard for large-scale native development and React Native development to coexist in the same organization for non-technical reasons.