Recently, the growing company published a group made up of 5 post series (https://medium.com/airbnb-engineering/react-native-at-airbnb-f95aa460be1c), They announced in the article that they would stop using React Native and remove it from the code base in favor of Swift/Objective-C/Java/Kotlin.

In the past few years, when talking about “Should WE use React Native?” it’s common for people to point out that Airbnb, a world-class company, has done a great job with its products, and they’ve put a lot of effort into React Native and are using it. Now, however, in a major reversal, a top company concerned about product quality invested heavily in React Native and, after very careful research, decided to ditch it. This is a scary thing for anyone who wants to use React Native.

Airbnb, on the other hand, is a significant contributor to the React Native open source community. React-native Maps and Lottie are two very important libraries (both included in the Expo SDK) that were originally developed by Airbnb. Before coming to Google, Leland Richardson was one of the most prominent figures in the community. Their contribution will surely be remembered.

However, if you read through the articles in this series, they spend most of their time saying React Native is pretty good, but not for Airbnb. Personally, this doesn’t really surprise me. Tens of thousands of developers are considering using React Native, and I’ve spoken to many of them, and I’ve found that teams considering Using React Native can fall into three broad categories, two of which are likely to be successful and fun, while others are likely to be a nightmare.

Here’s a quick guide to help you and your team decide if React Native should be used in your project.

1. You build a new app from scratch using React Native and want to develop everything in JavaScript

If this is the case, people are usually happy and can get better results. This is when Expo is perfect for you, you can use a lot of built-in native modules, do everything without having to use Xcode or Android Studio, upgrade to a new version almost effortlessly, and easily push code updates at any time without submitting new versions to the App Store. If for some reason you need to develop a page or two in native code, and you have defined the boundaries of those pages, it’s usually ok to do so. If I were building a new app from scratch, I would use Expo/React Native.

2. You’re developing a small number of secondary pages using React Native

If you’re thinking of using React Native to develop some simple secondary pages like Settings, FAQs, or “About” pages (maybe just embed them in the WebView), you’re in luck. These things don’t need to be tied to the rest of the application in terms of usage experience, but the overall look and feel is more “native.”

3. You have an application developed using Swift/Java/Objective-C/Kotlin, and now you want to develop part of it using React Native

This “brownfield” example — you have an application developed using Swift and Java, and you want to introduce React Native across multiple views or screens — is harder to deal with. I’m not surprised Airbnb has had a lot of setbacks along the way. Experienced native developers can also get frustrated learning a second, completely different technology stack. If you use both the React Native and React Native views on the same screen, on the React Native side you’ll store your data in JS objects, and on the Native side you’ll store your data in Swift/Java data structures, making it difficult to keep track of client state. Because React Native currently has only one asynchronous bridge, integrating at this level can be complex and inefficient. Now imagine 10 other similar problems (navigation, layout, delegate methods, version control, and so on). If the developers of one technology are always dealing with the worst of the other, they are bound to end up on a path of no return.

4. You have an iOS team and an Android team

Even if you’re in one of the first two situations, it’s hard for companies that think they have the best iOS and Android programmers to be happy with React Native. IOS programmers are particularly unhappy with this, as they tend to see JS as polluting their company’s code base, while Android programmers are less upset.

Even if you use React Native for what it does best, it’s still difficult to get React Native and React Native development to co-exist on a large scale in the enterprise due to non-technical issues.

As for its value, I agree with almost all of the criticisms of React Native outlined in Airbnb’s blog post. We can find many of the same things in Expo. And my own list of frustrations is much longer than that. In many ways, though, the technology works very well and will get better. For example, there is a common belief that a good look and feel for navigation is to use native navigation, but now Brent from the Expo team has done a lot of work on the React-Navigation library, and it works well and looks good. It has become the best choice for navigating most React Native apps.

I’m optimistic about the project because some of the most passionate people at Facebook (Hector, Sophie, and Ram in particular) are refactoring React Native and have a lot of smart plans that address some of the most important issues.

I think React Native is in a good place, One of the reasons is the usage of the React in the new versions of Microsoft Office Native (https://twitter.com/TheLarkInn/status/1006746626617008128).

From a macro perspective, developing mobile applications using scripting languages like JavaScript is almost inevitable because developing UI in languages like Swift/Objective-C/Java/Kotlin is inefficient. In addition, every application is developed twice (or three times if you count the Web), which is just too much trouble. The React Native, the Flutter, and other fledgling new products do much the same. Personally, my guess on the winner’s chances is as follows: React Native 55%, Flutter 15%, and the rest 30% we haven’t seen yet.

https://blog.expo.io/should-we-use-react-native-1465d8b607ac