We announced our React Native Open Source roadmap in Q4 2018 after deciding to invest more in the React Native open source community.

For our first milestone, we focused on identifying and improving the most visible aspects of our community. Our goals were to reduce outstanding pull requests, reduce the project's surface area, identify leading user problems, and establish guidelines for community management.

In the past two months, we made more progress than we expected. Read on for more details:

Pull Requests​

In order to build a healthy community, we must respond quickly to code contributions. In past years, we de-prioritized reviewing community contributions and accumulated 280 pull requests (December 2018). In the first milestone, we reduced the number of open pull requests to ~65. Simultaneously, the average number of pull requests opened per day increased from 3.5 to 7 which means we have handled about 600 pull requests in the last three months.

We merged almost two-thirds and closed one-third of the pull requests. They were closed without being merged if they are obsolete or low quality, or if they unnecessarily increase the project's surface area. Most of the merged pull requests fixed bugs, improved cross-platform parity, or introduced new features. Notable contributions include improving type safety and the ongoing work to support AndroidX.

At Facebook, we run React Native from master, so we test all changes first before they make it into a React Native Release. Out of all the merged pull requests, only six caused issues: four only affected internal development and two were caught in the release candidate state.

One of the more visible community contributions was the updated “RedBox” screen. It's a good example of how the community is making the developer experience friendlier.

Lean Core​

React Native currently has a very wide surface area with many unmaintained abstractions that we do not use a lot at Facebook. We are working on reducing the surface area in order to make React Native smaller and allow the community to take better care of abstractions that are mostly unused at Facebook.

In the first milestone, we asked the community for help on the Lean Core project. The response was overwhelming and we could barely keep up with all the progress. Check out all the work completed in less than a month!

What we are most excited about is that maintainers have jumped in fixing long standing issues, adding tests, and supporting long requested features. These modules are getting more support than they ever did within React Native, showing that this is a great step for the community. Examples of such projects are WebView that has received many pull requests since their extraction and the CLI that is now maintained by members of the community and received much needed improvements and fixes.

Leading User Problems​

In December, we asked the community what they disliked about React Native. We aggregated the responses and replied to each and every problem. Fortunately, many of the issues that our community faces are also problems at Facebook. In our next milestone, we plan to address some of the main problems.

One of the highest voted problems was the developer experience of upgrading to newer versions of React Native. Unfortunately, this is not something that we experience ourselves because we run React Native from master. Thankfully, members from the community already stepped up to address this problem:

• Michał Pierzchała from Callstack improved react-native upgrade by using rn-diff-purge under the hood. We also updated the website to remove outdated upgrade instructions.
• We plan on recommending CocoaPods by default for iOS projects which will reduce churn in project files when upgrading React Native. This will make it easier for people to install and link third-party modules which is even more important in the context of Lean Core as we expect projects to link more modules by default.

0.59 Release​

Without the help of the React Native community, especially Mike Grabowski and Lorenzo Sciandra, we would not be able to ship releases. We want to improve the release management process and plan to be more involved from now on:

• We will work with community members to create a blog post for each major release.
• We will show breaking changes directly in the CLI when people upgrade to new versions.
• We will reduce the time it takes to make a release. We are exploring ways to increase automated testing and also creating an improved manual test plan.

Many of these plans will be incorporated in the upcoming React Native 0.59 release. 0.59 will ship with React Hooks, a new 64-bit version of JavaScriptCore for Android, and many performance and functionality improvements. It is currently published as a release candidate and is expected to be stable within the next two weeks.

Next Steps​

For the next two months, we will continue managing pull requests to stay on track while also starting to reduce the number of outstanding GitHub issues. We will continue reducing the surface area of React Native through the Lean Core project. We plan to address 5 of the top community problems. As we finalize the community guidelines, we will turn attention to our website and documentation.

We are very excited to host over ten contributors from our community at Facebook London in March to help drive several of these efforts. We are glad that you are using React Native and hope that you'll see and feel the improvements we are working on in 2019. We'll be back with another update in a few months and will be merging your pull requests in the meantime! ⚛️✌️

Welcome to the 0.59 release of React Native! This is another big release with 644 commits by 88 contributors. Contributions also come in other forms, so thank you for maintaining issues, fostering communities, and teaching people about React Native. This month brings a number of highly anticipated changes, and we hope you enjoy them.

🎣 Hooks are here​

React Hooks are part of this release, which let you reuse stateful logic across components. There is a lot of buzz about hooks, but if you haven't heard, take a look at some of the wonderful resources below:

• Introducing Hooks explains why we’re adding Hooks to React.
• Hooks at a Glance is a fast-paced overview of the built-in Hooks.
• Building Your Own Hooks demonstrates code reuse with custom Hooks.
• Making Sense of React Hooks explores the new possibilities unlocked by Hooks.
• useHooks.com showcases community-maintained Hooks recipes and demos.

Be sure to give this a try in your apps. We hope that you find the reuse as exciting as we do.

📱 Updated JSC means performance gains and 64-bit support on Android​

React Native uses JSC (JavaScriptCore) to power your application. JSC on Android was a few years old, which meant that a lot of modern JavaScript features weren't supported. Even worse, it performed poorly compared iOS's modern JSC. With this release, that all changes.

Thanks to some awesome work by @DanielZlotin, @dulmandakh, @gengjiawen, @kmagiera, and @kudo JSC has caught up with the past few years. This brings with it 64-bit support, modern JavaScript support, and big performance improvements. Kudos for also making this a maintainable process now so that we can take advantage of future WebKit improvements without so much legwork, and thank you Software Mansion and Expo for making this work possible.

💨 Faster app launches with inline requires​

We want to help people have performant React Native apps by default and are working to bring Facebook's optimizations to the community. Applications load resources as needed rather than slowing down launch. This feature is called "inline requires", as it lets Metro identify components to be lazy loaded. Apps with a deep and varied component architecture will see the most improvement.

We need the community to let us know how it works before we turn it on by default. When you upgrade to 0.59, there will be a new metro.config.js file; flip the options to true and give us your feedback! Read more about inline requires in the performance docs to benchmark your app.

🚅 Lean core is underway​

React Native is a large and complex project with a complicated repository. This makes the codebase less approachable to contributors, difficult to test, and bloated as a dev dependency. Lean Core is our effort to address these issues by migrating code to separate libraries for better management. The past few releases have seen the first steps of this, but let's get serious.

You may notice that additional components are now officially deprecated. This is great news, as there are now owners for these features actively maintaining them. Heed the warning messages and migrate to the new libraries for these features, because they will be removed in a future release. Below is a table indicating the component, its status, and where you may migrate your use to.

Over the coming months, there will be many more components following this path to a leaner core. We're looking for help with this — head over to the lean core umbrella to pitch in.

👩🏽‍💻 CLI improvements​

React Native's command line tools are developer's entry point to the ecosystem, but they had long-standing issues and lacked official support. The CLI tools have been moved to a new repository, and a dedicated group of maintainers have already made some exciting improvements.

Logs are formatted much better now. Commands now run nearly instantly — you'll immediately notice a difference:

🚀 Upgrading to 0.59​

We heard your feedback regarding the React Native upgrade process and we are taking steps to improve the experience in future releases. To upgrade to 0.59, we recommend using rn-diff-purge to determine what has changed between your current React Native version and 0.59, then applying those changes manually. Once you've upgraded your project to 0.59, you will be able to use the newly improved react-native upgrade command (based on rn-diff-purge !) to upgrade to 0.60 and beyond as newer releases become available.

🔨 Breaking Changes​

Android support in 0.59 has been cleaned up following Google's latest recommendations, which may result in potential breakage of existing apps. This issue might present as a runtime crash and a message, "You need to use a Theme.AppCompat theme (or descendant) with this activity". We recommend updating your project's AndroidManifest.xml file, making sure that the android:theme value is an AppCompat theme (such as @style/Theme.AppCompat.Light.NoActionBar ).

The react-native-git-upgrade command has been removed in 0.59, in favor of the newly improved react-native upgrade command.

🤗 Thanks​

Lots of new contributors helped with enabling generation of native code from flow types and resolving Xcode warnings - these are a great way to learn how React Native works and contributing to the greater good. Thank you! Look out for similar issues in the future.

While these are the highlights that we noted, there are many others to be excited about. To see all of the updates, take a look at the changelog. 0.59 is a huge release – we can't wait for you to try it out.

We have even more improvements coming throughout the rest of the year. Stay tuned!

Ryan and the whole React Native core team

This week, Eli White gave a talk at F8 2019 about React Native in Facebook's Android and iOS applications. We are excited to share what we've been up to for the past two years and what we're doing next.

Check out the video on Facebook's developer website:

Highlights from the talk:​

• We spent 2017 and 2018 focused on React Native's largest product, Facebook's Marketplace. We collaborated with the Marketplace team to improve quality and add delight to the product. At this point, Marketplace is one of the highest quality products in the Facebook app both on Android and iOS.
• Marketplace's performance was a big challenge as well, especially on mid-end Android devices. We cut startup time by more than 50% over the last year with more improvements on the way! The biggest improvements are being built into React Native and will be coming to the community later this year.
• We have the confidence that we can build the high quality and performant apps that Facebook needs with React Native. This confidence has let us invest in bigger bets, like rethinking the core of React Native.
• Microsoft supports and uses React Native for Windows, enabling people to use their expertise and codebase to render to Microsofts's Universal Windows Platform. Check out Microsoft Build next week to hear them talk about that more.

React Radio Podcast about Open Source​

Eli's talk concludes by talking about our recent open source work. We gave an update on our progress in March and recently Nader Dabit and Gant Laborde invited Christoph for a chat on their podcast, React Native Radio, to chat about React Native in open source.

Highlights from the podcast:​

• We talked about how the React Native team at Facebook thinks about open source and how we are building a sustainable community that scales for a project of React Native's size.
• We are on track to remove multiple modules as part of the Lean Core effort. Many modules like WebView and the React Native CLI have received more than 100 Pull Requests since they were extracted.
• Next, we'll be focusing on overhauling the React Native website and documentation. Stay tuned!

You'll find the episode in your favorite podcasting app soon or you can listen to the recording right here:

Code & Community Health​

In the past six months, a total of 2800 commits were made to React Native by more than 550 contributors. 400 contributors from the community created more than 1,150 Pull Requests, of which 820 Pull Requests were merged.

The average number of Pull Requests per day throughout the past six months has increased from three to about six, even though we split the website, CLI and many modules out of React Native via the Lean Core effort. The average amount of open pull requests is now below 25 and we usually reply with suggestions and reviews within hours or days.

Meaningful Community Contributions​

We’d like to highlight a number of recent contributions which we thought were awesome:

• Accessibility: React Native 0.60 will ship with many improvements to accessibility APIs both on Android and iOS. All of the new features are directly using APIs provided by the underlying platform so they’ll integrate with native assistance technologies both on Android and iOS. We’d like to thank Marc Mulcahy, Alan Kenyon, Estevão Lucas, Sam Mathias Weggersen and Janic Duplessis for their contributions:
  • Additional Accessibility Roles + States and a new Accessibility States API. Added a number of missing accessibility roles for various components and a new API for better web support in the future.
  • AccessibilityInfo.announceForAccessibility. Added support for Android, previously iOS-only.
  • Extended Accessibility Actions Support. Added callbacks to deal with accessibility around user-defined actions.
  • Support for iOS Accessibility flags and support for "reduce motion".
  • Android keyboard accessibility improvements. Added a clickable prop and an onClick callback for invoking actions via keyboard navigation (note: this will soon be renamed to focusable ).
  • Use CALayers to draw text. Fixed an issue that made scaled-up text disappear on iOS.
• New App Screen: The community came up with a design for the new app screen that is implemented in 0.60. This screen is what most people see when they are first using React Native. It now links first time users to the documentation and the look fits with our upcoming website redesign 🌟. Huge thanks to Orta, Adam Shurson, Glauber Castro, Karan Singh, Eli Perkins, Lucas Bento and Eric Lewis for all their work and collaboration!
  • Check out the new app screen on the “ React Native Show“ video series.
• TurboModule Types: The new TurboModules system requires types for all native modules to guarantee type safe operations in native. In just over two weeks, the community sent ~40 Pull Requests to complete this work for flow typed native modules. Aside from the people already mentioned above, we’d like to thank Michał Chudziak, Michał Pierzchała, Wojtek Szafraniec, and Jean Regisser and everyone else who sent one or more Pull Requests.
• Haste: Since 2015 React Native used the “haste” module system that allows importing modules just via a global id instead of a relative path which is convenient but not well supported by many tools. James Ide proposed removing haste, similar to how React removed haste many years ago. He planned all the work through an umbrella task and he sent 18 Pull Requests to make it happen! Check out his Twitter thread to learn more.
• Android Fragments: John Shelley‘s proposal to make React Native work via Android Fragments was merged and will be available in 0.61. Read more about Android Fragments here.

Lean Core​

The primary motivation of Lean Core has been to split modules out of React Native into separate repositories so they can receive better maintenance. In just a six months repositories like WebView, NetInfo, AsyncStorage, the website and the CLI received more than 800 Pull Requests combined. Besides better maintenance, these projects can also be independently released more often than React Native itself.

We have also taken the opportunity to remove obsolete polyfills and legacy components from React Native itself. Polyfills were necessary in the past to support language features like Map and Set in older versions of JavaScriptCore (JSC). Now that React Native ships with a new version, these polyfills were removed.

This work is still in progress and many more things still need to be split out or removed both on the native and JavaScript side but there are early signs that we managed to reverse the trend of increasing the surface area and app size: When looking at the JavaScript bundle for example, about a year ago in version 0.54 the React Native JavaScript bundle size was 530kb and grew to 607kb (+77kb) by version 0.57 in just 6 months. Now we are seeing a bundle size reduction of 28kb down to 579kb on master, a delta of more than 100kb!

As we conclude the first iteration of the Lean Core effort, we will make an effort to be more intentional about new APIs added to React Native and we will continuously evaluate ways to make React Native smaller and faster, as well as finding ways to empower the community to take ownership of various components.

User Feedback​

Six months ago we asked the community “What do you dislike about React Native?” which gave a good overview of problems people are facing. We replied to the post a few months ago and it's time to summarize the progress that was made on top issues:

• Upgrading: The React Native community rallied around with multiple improvements to the upgrading experience: autolinking, a better upgrading command via rn-diff-purge, an upgrade helper website (coming soon). We’ll also make sure to communicate breaking changes and exciting new features by publishing blog posts for each major release. Many of these improvements will make future upgrades beyond the 0.60 release significantly easier.
• Support / Uncertainty: Many people were frustrated with the lack of activity on Pull Requests and general uncertainty about Facebook's investment in React Native. As we've shown above, we can confidently say that we are ready for many more Pull Requests and we are eagerly looking forward to your proposals and contributions!
• Performance: React Native 0.59 shipped with a new and much faster version of JavaScriptCore (JSC). Separately, we have been working on making it easier to enable inline-requires by default and we have more exciting updates for you in the next couple of months.
• Documentation: We recently started an effort to overhaul and rewrite all of React Native's documentation. If you are looking to contribute, we’d love to get your help!
• Warnings in Xcode: We got rid of all the existing warnings and are making an effort not to introduce new warnings.
• Hot Reloading: The React team is building a new hot reloading system that will soon be integrated into React Native.

Unfortunately we weren’t able to improve everything just yet:

• Debugging: We fixed many inconvenient bugs and issues people that we have been running into every day, but unfortunately we haven't made as much progress on this as we would like. We recognize that debugging with React Native isn't great and we'll prioritize improving this in the future.
• Metro symlinks: Unfortunately we haven't been able to implement a simple and straightforward solution for this yet. However, React Native users shared various workarounds that may work for you.

Given the large amount of changes in the past six months, we'd like to ask you the same question again. If you are using the latest version of React Native and you have things you'd like to give feedback on, please comment on our new edition of “What do you dislike about React Native?”

Continuous Integration​

Facebook merges all Pull Requests and internal changes directly into Facebook’s repository first and then syncs all commits back to GitHub. Facebook’s infrastructure is different from common continuous integration services and not all open source tests were run inside of Facebook. This means that commits that sync out to GitHub frequently break tests in open source which take a lot of time to fix.

Héctor Ramos from the React Native team spent the past two months improving React Native's continuous integration systems both at Facebook and on GitHub. Most of the open source tests are now run before changes are committed to React Native at Facebook which will keep CI stable on GitHub when commits are being synchronized.

Next​

Make sure to check out our talks about the future of React Native! In the next couple of months, members of the React Native team at Facebook will speak at Chain React and at React Native EU. Also, watch out for our next release, 0.60, which is right around the corner. It's going to be exciting ✨

After months of hard work from hundreds of contributors, the React Native Core team is proud to announce the release of version 0.60. This release handles significant migrations for both Android and iOS platforms, and many issues are resolved too. This blog post covers the highlights of the release. As always though, refer to the changelog for more detailed information. Finally, thank you contributors for helping us to make this milestone!

Focus on Accessibility​

There have been many improvements to the accessibility APIs, like announceForAccessibility, plus improvements to roles, action support, flags, and more. Accessibility is a complex science, but we hope these improvements make it a bit easier to be an A11Y. Be sure to check React Native Open Source Update June 2019 for more details of these changes.

A Fresh Start​

React Native's start screen has been updated! Thank you to the many contributors who helped create the new UI. This new "Hello World" will welcome users to the ecosystem in a more friendly, engaging way.

AndroidX Support​

AndroidX is a major step forward in the Android ecosystem, and the old support library artifacts are being deprecated. For 0.60, React Native has been migrated over to AndroidX. This is a breaking change, and your native code and dependencies will need to be migrated as well.

With this change, React Native apps will need to begin using AndroidX themselves. They cannot be used side-by-side in one app, so all of the app code and dependency code needs to be using one or the other.

matt-oakes on discussions-and-proposals

While your own native code will need to be migrated by you, @mikehardy, @cawfree, and @m4tt72 built a clever tool named "jetifier" to patch your node_modules . Library maintainers will need to upgrade, but this tool provide you with a temporary solution while giving them time to release an AndroidX version. So if you find errors related to AndroidX migration, give this a shot.

CocoaPods by Default​

CocoaPods are now part of React Native's iOS project. If you weren't already, be sure to open iOS platform code using the xcworkspace file from now on (protip: try xed ios from the root project directory). Also, the podspec s for the internal packages have changed to make them compatible with the Xcode projects, which will help with troubleshooting and debugging. Expect to make some straightforward changes to your Podfile as part of the upgrade to 0.60 to bring this exciting support. Note that we are aware of a compatibility issue with use_frameworks! , and we're tracking an issue with workarounds and a future patch.

Lean Core Removals​

WebView and NetInfo were previously extracted into separate repositories, and in 0.60 we’ve finished migrating them out of the React Native repository. Additionally, in response to community feedback about new App Store policy, Geolocation has been extracted. If you haven’t already, complete your migration by adding dependencies to react-native-webview, @react-native-community/netinfo, and @react-native-community/geolocation. If you'd like an automated solution, consider using rn-upgrade-deprecated-modules. Maintainers have made more than 100 commits to these repositories since extraction and we’re excited to see the community’s support!

Native Modules are now Autolinked​

The team working on the React Native CLI has introduced major improvements to native module linking called autolinking! Most scenarios will not require the use of react-native link anymore. At the same time, the team overhauled the linking process in general. Be sure to react-native unlink any preexisting dependencies as mentioned in the docs above.

Upgrade Helper​

@lucasbento, @pvinis, @kelset, and @watadarkstar have built a great tool called Upgrade Helper to make the upgrade process simpler. It helps React Native users with brownfield apps or complex customizations to see what's changed between versions. Take a look at the updated upgrading docs and try it out today for your upgrade path!

A Note to Library Maintainers​

Changes for AndroidX will almost certainly require updates to your library, so be sure to include support soon. If you're not able to upgrade yet, consider checking your library against the jetifier to confirm that users are able to patch your library at build time.

Review the autolinking docs to update your configs and readme. Depending on how your library was previously integrated, you may also need to make some additional changes. Check the dependencies guide from the CLI for information on how to define your dependency interface.

Thanks​

While these are the highlights that we noted, there are many others to be excited about. To see all the updates, take a look at the changelog. As always, stay tuned for more news. Enjoy 0.60 in the meantime!