Sunsetting React Native
Due to a variety of technical and organizational issues, we will be sunsetting React Native and putting all of our efforts into making native amazing.
Update
This article was published in 2018 and reflects the state of React Native at the end of 2017. When using these articles to make decisions about your business, please use discretion.
Any technical points should be revalidated because the maturity and size of the ecosystem was significantly different back then.
Any organizational points should also be considered within the context, size, and culture of your organization. This was true in 2018 and is still true today.
If these articles are exclusively cited as a reason not to use React Native, please do more research of your own before making a decision.
This is the fourth in a series of blog posts in which we outline our experience with React Native and what is next for mobile at Airbnb.Where are we today?
Although many teams relied on React Native and had planned on using it for the foreseeable future, we were ultimately unable to meet our original goals. In addition, there were a number of technical and organizational challenges that we were unable to overcome that would have made continuing to invest in React Native a challenge.
As a result, moving forward, we are sunsetting React Native at Airbnb and reinvesting all of our efforts back into native.
Failing to Reach Our Goals
Move Faster
When React Native worked as intended, engineers were able to move at an unparalleled speed. However, the numerous technical and organizational issues that we outlined in this series added frustrations and unexpected delays to many projects.
Maintain the Quality Bar
Recently, as React Native matured and we accumulated more expertise, we were able to accomplish a number of things that we weren’t sure were possible. We built shared element transitions, parallax, and were able to dramatically improve the performance of some screens that used to frequently drop frames. However, some technical challenges such as initialization and the async first render made meeting certain goals challenging. The lack of resources internally and externally made this even more difficult.
Write Code Once Instead of Twice
Even though code in React Native features was almost entirely shared across platforms, only a small percentage of our app was React Native. In addition, large amounts of bridging infrastructure were required to enable product engineers to work effectively. As a result, we wound up supporting code on three platforms instead of two. We saw the potential for code sharing between mobile and web and were able to share a few npm packages but beyond that, it never materialized in a meaningful way.
Improve the Developer Experience
The developer experience with React Native was a mixed bag. In some ways, such as build times, things were dramatically better. However, in others, such as debugging, things were much worse. The details are enumerated in part 2 in this series.
Sunset Plan
Because we weren’t able to achieve our specific goals, we have decided that React Native isn’t right for us anymore. We are currently in the process of working with teams to create a healthy transition plan. We have halted all new React Native features and have plans to transition the majority of the highest-trafficked screens to native by the end of the year. This was aided by some scheduled redesigns that were going to happen regardless. Our native infrastructure team will support React Native through 2018. In 2019, we will begin to ramp down support and reduce some of the React Native overhead such as initializing the runtime on launch.
At Airbnb, we are strong believers in open source. We actively use and contribute to many open source projects around the world and have open sourced some of our React Native work as well. As we have moved away from React Native, we haven’t been able to maintain our React Native repos as well as the community deserves. To do what’s best for the community, we will be migrating some of our React Native open source work to react-native-community which we have already begun to do with react-native-maps and will do with native-navigation and lottie-react-native.
It is not all bad
Although we weren’t able to achieve our goals with React Native, engineers who used React Native generally had a positive experience. Of these engineers:
- 60% would describe their experience as amazing.
- 20% were slightly positive.
- 15% were slightly negative.
- 5% were strongly negative.
63% of engineers would have chosen React Native again given the chance and 74% would consider React Native for a new project. It is worth noting that there is inherent selection bias in these results since it only surveys people who chose to use React Native.
These engineers wrote 80,000 lines of product code across 220 screens as well as 40,000 lines of javascript infrastructure. For reference, we have about 10x the amount of code and 4x the number of screens on each native platform.
React Native is Maturing
This series of posts reflects our experiences with React Native as of today. However, Facebook and the broader React Native community are dedicated to making React Native work for hybrid apps at scale. React Native is progressing faster than ever. There have been over 2500 commits in the last year and Facebook just announced that they are addressing some of the technical challenges we faced head-on. Even if we will no longer be investing in React Native, we’re excited to continue following these developments because technical wins in React native translate to real-world wins for the people around the world who use our products.
Takeaways
We integrated React Native into large existing apps that continued to move at a very fast pace. Many of the difficulties we encountered were due to the hybrid model approach we took. However, our scale allowed us to take on and solve some difficult problems that smaller companies may not have had time to solve. Making React Native work seamlessly with native is possible but challenging. Every company that uses React Native will have an experience that is a unique function of their team composition, existing app, product requirements, and maturity of React Native.
When everything came together, which it did for many features, the iteration speed, quality, and developer experience matched or surpassed all of our goals and expectations. At times, it really felt like we were on the verge of changing the game for mobile development. Even though these experiences were highly encouraging, when we balanced the positives against the pain points plus the current needs and resources of our Engineering organization, we decided that it wasn’t right for us anymore.
Deciding whether to use a new platform is a major decision and depends entirely on factors unique to your team. Our experiences and reasons for moving away may not apply to your team. In fact, many companies are continuing to successfully use it today and it may still be the best choice for many others.
Although we have never stopped investing in native, sunsetting React Native frees up even more resources to make native better than ever. Follow along in the next part of this series to learn what’s new in native for us.
This is part four in a series of blog posts highlighting our experiences with React Native and what’s next for mobile at Airbnb.
