It's been one year since we open-sourced React Native. What started as an idea with a handful of engineers is now a framework being used by product teams across Facebook and beyond. Today at F8 we announced that Microsoft is bringing React Native to the Windows ecosystem, giving developers the potential to build React Native on Windows PC, Phone, and Xbox. It will also provide open source tools and services such as a React Native extension for Visual Studio Code and CodePush to help developers create React Native apps on the Windows platform. In addition,Samsung is building React Native for its hybrid platform, which will empower developers to build apps for millions of SmartTVs and mobile and wearable devices. We also released the Facebook SDK for React Native, which makes it easier for developers to incorporate Facebook social features like Login, Sharing, App Analytics, and Graph APIs into their apps. In one year, React Native has changed the way developers build on every major platform.
It's been an epic ride — but we are only getting started. Here is a look back at how React Native has grown and evolved since we open-sourced it a year ago, some challenges we faced along the way, and what we expect as we look ahead to the future.
In the essence of Facebook's hacker culture, React Native started as a hackathon project in the summer of 2013. Similar to React, React Native seemed like a boldly unconventional idea. It wasn't clear this would actually work. How was touch negotiation between JS and native ScrollViews going to work? What about performance, and what about debugging? None of these challenges stopped the engineers from focusing and pushing forward.
Once we had a working prototype, we anticipated that the project had a ton of potential for Facebook. A few years ago we made a major shift to native mobile development. However, recompiling on every code change was slow, and separate sets of skills were needed to build for iOS and Android. All of this meant slower product development. The idea of React Native meant we could bring all the things we loved about developing for the web — such as fast iterations and having a single team build the whole product — to mobile. It meant we could move faster.
As a result, we started investing time and energy into the project — we knew the only way to prove that the new technology really worked was to throw hard problems at it. We chose a News Feed prototype, which was one of the first projects we built with React Native while still developing React Native's infrastructure. That code eventually became the basis for the feed used by the standalone Facebook Groups application.
By July 2014, there were still only a few people working on the project when React Native got its first big job: the Ads Manager team wanted to build a standalone iOS app. However, they didn't have engineers with iOS experience. This was a perfect fit. What followed were a few months of very close collaboration between the Ads Manager product team and the React Native team. The product engineers were constantly pushing the boundaries of the platform. The goal was no smaller than to ship the first fully React Native-powered app where the user experience was identical to an app built in Objective-C.
Once we felt confident this task was possible, we made a decision to make React Native cross-platform and start a React Native Android team in London. The then team of three wrote most of the core Android runtime and first components during the second half of 2014. The goal was to run the iOS Ads Manager code on Android, and by the end of 2014 we had a bare-bones version of the app running. It was missing many views and performance wasn't great on low-end devices, but you could see the list of ads and even create one. We were confident we could make this work so we made a push for performance and feature parity.
Facebook Ads Manager iOS codebase running on Android, January 2015.
The Facebook Ads Manager for iOS shipped in February 2015, less than six months after the team started working on it. Concurrently, everyone whose main focus was on JS or iOS worked on open-sourcing the iOS implementation. In January 2015 at React.js Conf, there was a first public preview, and at our F8 developer conference in March 2015, we opened the code to everyone.
In June 2015, after about three months of development and a month of internal dogfooding, the first version of the Android Ads manager shipped. Given how React Native for iOS took off, we immediately shifted our focus to open-sourcing React Native for Android, and we anticipated strong interest for the Android launch. After all, having to build the same app separately for each platform is a problem in the industry, and we knew from experience with the Ads Manager that React Native could help with it.
Similar to the iOS launch, we wanted to get React Native for Android out as early as possible to get feedback. Therefore, we started with only the core runtime and small number of view and modules (Text, Image, ScrollView, Network, AsyncStorage, and a few others). On September 14, we pushed the core of the Android runtime and an initial set of Android modules to GitHub and npm. And just like that, React Native version 0.11 was the first release with Android support. We've added the following Android modules since we open-sourced it, bringing the API parity close to iOS: Alert, AppState, CameraRoll, Clipboard, Date and time pickers, Geolocation, Intent, Modal, NetInfo, Pull to refresh view, Picker, Slider, View Pager, and WebView.
Needless to say, the adoption that followed outside of Facebook has made all of us on the React Native team extremely excited.
Timeline of the progress since the inception of React Native until open-sourcing React Native for Android.
The adoption of React Native and its developer community have both grown much faster than we had expected.
Over 650 people have committed code to the React Native codebase. Out of the 5,800 commits to the codebase, 30 percent were made by contributors who don't work at Facebook. In February 2016, for the first time, more than 50 percent of the commits came from external contributors. With so many people from the community contributing to React Native, we've seen as many as 266 new pull requests per month (up to 10 pull requests per day). Many of these are high-quality and implement widely used features.
Number of pull requests opened on the React Native GitHub repo each month.
In the beginning, the number of incoming pull requests made it difficult to review them quickly and efficiently. Finding the right reviewers for each pull request meant lots of manual work every day. To solve this, we automated everything that we could by building two GitHub bots.
The first was the mention bot, which finds the right reviewers for each pull request.
The mention bot finds the best reviewers for a pull request based on blame information.
The mention bot, which is now open-sourced, helped streamline how many pull requests we could review each day. An interesting fact is that with over 50 percent of the commits last month contributed by the community, the bot often identifies people in the community as best reviewers.
The second problem we had was that merging pull requests wasn't easy enough. Facebook engineers use the exact same React Native code you see on GitHub; we don't have a fork of the codebase. Therefore, we automatically test apps like the Facebook Ads Manager before merging your pull request to our large Mercurial repo called fbsource.
Simplified structure of our monolithic Mercurial repo called fbsource. The repo contains all our mobile and backend code.
The process of merging a pull request used to involve several manual steps. We simplified all of this to typing a single comment on GitHub.
@facebook-github-bot shipit: If all internal tests pass, the code is merged to fbsource master as well as GitHub master.
Thanks to these tools, the project has been able to keep up with the very large number of incoming pull requests. In total, 2,351 pull requests have been closed in just a year.
The number of open pull requests closed each month.
The popularity of the project has created an environment where there is a lot of potential impact to be had by anyone who wants to help us manage the massive number of issues that are opened.
We have implemented another bot to help anyone manage GitHub issues. It makes it possible for anyone to close issues as duplicates, close them as answered, add labels, and much more. There is also a guide to managing GitHub issues that you can use.
The issues bot lets anyone manage GitHub issues, no push access needed.
React Native Open Source Collaborators are people in the community who contribute very high-quality patches and actively help others. We have created the React Native Community Collaborator title for people who greatly help us move the project forward. With the title comes push access to the repo.
Here is a big shout-out to the React Native community collaborators: Adam Miskiewicz, Alexey Kureev, Brent Vatne, Chirag Jain, Christopher Dro, James Ide, Janic Duplessis, Joshua Sierles, Kyle Corbitt, Krzysztof Magiera, Leland Richardson, Mike Grabowski, and Satyajit Sahoo. Thank you for all your amazing work!
Some of us met at React.js Conf in San Francisco on Feb. 22, 2016:
In the picture (left to right): Christopher Dro (React Native Playground), Brent Vatne (Exponent), Jean-Richard Lai (TaskRabbit), Eric Vlad Vicenti (React Native team), Dave Sibiski (React Native Playground), James Ide (Exponent), Martín Bigio (React Native team), Tadeu Zagallo (React Native team), Christopher Chedeau (React Native team), Ken Wheeler (Formidable), Leland Richardson (Airbnb), and Martin Konicek (React Native Team).