By now, most iOS developers have probably heard the news that Airbnb is moving away from React Native. It’s kind of weird to see the reaction online – people are acting jubilant, almost celebrating the announcement. I see some iOS developers on twitter practically rolling their eyes at Airbnb for even trying React Native. But I’m not here to talk about insularity of the iOS developer community, I’m here to talk about Airbnb’s (quite excellent) blog posts.

These blog posts are excellent because Airbnb first lays out its expectations for React Native, and then explains how well the technology met (or failed to meet) those expectations. It’s a thorough, honest discussion about how large teams evaluate technologies, as well as how those team live with the consequences of their decisions.

So I really like these posts, but I wouldn’t say that they’re complete. More on that later. First, I want to discuss Airbnb’s actual expectations. I’m going to summarize them here, but you really, really should read the posts yourself.

Here are Airbnb’s goals for React Native, which I’m interpreting as their expectations for the technology:

1. Allow us to move faster as an organization.
2. Maintain the quality bar set by native.
3. Write product code once for mobile instead of twice.
4. Improve upon the developer experience.

Okay, so how did those four things go? Well, I’ll summarize again:

(*Note: my characterization of #3 as a failure has been disputed; you should go read Leland Richardson’s thread responding to me to get a really great, nuanced clarification of Airbnb’s experience sharing code between Android and iOS.)

Okay so at first glance, this seems kind of promising, right? I mean, Airbnb says that “60% [of engineers] would describe their experience as amazing”, so a majority of your team is on board. But 5% were “strongly negative”? Interesting. Very interesting. We’ll get back to this shortly, first let’s talk about that third expectation.

The big point everyone is talking about is number three: Airbnb expected to be able to reuse code across Android and iOS but were let down. They wanted that “write once, run everywhere” experience. And that’s the problem that I have with these posts and how they’re being discussed.

React Native is explicitly not “write once, run everywhere”, although this is a common misconception. The idea that you can write one app and deploy to Android and iOS is attractive, and solutions like Expo do exist to do that, but cross-platform code reuse is not the central selling point of React Native. React Native is a “learn once, write everywhere” platform; instead of building one app for multiple platforms, the main selling point of React Native is that it lets you use React.

And that’s it.

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. The native app just imports that pod and instantiates view controllers from it as if they were normal view controllers (because they are, their views just happen to be React Native components). Our native codebase was using React Native for a year before I even wrote any JavaScript, which minimized the overhead for me, a person who was pretty unhappy that JavaScript was in Artsy’s app at all.

And that kind of leads me back to culture. I think these blog posts do an excellent job of describing the technical parts of their experience, but they lack a detailed description of non-technical barriers to adopting React Native.

What kind of barriers? Well, not to bring up the insularity of the iOS developer community again, but… iOS developers kind of have a reputation within the broader software industry. Charlie Cheever, writing about this topic from Expo’s perspective, has this to say:

(Emphasis added.)

When I see a majority of a team describe their experience as “amazing”, and a very small (but very vocal, I’m sure) minority of the team describe it as “strongly negative”, it really makes me wonder about the internal discussions about React Native at Airbnb.

And I get it, I really do. I thought JavaScript was an infestation, too. It took a long time for me to get over it. I mean, if you’ve been hired to write Swift/Objective-C and all of a sudden your team asks you to use JavaScript instead, it’s natural to feel frustrated, or even angry. But you know what else? Engineers don’t just write code, they solve problems. Of course engineers are going to have feelings about the tools their team use, and I think a future blog post should cover how Artsy worked to mitigate the cultural tensions between native iOS developers and our React Native choice. But I wish we’d keep our feelings in check a little bit more.

Airbnb’s experience has been compared, appropriately, to a rejected organ transplant. If your company’s culture is really, really into iOS native development, then the organ will be rejected.

The reasons that Airbnb chose to move away from React Native are cultural as much as they are technical, and while I understand why they didn’t publicize these tensions, it gives the impression that Airbnb’s decision was based entirely in technical merit. And that’s just not the case.