Experiences And Thoughts On React Native

React Native at Airbnb

I don’t have much experience with cross-platform tools in general, but in 2016 I took a job with a React Native shop. I had never worked with React or React Native before, but I had dipped my toe into ReactiveCocoa and was starting to wrap my mind around the reactive coding paradigm. The company explained to me that React Native is a cross platform layer that relies on a solid bridging code, explained to me like an API between the iOS SDK and their RN codebase. They needed someone to own the iOS layer, and I was enjoying API design at the time and looking for a change, I said yes.

The team had no iOS experience, outside of what the very talented JS engineers had pieced together enough to ship an iOS app, and the native bridging layer was suffering for it. Startup times were very slow, memory usage was excessive, transitions and animations were very janky, and much of the code that was living in the React Native layer was better suited for the native layer but the engineers had played to their strengths and written it in JS instead. I was excited. I had a lot of work to do and could make a big impact. I started outlining the work that would need to be done, teaching the mobile team about the unique aspects of the iOS SDK.

After a month I started learning, with the help of a great mentor who was very active in the React Native community, the front end layer, to support my work on the Native layer. I rebuilt an app of mine in React Native. It took about a week to get a quick and dirty UI/UX implementation. Animations weren’t quite as smooth, and it was pretty awful doing my layouts in JSX, but I got past the learning curve and felt ready to really dive in on the iOS side. But our team got excited about having three engineers who knew RN, and started moving fast on the UI layer. Pretty soon all my work was in React Native.

I was building new screens, new components, new transitions. I wouldn’t touch Objective-C or Swift, outside of a small bug fix here or there, for weeks. I spoke to the mobile lead about my list of work that would need to be done on the iOS side to get our app rolling smoothly. I was told we’d get to it when we have more engineers to handle the RN work, probably in a year or two. For a time they switched me from working on a 80% RN app to a 95% RN app. I brought up my desire to return to the iOS side once more, and outlined exactly what changes I was proposing, what priority order it would take, what the impact would be on the Android ‘team’ of one, and how it would benefit our app and create a solid foundation to grow on. I was again told, a week later once the lead had actually read my proposal, that we’d likely get around to it in a couple years. I quit after 9 months.

Reading Gabriel of the Airbnb team’s Medium posts brought a lot of this back to me, and it was very validating to see a large team that had bet big on React Native and certainly included many, many engineers who are much smarter than I am, come to the same conclusions I had soon after starting work in RN. Plenty of people find a way to work in React Native efficiently and effectively, so why was it so hard for me?

For one, it seems like the period where I was deepest in RN, mid 2017, was a particularly rough time for the toolset. I remember spending far too much time and energy trying to get the upgrade to take, bouncing back and forth between npm versions, react-native versions, various versions of our large set of dependencies, just trying to get things to build so I could get back to struggling with whatever component view I was working on at the time.

Then there were the dependencies. I was in the foundational stages of my “All third party code is evil” mentality and every problem in a JS based toolset is solved with a dozen dependencies, each of which have a dozen dependencies on their own, and it’s turtles all the way down. That just seems to be a function of the JS community and a lot of the reason why JavaScript libraries make the web so slow and awful to use today.

Xcode has its problems, but when I need to work on an iOS app it’s the only app I need open. When I started React Native work I was, for the first time since college, writing my code in a text editor. I know thousands of developers do this and have convinced themselves that this is fine. They’re wrong, and my time working on server side Swift, where you can build and run a server stack right from the editor complete with breakpoints, a debug area, and a console, all in the same window of the same app, has convinced me of that. With React Native I was working with Sublime and the Chrome Debugging Tools (I use Firefox as my secondary browser, I will go to any lengths not to have Chrome installed on my Mac). Eventually I discovered other debugger tools I could connect to, that only occasionally required fiddling with preferences and overrides to make work correctly. Eventually I was able to move to fiddling with my preferences to work in VSCode instead of Sublime, and gasp it included breakpoints that worked most of the time. What an amazing development in the toolset, that only required that I move my development environment into what was essentially a web browser. I still wasn’t pleased.

Then, in the midst of this professional angst, came WWDC ‘17, an undeniably exciting time in any Apple Platform Developer’s year. As with every year, I was quick to install betas, get the new Xcode, and start plugging away with the new SDKs and fixing any low hanging fruit that needs to be taken care of in my apps. Except now I wasn’t limited only by the reliability of the betas, but also that fact that React Native itself needed to be patched so it could even build function correctly against the iOS 11 SDKs. Talking to my team to figure out how long this would take only got me confused looks. “Whenever it’s ready,” with no worry about the distinct possibility that Facebook’s bottleneck wouldn’t leave us enough time to actually properly support iOS 11 by the time it came out. So instead of actually getting to work on iOS 11 support I was identifying and reporting bugs in the RN layer. This is when I started working on personal apps on work time, justifying it to myself that otherwise I would fall behind on iOS.

The final straw for me was the dismissive attitude with which most people in the team treated my various concerns about us leaning too hard on React Native, one of only two issues with the job I blame on the people rather than the toolset. I was constantly told that React Native was a better way to work with designers (it wasn’t, designers had to use unintuitive JSX), that it was a faster way to iterate (we spent more time tweaking with tools than we saved in build times), that web-style deploys made for faster releases (they bypassed useful security and reliability checks, and left users with unexpected ‘updates’ when they just wanted to check the app, not to mention we were constantly worried that Apple would rightfully decide to no longer allow it), and finally that focusing my professional development solely on Apple Platforms was a professional liability. A common metaphor was that a Formula 1 racing team wanted a driver who could drive a Toyota Camry just as well as a F1 car. That I would be a better developer if I stopped caring about the iOS best practices I was pushing and instead went all-in on cross platform Javascript tools and whatever the community decides is the hot shit this month. Now that UIKit is coming to macOS and I’m planning ways I can port my personal and work iOS apps onto this new platform, which will have none of the JS baggage that comes with web development, and as I watch many web based companies, including my previous (and current) employers struggle with GDPR compliance because their toolset encouraged them to throw ideas like user privacy to the wind in favor of invasive JS monitoring for abstract ‘benefits’ that often have nothing to do with the core business of the company, I couldn’t be happier that I ignored this advice and removed myself from that situation.

I’m grateful for the experiences I had on this team. It really was a group of amazingly smart people working on interesting problems, who I got along with well and loved spending my days at work with. Also, it gave me the insights I have now to be informed while I watch the React-Native community develop (and dwindle). I firmly believe that there are teams for whom React Native was a great solution. These were teams who, between the years of 2016 and 2018, were made up of web developers who loved JavaScript and open source communities, who had small mobile engineering departments with little to no iOS or Android experience, who wanted to focus on cost-efficiency, needed to move very quickly to release an iOS and Android app, and were fine sacrificing the native experience to come to these solutions. For those who found themselves in this situation, I completely understand the appeal of React Native. If any of those things are not true of you or your team, I would encourage you to focus on native development. It’s just better and more rewarding in the long term.

But now here we are, where one of the highest profile users and contributors to the React Native project outside of the creators, are leaving it behind. This is a serious blow to the future of the platform. No doubt many engineers will continue to use React Native, to build great components and open source tools that the entire community will adopt and contribute to, but the effects of Airbnb’s abandonment will be felt for a long time. I believe this puts an expiration date on the lifetime of the toolset, and that two years from now React Native will be borderline unusable, especially if as it seems they perform a major re-architecting of the platform.

Finally, if you are a team looking for React-Native engineers, please, for the love of all that is decent in engineering principals, don’t put out a requisition for iOS native engineers who are looking to make great iOS apps. There are plenty of web developers who would love to do this work and won’t find themselves terribly depressed coming into the office everyday.