Should we use React Native?

Thoughts from Expo following Airbnb’s Sunsetting of RN.

The big news in the React Native world this week was that Airbnb published a lengthy, five-part blog post announcing and explaining their decision to stop using React Native and remove it from their codebase, in favor of a Swift/Obj-C/Java/Kotlin development that leverages new technology they are building for cross platform server rendering.

For the last few years, any conversation around “Should we be using React Native?” usually included someone pointing out that Airbnb, a world-class company that executes really well on its products, had made a big investment in React Native and was using it. Now, that point has totally flipped on its head: a top-tier company that cares a lot about product quality made a big investment in React Native, looked very closely at it, and then decided to go the other way. That’s scary to anyone thinking about using React Native.

The other thing that is a big deal is that Airbnb had been a big contributor to the React Native open source community. react-native-maps and Lottie are two really important libraries (both included in the Expo SDK!) that were originally developed by Airbnb. Leland Richardson was one of the most prominent figures in the community for a while before he moved on to Google. Those contributions will certainly be missed.

But if you read beyond the headline of the post, the post mostly says that React Native is pretty great but just not a good fit for Airbnb. This isn’t super surprising to me. Watching tens of thousands of developers consider using React Native and talking to many of them, I’ve found that teams considering React Native fall roughly into three broad categories, where two of them are very likely to be successful and happy using React Native, and the other one is usually a bad time.

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.

For what it’s worth, I agree with almost all of the criticisms of React Native listed in the Airbnb blog post. We’ve found a lot of the same things working at Expo. And I keep my own list of frustrations that’s actually a lot longer. But the technology is pretty good in a bunch of ways, and getting better. For example, it was commonly believed that you needed to use native navigation to get a good look and feel for navigation in your apps, but now that Brent on the Expo team has put a ton of work into the react-navigation library, it works really well and feels very, very good. It’s now the best option for navigation in most React Native apps.

I’m also optimistic about the project because of the renewed emphasis that some of the most caring people at Facebook are putting on the open source side of React Native (Hector and Sophie and Ram, especially), and think a lot of the plans they’ve laid out are smart and address some of the most important problems. It’s worth reading Nick Schrock’s Twitter thread where he lines up a bunch of the problems enumerated in the Airbnb blog post with planned efforts that Sophie outlined that should solve a lot of them.

One of the reasons I think React Native is in a good spot is that Microsoft is using it for the new version of Office.

And more broadly, this shift to writing mobile applications in a sane scripting language like JavaScript is pretty much inevitable because it’s too inefficient to write UIs in languages like Swift/Obj-C/Java/Kotlin. Further, it’s totally bonkers to write all of our apps twice (or three times if you want to count web too!). Whether it’s React Native, Flutter, or something new that hasn’t revealed itself on the horizon, it’s going to be something that looks roughly like this. Personally, I’d estimate the chances of the winner in the space as: React Native: 55%, Flutter: 15%, Something else we haven’t seen yet: 30%.

I really like that we get to work on this problem at Expo. It’s fun and interesting and feels important. We’ll keep working on solving these problems using the best solutions around as long as it’s still too hard to build and deliver mobile software.