The Wayback Machine - https://web.archive.org/web/20220127112857/https://archive.reactnative.dev/blog/

0.59

React Native Documentation Update

July 23, 2020

Rachel NaborsDocumentation Engineer at Facebook

Rachel Nabors

Last year we conducted user interviews and sent out a survey to learn more about how and when people use the React Native docs. With the data and guidance gleaned from 24 interviews and over 3000 survey responses, we've been able to work to improve React Native's documentation, and we're excited to share that progress today:

Thank you so much to everyone who participated in the interviews, the survey, and our documentation efforts! Your collaboration makes this possible.

What’s next?

The global COVID-19 pandemic has impacted many community members’ jobs.

We are responding with additional content including:

  • New and improved Native Modules guides
  • Introductory content for people coming in to React Native for the first time

You can help!

There are many ways you can help us write even better docs!

  1. If you see a typo, run into an issue with a guide, or something otherwise isn’t quite right, click that “Edit” button and submit a PR.
  2. Participate in our survey—this helps us understand how you use React Native and its documentation
  3. Write for us! We’re working on a tutorial section as well as guides for topics like offline apps, navigation, accessibility, debugging, animations, internationalization, and performance. If you or someone you admire or know is a perfect fit for any of these, please reach out to me!

React Native Team Principles

July 17, 2020

Eli WhiteEngineering Manager on React Native

Eli White

The React Native team at Facebook is guided by principles that help determine how we prioritize our work on React Native. These principles represent our team specifically and do not necessarily represent every stakeholder in the React Native community. We are sharing these principles here to be more transparent about what drives us, how we make decisions, and how we focus our efforts.

Native Experience

Our top priority for React Native is to match the expectations people have for each platform. This is why React Native renders to platform primitives. We value native look-and-feel over cross-platform consistency.

For example, the TextInput in React Native renders to a UITextField on iOS. This ensures that integration with password managers and keyboard controls work out of the box. By using platform primitives, React Native apps are also able to stay up-to-date with design and behavior changes from new releases of Android and iOS.

In order to match the look-and-feel of native apps, we must also match their performance. This is where we focus our most ambitious efforts. For example, Facebook created Hermes, a new JavaScript Engine built from scratch for React Native on Android. Hermes significantly improves the start time of React Native apps. We are also working on major architectural changes that optimize the threading model and make React Native easier to interoperate with native code.

Massive Scale

Hundreds of screens in the Facebook app are implemented with React Native. The Facebook app is used by billions of people on a huge range of devices. This is why we invest in the most challenging problems at scale.

Deploying React Native in our apps lets us identify problems that we wouldn’t see at a smaller scale. For example, Facebook focuses on improving performance across a broad spectrum of devices from the newest iPhone to many older generations of Android devices. This focus informs our architecture projects such as Hermes, Fabric, and TurboModules.

We have proven that React Native can scale to massive organizations too. When hundreds of developers are working on the same app, gradual adoption is a must. This is why we made sure that React Native can be adopted one screen at a time. Soon, we will be taking this one step further and enable migrating individual native views of an existing native screen to React Native.

A focus on massive scale means there are many things our team isn’t currently working on. For example, our team doesn’t drive the adoption of React Native in the industry. We also do not actively build solutions for problems that we don’t see at scale. We are proud that we have many partners and core contributors that are able to focus on those important areas for the community.

Developer Velocity

Great user experiences are created iteratively. It should only take a few seconds to seeing the result of code changes in a running app. React Native's architecture enables it to provide near-instant feedback during development.

We often hear from teams that adopting React Native significantly improved their development velocity. These teams find that the instant feedback during development makes it much easier to try different ideas and add extra polish when they don’t have to interrupt their coding session for every little change. When we make changes to React Native, we make sure to preserve this quality of the developer experience.

Instant feedback is not the only way that React Native improves developer velocity. Teams can easily leverage the fast-growing ecosystem of high quality open source packages. Teams can also share business logic between Android, iOS, and the web. This helps them ship updates faster and reduce organizational silos between platform teams.

Every Platform

When we introduced React Native in 2014, we presented it with our motto “Learn once, write anywhere” — and we mean anywhere. Developers should be able to reach as many people as possible without being limited by device model or operating system.

React Native targets very different platforms including mobile, desktop, web, TV, VR, game consoles, and more. We want to enable rich experiences on each platform instead of requiring developers to build for the lowest common denominator. To accomplish this, we focus on supporting the unique features of each platform. This ranges from varying input mechanisms (e.g. touch, pen, mouse) to fundamentally different consumption experiences like 3D environments in VR.

This principle informed our decision to implement React Native’s new core architecture in cross-platform C++ to promote parity across platforms. We are also refining the public interface targeted at other platform maintainers like Microsoft with Windows and macOS. We strive to enable any platforms to support React Native.

Declarative UI

We don’t believe in deploying the exact same user interface on every platform, we believe in exposing each platform’s unique capabilities with the same declarative programming model. Our declarative programming model is React.

In our experience, the unidirectional data flow popularized by React makes applications easier to understand. We prefer to express a screen as a composition of declarative components rather than imperatively managed views. React’s success on the web and the direction of the new native Android and iOS frameworks show that the industry has also embraced declarative UI.

React popularized declarative user interfaces. However, there remain many unsolved problems that React is uniquely positioned to solve. React Native will continue to build on top of the innovations of React and remain at the forefront of the declarative user interface movement.

Announcing React Native 0.63 with LogBox

July 6, 2020

Mike GrabowskiCTO and Co-Founder at Callstack

Mike Grabowski

Today we’re releasing React Native 0.63 that ships with LogBox turned on by default.

LogBox

We’ve heard frequent feedback from the community that errors and warnings are difficult to debug in React Native. To address these issues we took a look at the entire error, warning, and log system in React Native and redesigned it from the ground up.

Screenshot of LogBox

LogBox is a completely redesigned redbox, yellowbox, and logging experience in React Native. In 0.62 we introduced LogBox as an opt-in. In this release, we’re launching LogBox as the default experience in all of React Native.

LogBox addresses complaints that errors and warnings were too verbose, poorly formatted, or unactionable by focusing on three primary goals:

  • Concise: Logs should provide the minimum amount of information necessary to debug an issue.
  • Formatted: Logs should be formatted so that you can quickly find the information you need.
  • Actionable: Logs should be actionable, so you can fix the issue and move on.

To achieve these goals, LogBox includes:

  • Log notifications: We’ve redesigned the warning notifications and added support for errors so that all console.warn and console.log messages show up as notifications instead of covering your app.
  • Code Frames: Every error and warning now includes a code frame that shows the source code of the log right inside the app, allowing you to quickly identify the source of your issue.
  • Component Stacks: All component stacks are now stripped from error messages and put into their own section with the top three frames visible. This gives you a single, consistent space to expect stack frame information that doesn’t clutter the log message.
  • Stack Frame Collapsing: By default we now collapse call stack frames not related to your application’s code so you can quickly see the issue in your app and not sift through React Native internals.
  • Syntax Error Formatting: We’ve improved the formatting for syntax errors and added codeframes with syntax highlighting so you can see the source of the error, fix it, and continue coding without React Native getting in your way.

We’ve wrapped all of these features into an improved visual design that’s consistent between errors and warnings and allows paginating through all logs in one enjoyable UI.

With this change we’re also deprecating YellowBox in favor of LogBox APIs:

  • LogBox.ignoreLogs(): This function replaces YellowBox.ignoreLogs([]) as a way to silence any logs that match the given strings or regexes.
  • LogBox.ignoreAllLogs(): This function replaces console.disableYellowBox as a way to turn off error or warning notifications. Note: this only disables notifications, uncaught errors will still open a full screen LogBox.

In 0.63, we will warn when using these deprecated modules or methods. Please update your call sites off of these APIs before they are removed in 0.64.

For more information on LogBox and debugging react native, see the docs here.

Pressable

React Native is built to enable applications to meet user’s expectations of the platform. This includes avoiding “tells”—little things that give away that the experience was built with React Native. One major source of these tells has been the Touchable components: Button, TouchableWithoutFeedback, TouchableHighlight, TouchableOpacity, TouchableNativeFeedback, and TouchableBounce. These components make your application interactive by allowing you to provide visual feedback to user interactions. However, because they include built-in styles and effects that don’t match the platform interaction, users can tell when experiences are written with React Native.

Further, as React Native has grown and our bar for high-quality applications has gone up, these components haven't grown with it. React Native now supports platforms like Web, Desktop, and TV, but support for additional input modalities has been lacking. React Native needs to support high-quality interaction experiences on all platforms.

To address these problems, we are shipping a new core component called Pressable. This component can be used to detect various types of interactions. The API was designed to provide direct access to the current state of interaction without having to maintain state manually in a parent component. It was also designed to enable platforms to extend it's capabilities to include hover, blur, focus, and more. We expect that most people will build and share components utilizing Pressable under the hood instead of relying on the default experience of something like TouchableOpacity.

import { Pressable, Text } from 'react-native';

<Pressable
  onPress={() => {
    console.log('pressed');
  }}
  style={({ pressed }) => ({
    backgroundColor: pressed ? 'lightskyblue' : 'white'
  })}>
  <Text style={styles.text}>Press Me!</Text>
</Pressable>;

A simple example of a Pressable component in action

You can learn more about it from the documentation.

Native Colors (PlatformColor, DynamicColorIOS)

Every native platform has the concept of system-defined colors. Colors that automatically respond to system theme settings such as Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window.

While it is possible to detect some of these settings via the Appearance API and/or AccessibilityInfo and set your styles accordingly, such abstractions are not only costly to develop but are just approximating the appearance of native colors. These inconsistencies are particularly noticeable when working on a hybrid application, where React Native elements co-exist next to the native ones.

React Native now provides an out-of-the-box solution to use these system colors. PlatformColor() is a new API that can be used like any other color in React Native.

For example, on iOS, the system provides a color called labelColor. That can be used in React Native with PlatformColor like this:

import { Text, PlatformColor } from 'react-native';

<Text style={{ color: PlatformColor('labelColor') }}>
  This is a label
</Text>;

Sets the color of the Text component to labelColor as defined by iOS.

Android, on the other hand, provides colors like colorButtonNormal. You can use this color in React Native with:

import { View, Text, PlatformColor } from 'react-native';

<View
  style={{
    backgroundColor: PlatformColor('?attr/colorButtonNormal')
  }}>
  <Text>This is colored like a button!</Text>
</View>;

Sets the background color of the View component to colorButtonNormal as defined by Android.

You can learn more about PlatformColor from the documentation. You can also check the actual code examples present in the RNTester.

DynamicColorIOS is an iOS only API that lets you define which color to use in light and dark mode. Similar to PlatformColor, this can be used anywhere you can use colors. DynamicColorIOS uses iOS’s colorWithDynamicProvider under the hood.

import { Text, DynamicColorIOS } from 'react-native';

const customDynamicTextColor = DynamicColorIOS({
  dark: 'lightskyblue',
  light: 'midnightblue'
});

<Text style={{ color: customDynamicTextColor }}>
  This color changes automatically based on the system theme!
</Text>;

Changes the text color based on the system theme

You can learn more about DynamicColorIOS from the documentation.

Dropping iOS 9 and Node.js 8 support

After over four years from its release, we are dropping support for iOS 9. This change will allow us to move faster by being able to reduce the number of compatibility checks that need to be placed in the native code to detect whether a given feature was supported on a certain iOS version. With its market share of 1%, it shouldn’t have much negative impact on your customers.

At the same time, we are dropping support for Node 8. Its LTS maintenance cycle expired in December 2019. The current LTS is Node 10 and it is now the version that we are targeting. If you are still using Node 8 for the development of React Native applications, we encourage you to upgrade in order to receive all the latest security fixes and updates.

Other notable improvements

  • Support rendering <View /> in <Text /> without explicit size: You can now render any <View /> inside any <Text /> component without setting its width and height explicitly, which wasn’t always possible. On previous releases of React Native, this would result in a RedBox.
  • Changed iOS LaunchScreen from xib to storyboard: Starting April 30, 2020, all apps submitted to the App Store must use an Xcode storyboard to provide the app’s launch screen and all iPhone apps must support all iPhone screens. This commit adjusts the default React Native template to be compatible with this requirement.

Thanks

Thank you to the hundreds of contributors that helped make 0.63 possible!

Special thanks to Rick Hanlon for authoring the section on LogBox and Eli White for authoring the Pressable part of this article.

To see all the updates, take a look at the 0.63 changelog.

Announcing React Native 0.62 with Flipper

March 26, 2020

Rick HanlonReact Native Core at Facebook

Rick Hanlon

Today we’re releasing React Native version 0.62 which includes support for Flipper by default.

This release comes in the midst of a global pandemic. We’re releasing this version today to respect the work of hundreds of contributors who made this release possible and to prevent the release from falling too far behind master. Please be mindful of the reduced capacity of contributors to help with issues and prepare to delay upgrading if necessary.

Flipper by default

Flipper is a developer tool for debugging mobile apps. It’s popular in the Android and iOS communities, and in this release we’ve enabled support by default for new and existing React Native apps.

Screenshot of Flipper for React Native

Flipper provides the following features out of the box:

  • Metro Actions: Reload the app and trigger the Dev Menu right from the toolbar.
  • Crash Reporter: View crash reports from Android and iOS devices.
  • React DevTools: Use the newest version of React DevTools right alongside all your other tools.
  • Network Inspector: View all of the network requests made by device applications.
  • Metro and Device Logs: View, search, and filter all logs from both Metro and the Device.
  • Native Layout Inspector: View and edit the native layout output by the React Native renderer.
  • Database and Preference Inspectors: View and edit the device databases and preferences.

Additionally, since Flipper is an extensible platform, it provides a marketplace that pulls plugins from NPM so you can publish and install custom plugins specific to your workflows. See the available plugins here.

For more information, check out the Flipper documentation.

New dark mode features

We’ve added a new Appearance module to provide access to the user's appearance preferences, such as their preferred color scheme (light or dark).

const colorScheme = Appearance.getColorScheme();
if (colorScheme === 'dark') {
  // Use dark color scheme
}

We’ve also added a hook to subscribe to state updates to the users preferences:

import { Text, useColorScheme } from 'react-native';

const MyComponent = () => {
  const colorScheme = useColorScheme();
  return <Text>useColorScheme(): {colorScheme}</Text>;
};

See the docs for Appearance and useColorScheme for more information.

Moving Apple TV to react-native-tvos

As part of our Lean Core effort and to bring Apple TV in line with other platforms like React Native Windows and React Native macOS, we’ve started to remove Apple TV specific code from core.

Going forward, Apple TV support for React Native will be maintained in react-native-community/react-native-tvos along with the corresponding react-native-tvos NPM package. This is a full fork of the main repository, with only the changes needed to support Apple TV.

Releases of react-native-tvos will be based on the public release of React Native. For this 0.62 release of react-native please upgrade Apple TV projects to use react-native-tvos 0.62.

More upgrade support

When 0.61 was released, the community introduced a new upgrade helper tool to support developers upgrading to new versions of React Native. The upgrade helper provides a diff of changes from the version you're on to the version you're targeting, allowing you to see the changes that need to be made for your specific upgrade.

Even with this tool, issues come up when upgrading. Today we're introducing more dedicated upgrading support by announcing Upgrade-Support. Upgrade Support is a GitHub issue tracker where users can submit issues specific to upgrading their projects to receive help from the community.

We're always working to improve the upgrade experience, and we hope that these tools give users the support they need in the edge cases we haven't covered yet.

Other improvements

  • LogBox: We’re adding the new LogBox error and warning experience as an opt-in; to enable it, add require('react-native').unstable_enableLogBox() to your index.js file.
  • React DevTools v4: This change includes an upgrade to the latest React DevTools which offers significant performance gains, an improved navigation experience, and full support for React Hooks.
  • Accessibility improvements: We’ve made improvements to accessibility including adding accessibilityValue, missing props on Touchables, onSlidingComplete accessibility events, and changing the default role of Switch component from "button" to "switch".

Breaking changes

  • Remove PropTypes: We're removing propTypes from core components in order to reduce the app size impact of React Native core and to favor static type systems which check at compile time instead of runtime.
  • Remove accessibilityStates: We’ve removed the deprecated accessibilityStates property in favor of the new accessibilityState prop which is a more semantically rich way for components to describe information about their state to accessibility services.
  • TextInput changes: We removed onTextInput from TextInput as it’s uncommon, not W3C compliant, and difficult to implement in Fabric. We also removed the undocumented inputView prop, and selectionState.

Deprecations

  • AccessibilityInfo.fetch was already deprecated, but in this release we added a warning.
  • Setting useNativeDriver is now required to support switching the default in the future.
  • The ref of an Animated component is now the internal component and deprecated getNode.

Thanks

Thank you to the hundreds of contributors that helped make 0.62 possible!

To see all the updates, take a look at the 0.62 changelog.

Meet Doctor, a new React Native command

November 18, 2019

Lucas BentoReact Native Community

Lucas Bento

After over 20 pull requests from 6 contributors in the React Native Community, we're excited to launch react-native doctor, a new command to help you out with getting started, troubleshooting and automatically fixing errors with your development environment. The doctor command is heavily inspired by Expo and Homebrew's own doctor command with a pinch of UI inspired by Jest.

Here it is in action:

How it works

The doctor command currently supports most of the software and libraries that React Native relies on, such as CocoaPods, Xcode and Android SDK. With doctor we'll find issues with your development environment and give you the option to automatically fix them. If doctor is not able to fix an issue, it will display a message and a helpful link explaining how to fix it manually as the following:

Doctor command with a link to help on Android SDK's installation

Try it now

The doctor command is available as a part of React Native 0.62. However, you can try it without upgrading yet:

npx @react-native-community/cli doctor

What checks are currently supported

doctor currently supports the following checks:

  • Node.js (>= 8.3)
  • yarn (>= 1.10)
  • npm (>= 4)
  • Watchman (>= 4), used for watching changes in the filesystem when in development mode.

Specific to the Android environment:

  • Android SDK (>= 26), the software runtime for Android.
  • Android NDK (>= 19), the native development toolkit for Android.
  • ANDROID_HOME, environment variable required by the Android SDK setup.

And to the iOS environment:

  • Xcode (>= 10), IDE for developing, building and shipping iOS applications.
  • CocoaPods, library dependency management tool for iOS applications.
  • ios-deploy (optional), library used internally by the CLI to install applications on a physical iOS device.

Thanks

Huge thanks for the React Native Community for working on this, in particular @thymikee, @thib92, @jmeistrich, @tido64 and @rickhanlonii.

Announcing React Native 0.61 with Fast Refresh

September 18, 2019

Dan AbramovReact Core at Facebook

Dan Abramov

We’re excited to announce React Native 0.61, which includes a new reloading experience we’re calling Fast Refresh.

Fast Refresh

When we asked the React Native community about common pain points, one of the top answers was that the “hot reloading” feature was broken. It didn’t work reliably for function components, often failed to update the screen, and wasn’t resilient to typos and mistakes. We heard that most people turned it off because it was too unreliable.

In React Native 0.61, we’re unifying the existing “live reloading” (reload on save) and “hot reloading” features into a single new feature called “Fast Refresh”. Fast Refresh was implemented from scratch with the following principles:

  • Fast Refresh fully supports modern React, including function components and Hooks.
  • Fast Refresh gracefully recovers after typos and other mistakes, and falls back to a full reload when needed.
  • Fast Refresh doesn’t perform invasive code transformations so it’s reliable enough to be on by default.

To see Fast Refresh in action, check out this video:

Give it a try, and let us know what you think! If you prefer, you can turn it off in the Dev Menu (Cmd+D on iOS, Cmd+M or Ctrl+M on Android). Turning it on and off is instant so you can do it any time.

Here are a few Fast Refresh tips:

  • Fast Refresh preserves React local state in function components (and Hooks!) by default.
  • If you need to reset the React state on every edit, you can add a special // @refresh reset comment to the file with that component.
  • Fast Refresh always remounts class components without preserving state. This ensures it works reliably.
  • We all make mistakes in the code! Fast Refresh automatically retries rendering after you save a file. You don't need to reload the app manually after fixing a syntax or a runtime error.
  • Adding a console.log or a debugger statement during edits is a neat debugging technique.

Please report any issues with Fast Refresh on GitHub, and we’ll look into them.

Other Improvements

  • Fixed use_frameworks! CocoaPods support. In 0.60 we made some updates to integrate CocoaPods by default. Unfortunately, this broke builds using use_frameworks!. This is fixed in 0.61, making it easier to integrate React Native into your iOS projects that require building with dynamic frameworks.
  • Add useWindowDimensions Hook. This new Hook automatically provides and subscribes to dimension updates, and can be used instead of the Dimensions API in most cases.
  • React was upgraded to 16.9. This version deprecates old names for the UNSAFE_ lifecycle methods, contains improvements to act, and more. See the React 16.9 blog post for an automated migration script and more information.

Breaking Changes

  • Remove React .xcodeproj. In 0.60, we introduced auto-linking support via CocoaPods. We have also integrated CocoaPods into the e2e tests runs, so that from now on, we have a unified standard way of integrating RN into iOS apps. This effectively deprecates the React .xcodeproj support, and the file has been removed starting 0.61. Note: if you use 0.60 auto-linking already, you shouldn't be affected.

Thanks

Thanks to all of the contributors that helped make 0.61 possible!

To see all the updates, take a look at the 0.61 changelog.

Meet Hermes, a new JavaScript Engine optimized for React Native

July 17, 2019

Rachel NaborsDocumentation Engineer at Facebook

Rachel Nabors

Last week at Chain React we announced Hermes, an open source JavaScript engine we’ve been working on at Facebook. It’s a small and lightweight JavaScript engine optimized for running React Native on Android. Check it out!

Hermes improves React Native performance by decreasing memory utilization, reducing download size, and decreasing the time it takes for the app to become usable or “time to interactive” (TTI).

“As we analyzed performance data, we noticed that the JavaScript engine itself was a significant factor in startup performance and download size. With this data in hand, we knew we had to optimize JavaScript performance in the more constrained environments of a mobile phone compared with a desktop or laptop. After exploring other options, we built a new JavaScript engine we call Hermes. It is designed to improve app performance, focusing on our React Native apps, even on mass-market devices with limited memory, slow storage, and reduced computing power.” —Hermes: An open source JavaScript engine optimized for mobile apps, starting with React Native

Want to get started right away? Be sure to check out our new guide to enabling Hermes in your existing React Native app in the docs!

Illustration of the Hermes and React Native logos joined into a winged fury, rising in a crashing electrical storm from a lone, glowing, presumably Android phone. Illustration by Rachel Nabors

Announcing React Native 0.60

July 3, 2019

Ryan TurnerCore Maintainer & React Native Developer

Ryan Turner

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.

The new init screen helps developers get started from the get-go with resources and a good example

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 podspecs 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!

Upgrade Helper cleanly and easily shows the changes needed to migrate to a different version of React Native

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!

React Native Open Source Update June 2019

June 12, 2019

Christoph NakazawaEngineer at Facebook

Christoph Nakazawa

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:

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 ✨

React Native at F8 and Open Source Podcast

May 1, 2019

Christoph NakazawaEngineer at Facebook

Christoph Nakazawa

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:

F8 Talk about React Native

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:

Next →