Airbnb Switching Away From React Native
The primary benefit of React Native is the fact that code you write runs natively on Android and iOS. Most features that used React Native were able to achieve 95–100% shared code and 0.2% of files were platform-specific (*.android.js/*.ios.js).
[…]
We opted to rewrite components instead of wrapping native ones because it was more reliable to make platform-appropriate APIs individually for each platform and reduced the maintenance overhead for Android and iOS engineers who may not know how to properly test changes in React Native. However, it did cause fragmentation between the platforms in which native and React Native versions of the same component would get out of sync.
[…]
Before React Native can render for the first time, you must initialize its runtime. Unfortunately, this takes several seconds for an app of our size, even on a high-end device.
A common misconception is that React Native allows you to move away from writing native code entirely. However, that is not the current state of the world. The native foundation of React Native still rears its head at times. For example, text is rendered slightly differently on each platform, keyboards are handled differently, and Activities are recreated on rotation by default on Android. A high-quality React Native experience requires a careful balance of both worlds. This, paired with the difficulty of having balanced expertise on all three platforms makes shipping a consistently high-quality experience difficult.
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.
Even though we’re not using React Native, we still see the value in writing product code once. We still heavily rely on our universal design language system (DLS) and many screens look nearly identical on Android and iOS.
Several teams have experimented with and started to unify around powerful server-driven rendering frameworks. With these frameworks, the server sends data to the device describing the components to render, the screen configuration, and the actions that can occur. Each mobile platform then interprets this data and renders native screens or even entire flows using DLS components.
I’m seeing a lot of hemming, hawing, and gnashing of teeth over AirBnB’s announcement that they are sunsetting React Native. They are unrolling a pretty massive investment. Obviously this is a setback for React Native ecosystem.
Update (2018-06-25): Ash Furrow (tweet):
So when people frame Airbnb’s decision as a failure of React Native, I wonder about how much they really understand about what React Native is for. If you have an expectation that a technology can do something that it’s not designed for, and then you’re disappointed when it fails to deliver, it’s not really the technology’s fault, is it? And further, if “only a small percentage” of your app even uses that technology, then you don’t get as much of the benefits.
I’m trying not to frame this as an Artsy-vs-Airbnb discussion, but it’s hard to avoid the comparison because Artsy has had such overwhelming success with our React Native stack. I think a big part of that comes from how we structured our React Native code: all the JavaScript is in its own repository and it gets shipped as a CocoaPod.
Update (2018-07-05): Nate Ebel (via Ben Sandofsky, Hacker News):
The mobile team here at Udacity recently removed the last features in our apps that were written with React Native.
