Highlights​

• Debugging Improvements
• Stable Symlink Support in Metro
• Kotlin Template on Android
• Android 14 Support
• New Architecture Updates
• Deprecated Debugging Features

Breaking Changes​

• Babel Package Renames
• Other Breaking Changes
• React Native CLI Changes
• Deprecated @types/react-native

Highlights​

Debugging Improvements​

The React Native and Hermes teams are committed to improving the debugging experience in React Native. In 0.73, we're happy to share some initial progress out of this ongoing investment.

Console Log History in Hermes​

console.log() is an ever popular way for developers to quickly debug their JavaScript code. In previous releases, console logs in React Native apps would not be recorded until a debugger was connected. This made it hard to observe logs that occur early during app load.

In React Native 0.73 we've addressed this issue. Hermes now captures all console.log() calls in the background, which will be sent to the Console tab when a debugger is first connected — matching the debugging experience in web browsers. This new behaviour works across Flipper, Chrome DevTools connected to Hermes, and the experimental New Debugger.

Updated Debugging Docs​

We've refreshed the Debugging section of our docs, which now includes up-to-date information on how to connect all supported debuggers, more info on React DevTools, and refreshed visuals.

Experimental New Debugger​

The React Native team is working on a new JavaScript debugger experience, intended to replace Flipper, with a Technical Preview available as of React Native 0.73. The new debugger opens immediately, and features a stripped-back Chrome DevTools UI customized for debugging React Native with Hermes.

Learn more about enabling this experience in the docs.

Stable Symlink Support in Metro​

Support for resolving symlinks in Metro is now enabled by default. Symlink support enables React Native to work with monorepo setups when containing directories are configured with watchFolders.

Symlinks are deeply represented in Metro's internals, meaning they work with features such as Fast Refresh, and incur little performance overhead during bundling. Symlinks are supported on all desktop platforms, with and without Watchman.

Kotlin Template on Android​

We're excited to announce that, starting from 0.73, Kotlin is now the recommended language for Android apps built with React Native. This follows the direction that the Android ecosystem has been moving in for several years and allows you to write your app using a modern language.

We've updated React Native's template on Android to use Kotlin instead of Java. The new MainActivity.kt and MainApplication.kt files are 36% smaller in size.

The Upgrade Helper has also been updated to make it easier to migrate your .java files to .kt files. If you've previously modified the Java files in your project and you need support migrating them to Kotlin, you can use the Code > Convert Java file to Kotlin File utility of Android Studio (also accessible with the shortcut Cmd ⌘ + Shift ⇧ + Option ⌥ + K).

Android 14 Support​

We've updated React Native to fully support Android 14. Starting from 0.73, React Native developers can now target the latest Android SDK version, API Level 34 (Upside Down Cake).

Java 17 and Android Gradle Plugin upgrade​

In order to support Android 14, we've updated the version of Android Gradle Plugin (AGP) used to build Android apps from 7.4.x to 8.1.x.

This major version bump of AGP comes with a series of breaking changes that are available in the release notes from Google (8.0.0 and 8.1.0).

Most importantly, Java 17 is now a requirement to build Android apps. You can update your Java version to 17 by running:

brew tap homebrew/cask-versions
brew install --cask zulu17

and by updating your JAVA_HOME as documented in the Getting Started guide.

If you're a library developer, your libraries should work with React Native 0.73 without changes. Earlier this year, we published a note with a clarification on what the AGP bump means for you as a library author.

Grant partial access to photos and videos​

Selected Photos Access allows Android 14 users to grant apps access to specific items in their media library, rather than access to all media. In 0.73, React Native apps now support this capability, by using the READ_MEDIA_VISUAL_USER_SELECTED permission in the PermissionsAndroid API.

Min SDK bump​

React Native 0.73 will be the final version which supports Android 5.0 (API Level 21). The next version of React Native will have a minimum SDK version of 23 (Android 6.0). Read more about the upcoming changes to min SDK bump here.

New Architecture Updates​

We continue the rollout of React Native's New Architecture, to make it available to everyone in the Open Source community.

Since React Native 0.68, both the New Renderer (Fabric) and the New Native Module System (TurboModules) were available to users to experiment and evaluate. We want to thank the community for the feedback we've received so far.

Today we're releasing another piece of the New Architecture: Bridgeless Mode. Up until now, when you enable the New Architecture in your app, the Bridge would still be available to support backward compatibility with older components and modules. However, our vision is to fully sunset the bridge. Starting from React Native 0.73, you can enable Bridgeless Mode which will disable the creation of the bridge entirely.

Together with Bridgeless Mode, we're shipping a Native Module Interop Layer, that will allow you to reuse your old modules when in Bridgeless Mode. The Renderer Interop Layer introduced in React Native 0.72 has also been adapted to work with Bridgeless Mode.

As with the rest of the New Architecture, Bridgeless Mode is initially experimental. We invite interested users to enable it and report any problems and incompatibilities you face in the New Architecture working group.

Deprecated Debugging Features​

Flipper ↔ React Native integration​

We are gradually moving away from Flipper as the default tool for debugging React Native apps. In 0.73, this begins by deprecating the native Flipper integration included with React Native (bootstrap code which wires up Flipper's core plugins). We will be removing this integration and dependency in the next release — meaning parts of Flipper such as the Network plugin will cease to work.

Unchanged: Flipper as a standalone product for native app debugging will continue to exist. Even after its removal from new React Native projects in the future, developers will be able to manually add Flipper to their app if they wish.

For more information on why we are moving away from Flipper, view the RFC.

Remote JavaScript Debugging​

Remote JavaScript Debugging is a legacy debugging mode that connects an external web browser (Chrome) to your app and runs your JavaScript code inside a web page, i.e. http://localhost:8081/debugger-ui. This model could lead to inconsistent app behaviour while debugging, and is incompatible with native modules under the New Architecture.

In 0.73, Remote JavaScript Debugging is deprecated and has been removed from the Dev Menu. Enabling the remote debugger must now be done manually via the NativeDevSettings API. Doing this is covered in the Other Debugging Methods docs.

Breaking Changes​

Babel Package Renames​

We've relocated two Babel-related packages out of Metro and into React Native's repository and versioning scheme, enabling us to simplify maintenance and upgrades. The new versions of these packages support New Architecture features in 0.73, meaning these dependencies must be updated.

Please follow the Upgrade Helper when upgrading, to ensure you have updated these dependencies. Some packages have been renamed:

Other Breaking Changes​

These are some of the key breaking changes in 0.73. Please consult the full changelog for the complete list of breaking changes.

• Raise minimum Node.js requirement to 18.x (#37709) (see also Node.js 16 EOL).
• The template now uses TypeScript 5.0 (#36862).
  • React Native types continue working on TypeScript 4.8.
• Android: Java 17 is now a requirement to build Android apps (see above).
• Android: Major bump of Fresco to 3.0 (#38275).
• iOS: Raise minimum iOS version to 13.4 (#36795).
• iOS: Metro will no longer be automatically started when running builds via Xcode (#38242).

For library authors:

• Android: Bump to AGP 8.1.1 (discussion)

React Native CLI Changes​

Highlighted breaking changes​

• Change default task prefix in build-android command. From now on, when you run build-android, the bundle task will be run instead of assemble (#1913).
• Remove fallback flow for Metro config defaults (#1972).
  • The updated metro.config.js format from 0.72 is now required in 0.73, as we have removed the fallback copy of these defaults from CLI.
• Remove --configuration option from run-ios (replaced with --mode) (#2028).
• Remove --variant option from build-android command (replaced with --mode) (#2026).

See full changelog for v12.0.0.

Deprecated @types/react-native​

As mentioned in First-class Support for TypeScript, we have shipped TypeScript types with react-native since 0.71 and we are now deprecating @types/react-native for 0.73.

We will not ship any future patches for existing versions. The guidance is to migrate away from @types/react-native. See instructions on how to migrate.

Acknowledgements​

React Native 0.73 contains over 2259 commits from 68 contributors. Thanks for all your hard work!

Upgrade to 0.73​

Please use the React Native Upgrade Helper to view code changes between React Native versions for existing projects, in addition to the Upgrading docs. You can also create a new project with npx react-native@latest init MyProject.

If you use Expo, React Native 0.73 will be supported in the Expo SDK 50 release.

This release adds highly requested features for Metro, better error handling, and other developer experience improvements. So much of this work was prioritized from your feedback on the 2022 community survey -- thank you to all those that participated!

Highlights​

• New Metro Features
• Developer Experience Improvements
• Moving New Architecture Updates

Breaking Changes​

• Deprecated Component Removals
• Package Renames

Highlights​

New Metro Features​

Symlink Support (Beta)​

Symlink support continues to be one of the top-requested features in Metro and, in React Native 0.72, we are happy to announce beta support for it.

Symlink support enables React Native to work transparently with monorepo setups and pnpm, removing the need for workarounds. See Enabling Beta Features to use in your app.

It is currently in beta to collect feedback on developer experience given varying workflows, see more details here. We plan to default enable symlinks in 0.73.

Package Exports Support (Beta)​

Package Exports is the modern alternative to the package.json "main" field and provides new capabilities for npm packages to define their public API and target React Native.

By enabling Package Exports support in your Metro config, your app will be compatible with the wider JavaScript ecosystem, including via the new "react-native" community condition. See Enabling Beta Features to use in your app.

Enabling Beta Features​

To enable these features in your project, update your app’s metro.config.js file and set either the resolver.unstable_enableSymlinks or resolver.unstable_enablePackageExports options.

const config = {
  // ...
  resolver: {
    unstable_enableSymlinks: true,
    unstable_enablePackageExports: true,
  },
};

New metro.config.js Setup​

In React Native 0.72, we’ve changed the config loading setup for Metro in React Native CLI. Please update your project’s metro.config.js file to match the template’s version.

This moves control over extending the base React Native Metro config into your project, and we’ve cleaned up the leftover defaults. In addition, this means that standalone Metro CLI commands, such as metro get-dependencies, will now work.

Developer Experience Improvements​

No more redboxes with invalid style properties​

Prior to this release, providing an invalid style property in StyleSheet would result in a redbox. This is a high signal error that disrupts the developer workflow for a relatively low-risk error.

In 0.72, we’ve relaxed this expectation to fail silently, like providing an invalid CSS property in the browser, and have updated types such that some errors may be caught in build-time vs. run-time.

Better error readability for Hermes​

Hermes has added a better error message when invoking an undefined callable.

    var x = undefined; x();
    // Before: undefined is not a function
    // After: x is not a function (it is undefined)

In addition, LogBox stack traces now filter out internal Hermes bytecode frames that are not relevant to app users.

Improved error output of the React Native CLI​

0.72 ships with React Native CLI v11 which includes improvements to reduce duplication, clarify wording, reduce verbose stack traces, and add deep links to relevant docs in the following commands init, run-android, and run-ios.

You can find other improvements in the React Native CLI changelogs.

Faster Compilation and JSON Parsing in Hermes​

Hermes has improved the compilation time of large object literals. For example, in one reported issue, #852, a user had an entire dataset written out as a large object literal. By improving the de-duplication algorithm Hermes uses, compilation sped up by 97% (221c). These improvements will benefit build times for apps that bundle many objects.

Multiple optimizations (de9c, 6e2d) to JSON parsing have also landed, benefiting apps using libraries like redux-persist that rely heavily on JSON manipulation.

More ECMAScript Support in Hermes​

Support for the following specifications in Hermes has landed in React Native 0.72:

• prototype.at support for Array, TypedArray and String. See #823 (ebe2).
• Implement well-formed JSON.stringify (d41d) to prevent ill-formed Unicode strings
• Implement AggregateError (9b25) that represents several errors wrapped in a single error. Useful for multiple errors like from Promise.any() when all promises passed to it reject.

For users on JSC, these features are already available.

Moving New Architecture Updates​

The New Architecture is currently experimental. To keep updates focused to their target audience, we are moving New Architecture updates in 0.72, and future releases, to the dedicated working group. This change will also allow for more frequent updates, such as work that ships in our nightlies.

You can read the 0.72 updates for the New Architecture here. Subscribe to the working group GitHub notifications to stay informed on our progress on the New Architecture.

Breaking Changes​

Deprecated Component Removals​

The following packages have been removed from React Native in 0.72. Please migrate to the recommended community package:

• Slider is superseded by @react-native-community/slider
• DatePickerIOS is superseded by @react-native-community/datetimepicker
• ProgressViewIOS is superseded by @react-native-community/progress-view

Package Renames​

All packages published from the react-native core repository now live under react-native/packages, and are published under the @react-native npm scope to ensure clear ownership.

There are no changes to the react-native package.

This change will not affect you if you have no direct dependency on a renamed package. Otherwise, when upgrading to React Native 0.72, update any renamed dependency to its ~0.72 version.

You can read the motivation that led to these changes in the dedicated RFC.

Acknowledgements​

A lot of this release came from the direct feedback from the community. From reports on noisy redboxes, bugs with Package Exports, benchmarks for the New Architecture — all of it is valuable to hear and we appreciate the time it takes to share feedback.

0.72 contains over 1100 commits from 66 contributors. Thank you for all your hard work!

Upgrade to 0.72​

Check out the list of needed changes in the upgrade-helper, or read the upgrade documentation for how to update your existing project, or create a new project with npx react-native@latest init MyProject.

If you use Expo, React Native version 0.72 will be supported in the Expo SDK 49 release.

• React Native projects will work with more npm packages out-of-the-box
• New capabilities for packages to define their API and target React Native
• Some breaking changes to package resolution (in edge cases)

In this post we'll cover how Package Exports works, and what these changes mean for you as a React Native app developer or package maintainer.

What is Package Exports?​

Introduced in Node.js 12.7.0, Package Exports is the modern approach for npm packages to specify entry points — the mapping of package subpaths which can be externally imported and which file(s) they should resolve to.

Supporting "exports" improves how React Native projects will work with the wider JavaScript ecosystem (used in ~16.6k packages today), and gives package authors a standardised feature set for multiplatform packages to target React Native.

"exports" can be used alongside, or instead of, "main" in a package.json file.

{
  "name": "@storybook/addon-actions",
  "main": "./dist/index.js",
  ...
  "exports": {
    ".": {
      "node": "./dist/index.js",
      "import": "./dist/index.mjs",
      "default": "./dist/index.js"
    },
    "./preview": {
      "import": "./dist/preview.mjs",
      "default": "./dist/preview.js"
    },
    ...
    "./package.json": "./package.json"
  }
}

Here's some app code consuming the above package by importing different subpaths of @storybook/addon-actions.

import {action} from '@storybook/addon-actions';
// -> '@storybook/addon-actions/dist/index.js'

import {action} from '@storybook/addon-actions/preview';
// -> '@storybook/addon-actions/dist/preview.js'

import helpers from '@storybook/addon-actions/src/preset/addArgsHelpers';
// Inaccessible - not listed in "exports"!

The headlining features of Package Exports are:

• Package encapsulation: Only subpaths defined in "exports" can be imported from outside the package — giving packages control over their public API.
• Subpath aliases: Packages can define custom subpaths which map to a different file location (including via subpath patterns) — allowing relocation of files while preserving the public API.
• Conditional exports: A subpath may resolve to a different underlying file depending on environment. For example, to target "node", "browser", or "react-native" runtimes — replacing the "browser" field spec.

For app developers​

Package Exports can be enabled today, in beta.

• Imports against packages that depend on Package Exports features (such as Firebase and Storybook) should now work as designed.
• React Native for Web projects using Metro will now be able to use the "browser" conditional export, removing the need for workarounds.

Enabling Package Exports brings a few edge-case breaking changes that may affect specific projects, and which you can test today.

In a future React Native release, Package Exports will be enabled by default. In a chicken-and-egg situation, React Native apps were previously a holdout for some packages to migrate to "exports" — or used our "react-native" root field escape hatch. Supporting these features in Metro will allow the ecosystem to move forward.

Enabling Package Exports (beta)​

Package Exports can be enabled in your app's metro.config.js file via the resolver.unstable_enablePackageExports option.

const config = {
  // ...
  resolver: {
    unstable_enablePackageExports: true,
  },
};

Metro exposes two further resolver options which configure how conditional exports behave:

• unstable_conditionNames — The set of condition names to assert when resolving conditional exports. By default, we match ['require', 'import', 'react-native'].
• unstable_conditionsByPlatform — The additional condition names to assert when resolving for a given platform target. By default, this matches 'browser' when the platform is 'web'.

Validating changes in your project​

For existing projects, we recommend that early adopters follow these steps to see if resolution changes occur after enabling unstable_enablePackageExports. This is a one-time process. It's likely that there will be no changes at all, but we'd like developers to opt in with certainty.

Breaking changes​

We decided on an implementation of Package Exports in Metro that is spec-compliant (necessitating some breaking changes), but backwards compatible otherwise (helping apps with existing imports to migrate gradually).

The key breaking change is that when "exports" is provided by a package, it will be consulted first (before any other package.json fields) — and a matched subpath target will be used directly.

• Metro will not expand sourceExts against the import specifier.
• Metro will not resolve platform-specific extensions against the target file.

For more details, please see all breaking changes in the Metro docs.

Package encapsulation is lenient​

When Metro encounters a subpath that isn't listed in "exports", it will fall back to legacy resolution. This is a compatibility feature intended to reduce user friction for previously allowable imports in existing React Native projects.

Instead of throwing an error, Metro will log a warning.

warn: You have imported the module "foo/private/fn.js" which is not listed in
the "exports" of "foo". Consider updating your call site or asking the package
maintainer(s) to expose this API.

For package maintainers (preview)​

Package Exports provides the ability to restrict access to your package's internals, and more predictable capabilities for libraries to target React Native and React Native for Web.

If you are using "exports" today​

If your package uses "exports" alongside the current "react-native" root field, please bear in mind the breaking changes for users above. For users enabling this feature in Metro, "exports" will now be considered first during module resolution.

In practice, we anticipate the main change for users will be the enforcement (via warnings) of any inaccessible subpaths in their apps, from respecting "exports" package encapsulation.

Migrating to "exports"​

Adding an "exports" field to your package is entirely optional. Existing package resolution features will behave identically for packages which don't use "exports" — and we have no plans to remove this behaviour.

We believe that the new features of "exports" provide a compelling feature set for React Native package maintainers.

• Tighten your package API: This is a great time to review the module API of your package, which can now be formally defined via exported subpath aliases. This prevents users from accessing internal APIs, reducing surface area for bugs.
• Conditional exports: If your package targets React Native for Web (i.e. "react-native" and "browser"), we now give packages control of the resolution order of these conditions (see next heading).

If you decide to introduce "exports", we recommend making this as a breaking change. We've prepared a migration guide in the Metro docs which includes how to replace features such as platform-specific extensions.

The new "react-native" condition​

We've introduced "react-native" as a community condition (for use with conditional exports). This represents React Native, the framework, sitting alongside other recognised runtimes such as "node" and "deno" (RFC).

Community Conditions Definitions — "react-native"

Will be matched by the React Native framework (all platforms). To target React Native for Web, "browser" should be specified before this condition.

This replaces the previous "react-native" root field. The priority order for how this was previously resolved was determined by projects, which created ambiguity when using React Native for Web. Under "exports", packages concretely define the resolution order for conditional entry points — removing this ambiguity.

  "exports": {
    "browser": "./dist/index-browser.js",
    "react-native": "./dist/index-react-native.js",
    "default": "./dist/index.js"
  }

The future: Stable "exports", enabled by default​

In the next React Native release, we are aiming to remove the unstable_ prefix for this feature (having addressed planned performance work and any bugs) and will enable Package Exports resolution by default.

With "exports" enabled for everyone, we can begin taking the React Native community forward — for example, React Native's core packages could be updated to better separate public and internal modules.

Thanks​

Thanks to members of the React Native community that gave feedback on the RFC: @SimenB, @tido64, @byCedric, @thymikee.

Huge thanks to @motiz88 and @robhogan at Meta for supporting the development of this feature.

The contributors who helped tackle the incident recently attended a post-mortem meeting to discuss in detail what happened, what we all learned from it, and what actions we are going to take to avoid similar outages in the future.

What happened

On November 4th 2022, we published the version 0.71.0-rc0 of React Native, the first release candidate for 0.71, on several public repositories.

A major change made in this release candidate helped to improve build times by publishing artifacts to Maven Central, instead of building them from source. More details on how this was done are available in RFC#508 and related discussions.

Unfortunately, because of the way we scaffolded new projects from the template, this caused build failures for any Android user on older versions because they would start downloading new artifacts for 0.71.0-rc0 instead of the version they were using in their project (like 0.68.0).

Why this happened

The React Native template provides a build.gradle file to build Android apps. This file contains a dependency on the React Native Android library as follows: implementation("com.facebook.react:react-native:+").

Importantly, the + part of this dependency (a Gradle Dynamic version) tells Gradle to pick the highest available version of React Native. Using Gradle Dynamic versions is considered an antipattern as it exposes users to less-reproducible builds.

We were aware of the issues dynamic versions could cause, so in 0.71 we cleaned up the new app template and removed all the + dependencies. However, users on older versions of React Native were still using a + version.

This caused builds with React Native versions before 0.71.0-rc.0 to query all the repositories for the highest available versions of the React Native. Because the newly pushed 0.71.0-rc.0 on Maven Central became the highest version available, builds with React Native versions before 0.71.0-rc.0 started using artifacts from 0.71.0-rc.0. The React Native version mismatch between the local build (e.g 0.68.0) and artifacts from Maven Central (0.71.0-rc.0) caused these builds to fail.

Further technical details on this event area are also available on this GitHub issue.

How we mitigated & resolved

As soon as we identified the issue on November 4th, the community found and shared a manual workaround to fix the issue which would pin React Native to a specific, correcting the mistake.

Then, over the weekend of November 5th and 6th, the release crew shipped patch releases for all previous React Native versions down to 0.63 which automatically applied the patch, so that users could update to a fixed version of React Native.

At the same time, we reached out to Sonatype to ask for the removal of the offending artifacts.

The issue was fully resolved on November 8th when the artifacts were fully removed from Maven Central.

Timeline of events

This section contains a brief timeline of the events. All times are GMT/UTC +0

• Nov 4th - 5:06 PM: 0.71-RC0 is released.
• Nov 4th - 6:20 PM: First report of build issue is opened.
• Nov 4th - 7:45 PM: Issue is identified by community.
• Nov 4th - 9:39 PM: Workarounds are communicated, Expo deploys fix to all their users.
• Nov 5th - 03:04 AM: New issue is open to communicate status and workarounds.
• Nov 6th - 04:11 PM: Ticket to SonaType asking for removal of the artifacts is open.
• Nov 6th - 04:40 PM: First tweet from @reactnative with ack + link to issue.
• Nov 6th - 07:05 PM: Decision to patch React Native versions back to 0.63.
• Nov 7th - 12:47 AM: Last patched release is released: 0.63.5.
• Nov 8th - 08:04 PM: Artifacts on Maven Central are fully removed.
• Nov 10th - 11:51 AM: Issue about the incident is closed.

Lessons Learned

While in many ways the conditions to trigger this incident has existed since React Native 0.12.0, we want to ensure that the foundations on which we develop and release React Native moving forward are stronger. Here are some of the lessons learned and the actionables on how we’ll adapt our processes and infrastructure to respond faster and stronger in the future.

Incident response strategy​

This incident highlighted gaps in our incident response strategy for open-source issues related to React Native.

The community quickly found a workaround in less than 2 hours. Due to our lack of visibility on the scope of the impact of this issue, as well as the complexity required to fix it for old versions, we relied on impacted people discovering the workaround on the GitHub issue.

It took us 48 hours to recognize the larger scope of this issue and that we couldn’t rely on everyone finding the GitHub issue. We needed to prioritize more complex active mitigations to automatically fix people’s projects.

We will be revisiting our processes for when to rely on developer-applied-workarounds vs fixes that we can deploy automatically. We will also take a look at our options for getting a better live pulse on the health of our ecosystem.

Release Support Policy​

As visualized in the rn-versions tool, to cover more than 90% of the developer base of React Native at the time of the incident, we had to release patches all the way down to version 0.63.

We believe this is caused by the React Native upgrade experience which has historically been full of frictions. We are currently looking into ways to improve the upgrade experience to make it smoother and faster to mitigate this fragmentation of the ecosystem.

Releasing a newer version of React Native should never have an impact on users on older versions, and we want to apologize for the disruption we caused to your workflow.

Similarly, we want to also stress the importance of being up to date with the latest version of your dependencies and React Native to benefit from the improvements and the safeguards we introduced. This incident happened during a time in which an official release support policy was getting defined and wasn’t broadcasted or enforced yet.

In the future, we will communicate our support policy over our communication channels and we will consider deprecating older versions of React Native on npm.

Improved testing and best practices for 3rd party libraries​

This incident highlighted the importance of having better release testing and better guidance to 3rd party libraries.

On the testing side, releasing versions down to 0.63.x proved to be challenging due to the lack of automation and testing we now have in place for stable releases. We recognize the importance of our release and testing infrastructure and we’re going to invest further in it in the future.

Specifically, we are now encouraging and supporting 3rd party library testing as part of the release of react native. We’re also adding some new channels and roles in the Core Contributors Discord Server.

On top of this, we started a closer collaboration with Callstack, the maintainers of create-react-native-library, to improve the library template and make sure it follows all the necessary best practices to integrate with React Native projects. The newer version of create-react-native-library is now fully compatible with 0.71 projects while still offering backward compatibility.

Conclusions

We want to apologize for the disruption this caused to the workflows of developers all around the world. As highlighted above, we have already started taking action to strengthen our foundation - and more work is due.

We hope that sharing these insights will help you all better understand this incident, and that you can leverage our learnings to apply better practices in your own tools and projects.

In closing, we want once again to thank Sonatype for helping us remove the artifacts, our community, and the release crew that worked tirelessly to address this as soon as possible.

• TypeScript by default
• Simplifying layouts with Flexbox Gap
• Web-inspired props for accessibility, styles, and events
• Restoring PropTypes
• Developer Experience Improvements
• New Architecture Updates

In this post we’ll cover some of the highlights of 0.71.

TypeScript by default​

In this release, we’re investing in the TypeScript experience of React Native.

Starting with 0.71, when you create a new React Native app via the React Native CLI you'll get a TypeScript app by default. The new project is already set up with a tsconfig.json so out of the box your IDE will help you write typed code right away.

We’re also offering built-in, more accurate TypeScript declarations directly from the react-native package. This means you won’t need @types/react-native any longer, and the types will be updated in lockstep with React Native releases.

Finally, our documentation has been updated to feature TypeScript for all examples.

For more details on this change, including migration steps and how this affects Flow users, check out our previous post First-class Support for TypeScript.

Simplifying layouts with Flexbox gap​

With React Native you can flexibly layout components on different screen sizes using Flexbox. Browsers have supported the Flexbox properties gap, rowGap, and columnGap, which allow you to specify the amount of space between all items in a Flexbox.

These properties have been long requested in React Native, and 0.71 adds initial support for gaps defined using pixel values. In future versions, we will add support for more values, such as percentages.

To see why this is useful, imagine trying to build a responsive layout with variably sized cards, 10px apart from each other, hugging the edges of the parent container. Trying to accomplish this layout with child margins can be tricky.

The following shows a layout where we start by giving each child margin: 10 style:

Margins are applied uniformly to the edges of all children and don’t collapse under Flexbox, giving us spacing at the exterior of the cards, and double the space on the interior compared to what we wanted. We can get around this by applying non-uniform margins, using negative margins on the parent, halving our intended spacing, etc, but it can be made much easier.

With flex gap, this layout can be achieved by setting gap: 10 on the container for a 10 pixel gap between the interior of the cards:

For more information on Flexbox gaps, see this blogpost from CSS Tricks.

Web-inspired props for accessibility, styles, and events​

This release includes a number of new props inspired by web standards to align React Native’s APIs across many platforms. These new props are purely additive so there are no expected migrations or change of behavior for equivalent accessibility, behavior, or style props.

For any new prop alias introduced, if there is an existing prop with a different name and both are specified, the new alias prop value will take precedence. For example, this release adds a src prop alias for source on the Image component to align with the src prop on web. If both src and source are provided, the new src prop will be used.

Accessibility​

We introduced ARIA props as alias to existing React Native accessibility props.

These props now exist on all core components of React Native:aria-label, aria-labelledby,aria-modal, id, aria-busy, aria-checked, aria-disabled, aria-expanded, aria-selected, aria-valuemax, aria-valuemin, aria-valuenow, and aria-valuetext.

We also introduced equivalent web behavior for: aria-hidden, aria-live, role, and tabIndex.

See this issue for more details.

Component-Specific Behavior​

There were also props introduced to align prop names with equivalent DOM prop names for core components.

• Image: alt, tintColor, crossOrigin, height, referrerPolicy, src, srcSet, and width.
• TextInput: autoComplete, enterKeyHint, inputMode, readOnly, and rows.

See this issue for more details.

Styles​

To align with certain CSS styles, there have been feature extensions for the following styles:

• aspectRatio now supports string values
• fontVariant now supports space-separated string values
• fontWeight now supports number values
• transform now supports string values

The following aliases have been added to shadow existing React Native styles:

• objectFit
• pointerEvents
• userSelect
• verticalAlign

See this issue for more details.

Events​

Finally, we also added an opt-in implementation of PointerEvents

Once enabled, the following handlers on View will support hover:

• onPointerOver, onPointerOut
• onPointerEnter, onPointerLeave

These events are also implemented in Pressability for new opt-in support for hover.

To enable these features, set the following flags to true:

import ReactNativeFeatureFlags from 'react-native/Libraries/ReactNative/ReactNativeFeatureFlags';

// enable the JS-side of the w3c PointerEvent implementation
ReactNativeFeatureFlags.shouldEmitW3CPointerEvents = () => true;

// enable hover events in Pressibility to be backed by the PointerEvent implementation.
// shouldEmitW3CPointerEvents should also be true
ReactNativeFeatureFlags.shouldPressibilityUseW3CPointerEventsForHover =
  () => true;

Check out our dedicated PointerEvents post to learn more.

Restoring PropTypes​

React Native’s prop types, such as ViewPropTypes and Text.propTypes, were deprecated in 0.66 and accessing them would output deprecation warnings. When they were removed in 0.68, many developers began experiencing errors when upgrading to the latest version of React Native.

After some investigation, we realized that a couple issues prevented the community from taking action on the deprecation warnings. First, the deprecation warning was not always actionable which caused people to ignore them (issue one, issue two). Second, the deprecation warnings were being incorrectly filtered by LogBox.ignoreLogs. Both of these have now been fixed, but we want to give people more time to upgrade the deprecated call sites.

So in this release we are adding back React Native’s propTypes so that it is easier for people to upgrade and migrate their code to avoid using them. The deprecated-react-native-prop-types package has also been updated for all of the props in 0.71. In the future, we plan to proceed with the deprecation and remove prop types once again. We expect that when we revisit the removal, the community will experience significantly fewer issues.

Developer Experience Improvements​

React DevTools​

In this release, we've brought two popular React DevTools features on web to React Native.

"Click to inspect" is the option in the top left corner of React Dev Tools that allows you to click on an item in the app to inspect it in Dev Tools, similar to the Chrome element inspector.

Component highlighting will highlight the element you select in DevTools in the app so you can see which React components line up with which on-screen elements.

Here are both features in action:

Hermes​

In React Native 0.70, we made Hermes the default engine for React Native.

In React Native 0.71, we’re upgrading Hermes with a few notable improvements:

• Improve source maps: By loading source maps over the network with Metro we’ve restored the ability to use source maps in recent versions of Chrome Dev Tools outside of Flipper.
• Improve JSON.parse performance: This version includes a performance optimization that improves the performance of JSON.parse up to 30%.
• Add support for .at(): Hermes now supports.at() for String, TypedArray, and Array.

For a full list of changes see the Road to 71 issue.

New Architecture​

This release brings many improvements to the experimental New Architecture experience based on user feedback and reports we collected so far.

• Reduced build times: The new distribution model uses Maven Central, which allows us to greatly reduce the build time on Android, resolves many build problems on Windows, and provides a more seamless experience with the New Architecture. Read more here.
• Write less C++ code: You can now enable the New Architecture without having to add any C++ code in your app and the CLI app template has been cleaned of all the C++ code and the CMake files. Read more here.
• Better encapsulation of iOS app setup: On iOS, we followed a similar approach to Android and encapsulated most of the logic to set up the New Architecture in the RCTAppDelegate class, which will simplify upgrades in the future with fewer manual breaking changes.
• Better dependency management on iOS: For library maintainers, we've added a new install_module_dependencies function to call inside your package podspec which will install all the required dependencies for the New Architecture.
• Bug fixes and better IDE support: we fixed several bugs and issues (like better IDE support for Android) that were reported by our users in the New Architecture Working Group.

As a reminder, the New Architecture is still an experimental API experience as we iterate on changes to make adoption easier. Please try out the new simplified steps in the New Architecture documentation and post any feedback you have to the New Architecture Working Group.

Other Notable Fixes​

• Better stack frame collapsing: We've updated the list of internal frames for React Native so LogBox will show your code more often rather than internal React Native frames, helping you to debug issues faster.
• Build time improvements: We migrated assets to Maven Central for prefabs to improve build times (both iOS and Android) for Hermes in both the current and new architectures.
• Android template improvements: The Android template was heavily cleaned and now fully relies on the React Native Gradle Plugin. You can find the configuration instructions directly inside the template or in the new dedicated page on the website.

Breaking changes​

• Changes to Console Logging: LogBox.ignoreLog no longer filters console logs. This means you will start seeing logs in the console that you have silenced in LogBox. See this comment for more details.
• Removed AsyncStorage and MaskedViewIOS: These components have been deprecated since version 0.59, so it’s time we remove them entirely. For alternatives, please check React Native Directory for community packages that cover those use cases.
• JSCRuntime moved to react-jsc: react-jsi is now split into react-jsc and react-jsi. If you use JSCRuntime, you will need to add react-jsc as a dependency (facebook/react-native@6b129d8).

Acknowledgements​

This release is possible thanks to the work of 70+ contributors adding over 1000 commits.

We especially want to thank those who contributed to these major React Native projects:

• Flexbox Gap Support: @intergalacticspacehighway and @jacobp100.
• Web-inspired props: @gabrieldonadel @dakshbhardwaj @dhruvtailor7 @ankit-tailor @madhav23bansal.
• Codegen Improvements: @AntoineDoubovetzky, @MaeIg, @Marcoo09, @Naturalclar, @Pranav-yadav, @ZihanChen-MSFT, @dakshbhardwaj, @dhruvtailor7, @gabrieldonadel, @harshsiri110, @ken0nek, @kylemacabasco, @matiassalles99, @mdaj06, @mohitcharkha, @tarunrajput, @vinayharwani13, @youedd, @byCedric.

Finally, thanks to @cortinico, @kelset, @dmytrorykun, @cipolleschi, and @titozzz for cutting this release!

Try out 0.71.0 now!​

For React Native CLI users, see the upgrade documentation for how to update your existing project, or create a new project with npx react-native init MyProject.

React Native version 0.71 will be supported in Expo SDK version 48.

• New app template is TypeScript by default
• TypeScript declarations shipped with React Native
• React Native documentation is TypeScript First

In this post we’ll cover what these changes mean for you as a TypeScript or Flow user.

New App Template is TypeScript By Default​

Starting with 0.71, when you create a new React Native app via the React Native CLI you'll get a TypeScript app by default!

npx react-native init My71App --version 0.71.0

The starting point of a newly generated app will be App.tsx instead of App.js – fully TypeScript typed. The new project is already set up with a tsconfig.json so out of the box your IDE will help you write typed code right away!

Declarations Shipped with React Native​

0.71 is the first release with built-in TypeScript (TS) declarations.

Prior, TypeScript declarations for React Native were provided by @types/react-native hosted in the DefinitelyTyped repository. The decision to co-locate TypeScript types with React Native source was for improved correctness and maintenance.

@types/react-native only provides types for stable releases. This means if you ever wanted to develop with a pre-release version of React Native in TypeScript, you’d have to use types from an older release which may be inaccurate. Releasing @types/react-native is also error-prone. The releases lag React Native releases, and the process involves manually inspecting for type changes made to React Native’s public API and updating the TS declaration to match.

With TS types co-located with React Native source, there is more visibility and ownership of TS types. Our team is actively working on tools to maintain alignment between Flow and TS.

This change also removes a dependency for React Native users to manage. When upgrading to 0.71 or above, you can remove @types/react-native as a dependency. Refer to the new app template on how to set up TypeScript support.

We plan to deprecate @types/react-native for versions 0.73 and onward. Concretely this means:

• @types/react-native tracking React Native versions 0.71 and 0.72 will be released. They will be identical to the types in React Native on the relevant release branches.
• For React Native 0.73 and onward, TS types will only be available from React Native.

How to Migrate​

Please migrate to the new co-located types at your earliest convenience. Here are more details on migrating based on your needs.

App Maintainer​

Once you upgrade to React Native >= 0.71, you can remove the @types/react-native from your devDependency.

Library Maintainer​

Libraries that target versions of React Native below 0.71 may use a peerDependency of @types/react-native to typecheck against the apps version of typings. This dependency should be marked as optional in peerDependenciesMeta so that the typings are not required for users without TypeScript or for 0.71 users where typings are built-in.

Maintainer of TypeScript declarations that depend on @types/react-native​

Check out the breaking changes introduced with 0.71 to see if you’re ready to migrate.

What if I use Flow?​

Flow users can continue to typecheck applications targeting 0.71+ but configuration logic for it is no longer included out-of-the box in the template.

Flow users have previously upgraded React Native’s Flow types by merging in the .flowconfig from the new app template and manually updating flow-bin. The new app template no longer has a .flowconfig, but one is still present in the React Native repository that can be used as a basis for your app.

If you need to start a new React Native app in Flow, you can reference the new app template from 0.70.

What if I find a bug in the TypeScript declaration?​

Regardless of whether you’re using built-in TS types or @types/react-native, if you find a bug please submit a PR to both React Native and DefinitelyTyped repositories. If you don’t know how to fix it, please file a GitHub issue in the React Native repository and mention @lunaleaps on the issue.

Documentation is TypeScript First​

To ensure a consistent TypeScript experience, we have made several updates to the React Native documentation to reflect TypeScript as the new default language.

Code examples now allow inline TypeScript and over 170 interactive code examples have been updated to pass linting, formatting, and type-checking in the new template. Most examples are valid as both TypeScript and JavaScript. Where they are incompatible, you can view the example in either language.

If you spot a mistake or you have an improvement, remember that the website is also open source and we would love to see your PRs!

Thank you to the React Native TypeScript community!​

In closing, we want to recognize all the work done over the years by the community to ensure that TypeScript is usable by React Native developers.

We want to thank all the contributors that have been maintaining @types/react-native since 2015! We see the effort and care you all have put into making sure React Native users have the best experience.

Thank you to @acoates, @eps1lon, @kelset, @tido64, @Titozzz, and @ZihanChen-MSFT for your help consulting, questioning, communicating and reviewing changes to move the TypeScript types to React Native.

Similarly, we want to thank the maintainers of react-native-template-typescript for supporting the TypeScript experience for new app development in React Native since day one.

We look forward to collaborating more directly in the React Native repository and continue improving the React Native developer experience!

It’s been over a year since we shared our many platform vision on the wins of building beyond mobile and how it sets a higher bar for all platforms. During this time, we've increased our investments in React Native for VR, Desktop, and Web. With differences in hardware and interactions on these platforms, it raised the question of how React Native should holistically handle input.

Going Beyond Touch​

Desktop and VR have historically relied on mouse and keyboard input where mobile is primarily touch. That narrative has evolved with touch-screen laptops and growing needs to support interactions via keyboard and pen on mobile. All of which the React Native touch event system is not equipped to handle.

As a result, users of out-of-tree platforms fork React Native and/or create custom native components and modules to support critical features like hover detection or left-click. This divergence leads to prop redundancy with event handlers serving similar purposes but for different platforms. It adds complexity to the framework and makes code-sharing between platforms tedious. For these reasons, the team was motivated to provide a cross-platform pointer API.

React Native aims to provide robust and expressive APIs to build for many platforms while maintaining characteristic platform experiences. Designing such an API is challenging yet thankfully there is prior art in the pointer space that React Native can leverage.

Looking to Web​

Web is a platform with similar challenges in scaling to many platforms while also considering future-proof design. The World Wide Web consortium (W3C) is tasked with setting standards and proposals to build a Web that is interoperable amongst different platforms and browsers.

Most relevant for our needs, the W3C has defined behavior for an abstract form of input, called a pointer. The Pointer Events specification builds on mouse events and aims to provide a single set of events and interfaces for cross-device pointer input while still allowing for device-specific handling when necessary.

Following the Pointer Events specification provides React Native users many benefits. Beyond addressing the problems mentioned earlier, it raises the capabilities of platforms that haven’t historically had to consider multi-input type interactions. Think attaching a bluetooth mouse to your Android phone or the Apple pencil supporting hover on the iPad M2.

Being spec-complaint also provides opportunity for knowledge sharing between Web and React Native. Education of Web expectations around Pointer Events can doubly serve React Native developers. However, we also recognize that React Native requirements are different than web and our approach to specifications is best effort with well documented deviations so expectations are clear. There is related work of aligning certain Web standards to reduce API fragmentation in accessibility and performance APIs.

Porting Web Platform Tests​

While the Pointer Events specification provides interfaces and behavior descriptions of the API, we found it wasn’t specific enough for us to confidently make changes and point to the specification as verification. However, web browsers use another mechanism to ensure compliance and interoperability — the Web Platform Tests!

The Web Platform Tests are written to work against the browser’s imperative DOM APIs — unsupported by React Native as it uses its own view primitives. This means that we aren’t able to code-share the tests with browsers and instead have an analogous testing API for React Native that makes it easier to port those Web Platform Tests.

We implemented a new manual testing framework which we are now using for verifying our implementations through RNTester. These tests are tentatively named the RNTester Platform Tests and are still fairly basic. Our implementation provides an API to construct test cases as components themselves which are rendered and where the results are reported solely through the UI.

These tests will continue to be helpful as we further the completeness of our Pointer Events implementation. These tests will also scale to test Pointer Events implementations on platforms beyond Android and iOS. As the number of tests in our suite increase we will be looking to automate the running of these tests so that we are better equipped to catch regressions in our implementations.

How it works​

Much of our Pointer Events implementation builds off existing infrastructure for dispatching touch events. On Android and iOS we leverage the relevant MotionEvent and UITouch events. The general flow of event dispatching is illustrated below.

Using Android as an example, the general approach to leveraging platform events are:

1. Iterate through all pointers of the MotionEvent and do a depth-first search to determine the target React view of each pointer and its ancestral path.
2. Map the category of MotionEvent to the relevant pointer events. There is a 1-to-many relationship between MotionEvent and PointerEvent. In the illustration of their relationship, dotted lines indicate fired events if the pointing device does not support hover.

1. Build the PointerEvent interface with platform details from the MotionEvent and cached state of previous interactions. (Ex. the button property)
2. Dispatch the pointer events from Android to React Native’s core event queue and leverage JSI to call the dispatchEvent method in react-native-renderer which iterates through the React tree for the bubble and capture phase of the event.

Implementation Progress​

When it comes to our current progress of implementing the Pointer Events specification we’ve focused on a solid baseline implementation of the most common events that handle things like pressing, hovering, and moving.

Events​

Event Properties​

For each of the events mentioned above we’ve also implemented the majority of the properties expected in the PointerEvent object — though in React Native these are exposed through the event.nativeEvent property. You can find an enumeration of all the implemented properties in the event object’s Flowtype interface definition. One notable exception to being completely implemented is the relatedTarget property as exposing a native view reference in this ad-hoc manner isn’t trivial.

Future Work and Exploration​

In addition to the events above there are also some other APIs related to Pointer Events. In the future, we plan to be implement these APIs as a part of this effort. These APIs include:

• Pointer Capture API
  • Includes the imperative API exposed on element references including setPointerCapture(), releasePointerCapture(), and hasPointerCapture().
• touch-action style property
  • The web uses this CSS property to declaratively negotiate gestures between the browser and a website’s own event handling code. In React Native this could be used for negotiating the event handling between a View’s pointer event handlers and a parent ScrollView.
• click, contextmenu, auxclick
  • click is an abstract definition of interaction that may be triggered through accessibility paradigms or other characteristic platform interactions.

Another benefit of the native Pointer Events implementation is that it will allow us to revisit and improve various forms of gesture handling currently limited only to touch events and handled in JavaScript by the Responder, Pressability, and PanResponder APIs.

Furthermore, we are continuing to explore including an implementation of the EventTarget interface for React Native host components (i.e. add/removeEventListener) which we believe will make possible more user-land abstractions for handling pointer interactions.

Trying it Out​

Our Pointer Events implementation is still experimental but we’re interested in getting feedback from the community on what we’ve shared. If you are interested in trying this API you’ll need to enable a couple feature flags:

Enable Feature Flags​

In your entry JavaScript file (index.js in the default React Native app template) you’ll need to enable the shouldEmitW3CPointerEvents flag for Pointer Events and shouldPressibilityUseW3CPointerEventsForHover to use Pointer Events in Pressability.

import ReactNativeFeatureFlags from 'react-native/Libraries/ReactNative/ReactNativeFeatureFlags';

// enable the JS-side of the w3c PointerEvent implementation
ReactNativeFeatureFlags.shouldEmitW3CPointerEvents = () => true;

// enable hover events in Pressibility to be backed by the PointerEvent implementation
ReactNativeFeatureFlags.shouldPressibilityUseW3CPointerEventsForHover =
  () => true;

iOS-specific​

In order to ensure that the pointer events are sent from the native iOS renderer you’ll need to flip a native feature flag in your native app’s initialization code (typically AppDelegate.mm).

#import <React/RCTConstants.h>

// ...

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    RCTSetDispatchW3CPointerEvents(YES);

    // ...
}

Note that to ensure that the Pointer Event implementation can distinguish between mouse and touch pointers on iOS you need to add UIApplicationSupportsIndirectInputEvents to your Xcode project’s info.plist.

Android-specific​

Similarly to iOS Android has a feature flag that you’ll need to enable in your app’s initialization — typically your onCreate for your root React activity or surface.

import com.facebook.react.config.ReactFeatureFlags;

//... somewhere in initialization

@Override
public void onCreate() {
    ReactFeatureFlags.dispatchPointerEvents = true;
}

JavaScript​

function onPointerOver(event) {
  console.log(
    'Over blue box offset: ',
    event.nativeEvent.offsetX,
    event.nativeEvent.offsetY,
  );
}

// ... in some component
<View
  onPointerOver={onPointerOver}
  style={{height: 100, width: 100, backgroundColor: 'blue'}}
/>;

Feedback Welcome​

Today Pointer Events are used by our VR platform and powering the Oculus Store, but we're also looking for early community feedback on both our approach and what we have for an implementation so far. We are excited to share our further progress with you and if you have questions or thoughts around this work, join us on the dedicated discussion on Pointer Events.

That’s why at the beginning of September, we gathered some of the active core contributors of React Native, library maintainers, and the Meta’s React Native and Metro teams to the Core Contributor Summit 2022. Callstack hosted the Summit in their HQ in Wrocław, Poland, as a part of the React Native EU conference happening at the same time.

Together with the React Native core team, we devised a series of workshops in which the attendees could participate. The topics were:

• ​​React Native Codegen & TypeScript Support
• ​​React Native New Architecture Library Migration
• ​​React Native Monorepo
• Metro Web and Ecosystem Alignment
• Metro Simplified Release Workflow

We were impressed by the amount of knowledge-sharing and collaboration over those two days. In this blog post, we’d like to give you a sneak peek of the results of this gathering.

React Native Codegen & TypeScript Support​

React Native’s Codegen is a fundamental part of the New Architecture of React Native. Supporting and improving it is among our top priorities for the future of React Native. For instance, earlier this year, we added support for generic code starting from TypeScript specs rather than Flow.

In this session, we took the opportunity to onboard new contributors to Codegen, by explaining its core concept and describing how it works. We then focused on two major areas:

1. Supporting new types that are currently unsupported by Codegen. One of the highly requested ones was the string union types in TypeScript.​

A team of a few people moved into a meeting room to tackle this task. They encountered and overcame some difficulties along the way, like how to run unit tests for Codegen. They spent quite some time understanding the code execution flow before starting to deal with the code. After some hours of collaborative work, they ended up with the first prototype that was able to recognize string unions. This experience was extremely useful in discussing design patterns and the ideal architecture we may want in the future.

2. Improving auto-linking for iOS, which was missing a use case.​

Specifically, auto-linking could not work well in scenarios where libraries and the app were living together in a monorepo. Android already supported this use case but it was missing for iOS.

Working with the contributors on Codegen helped us realize that it wasn’t trivial to work in its codebase. For example, adding the support for one type required to copy-and-paste the same code in four different places: modules with specs written in Flow, modules with specs written in TypeScript, components with specs written in Flow, and components with specs written in TypeScript.

This realization pushed us to create an umbrella task to reach out for help to the community in order to improve the status of the codebase toward a more maintainable one.

The participation was outstanding: we managed to quickly assign the first 40 tasks in 5 days. At the end of October, the community completed 47 tasks and many others are ready and waiting to be merged.

This initiative also contributed to the Hacktoberfest for all the people who contributed to these improvements!

​​React Native New Architecture Library Migration​

The hot topic in the React Native space is the New Architecture. Having libraries that support the New Architecture is a crucial point in the migration for the whole ecosystem. Therefore, we want to support library maintainers in migrating to the New Architectures.

Initially, this session started as a brainstorming, where the core contributors had the opportunity to ask the React Native team all the questions they had related to the New Architecture. This in-person feedback loop was crucial for both the core contributors to bring clarity and for the React Native team to collect feedback. Some of the shared feedback and concerns will end up being implemented in React Native 0.71.

We then moved to practically migrating as many libraries to the new architecture as possible. During this session, we kicked off the migration process for several community packages, such as react-native-document-picker, react-native-store-review, and react-native-orientation.

As a reminder, if you’re also migrating a library and need support in doing so, please reach out to our New Architecture Working Group on GitHub.

​​React Native Monorepo​

Releasing a new version of React Native is not trivial today. React Native is one of the most downloaded packages on NPM, and we want to make sure that our release process is smooth.

That’s why we want to refactor the react-native repository and implement the Monorepo RFC (#480).

In this session, we initially brainstormed and collected opinions from every contributor, as it’s crucial that we evolve our repository to reduce the breaking changes for our downstream dependencies.

We then started working on two fronts. First, we had to expand our Continuous Integration infrastructure to support our monorepo, adding Verdaccio to our testing infrastructure. We then started renaming & adding scopes to several of our packages, resulting in 6 distinct contributions.

You can track the status of this effort under this umbrella issue and we hope to share more on this effort in the near future.

Metro Web and Ecosystem Alignment​

Metro, our JavaScript Bundler, is a foundational and integrated part of the React Native development experience and we want to make sure it works with the latest standards in the JS ecosystem.

The focus of this session was to discuss improving Metro's feature set to work better for web use cases and with the npm and bundler ecosystem. Two major areas of discussion:

1. Adopting the "exports" (package entry points) specification​

From the Node.js documentation:

Adopting the "exports" specification has a lot of potential. In this session, we debated on how to handle Platform Specific Code with "exports". Considering many factors, we came up with a fairly non-breaking rollout plan for "exports", by adding a "strict" and "non-strict" mode to Metro resolver. We discussed how leveraging builder-bob would help library creators adopt the strict mode without friction.

This discussion resulted in:

1. An RFC for Metro on how package exports would work with React Native.
2. An RFC for Node.js to include “react-native” as a Community Condition.

2. Web and bundler ecosystem​

The Metro team shared progress from their partnership with Expo and the intent to continue this working model for upcoming bundle splitting and tree-shaking support. We touched again on ES module support and considered potential future features such as Yarn PnP and output optimization on the web. We discussed how Metro’s core shares logic and data structures with Jest and opportunities for more reuse.

Developers surfaced insightful use cases for bundle splitting and interoperability with third-party tooling. This led us to discuss potential extension points in Metro and improving current documentation.

This discussion provided us with good grounding for the next day's session on simplifying the release workflow.

Metro Simplified Release Workflow​

As mentioned, releasing React Native is not trivial.

Things get harder as we need to release React Native, the React Native CLI, and Metro. Those tools are connected to each other as React Native and the CLI both depend on Metro. This creates some friction when any of the packages releases a new version.

Currently, we manage this through direct communication and synchronized releases, but there is space for improvement.

In this session, we reconsidered the dependencies between React Native, Metro, and the CLI. We uncovered how some design decisions during the “Lean Core” effort, when we extracted the CLI from React Native, made these two projects codependent with some functionalities duplicated among efforts. The decisions back then made sense and allowed the CLI team to iterate faster than ever.

It was about time to revisit them and take the experience of both teams to figure out the way through. As a result, the Metro team will take over the @react-native-community/cli-plugin-metro development, temporarily moving it back to the core of React Native, and then most likely to the Metro monorepo.

The biggest takeaway, apart from three hours of drawing dependencies between the packages on the whiteboard, was for the CLI and Metro team to exchange their issues, experiences, and plans, resulting in a better understanding of each other.

We wouldn’t be able to achieve this level of cooperation without actually meeting each other.

We’re still impressed by how spending several hours together for a couple of days resulted in so much knowledge-sharing and cross-pollination of ideas. During this summit, we planted the seeds for initiatives that will help us improve and re-shape the React Native ecosystem.

We want to say thank you again to Callstack for hosting us and to all the participants for joining us at the Core Contributor Summit 2022.

If you’re interested in joining the development of React Native, make sure you join our open initiatives and read the contribution guide we have on our website. We hope to meet you in person as well in the future!

Sections​

• New Architecture’s New Documentation
• Hermes as default engine
• A new unified configuration for Codegen
• Android Auto-linking for New Architecture libraries
• Full CMake support for Android builds
• Highlights of 0.70

New Architecture’s New Documentation​

Over the last few months, we have been working to add more content to the New Architecture section of the documentation. In the new section you can find migration guides, examples and tutorials to get you up to speed.

Along with it, you can find new documents diving into Why a New Architecture and the various parts of it. We hope this helps you better understand the rationale behind the new APIs.

Any feedback is more than welcome, please let us know in the react-native-website repository.

Hermes as default engine​

React Native 0.70 is the first version with Hermes, our in-house JS engine, enabled by default.

This is the result of collaborative effort between the Hermes team and the React Native team, alongside with the priceless contributions from the community. We worked to improve and fine tune Hermes to make it more performant and deliver highly requested features by the community.

You can read more about it in the official announcement blogpost.

A new unified configuration for Codegen​

With 0.70, we introduced a unified way to define the Codegen specs for both iOS and Android. Previously, you had to put the Android configuration in a separate build.gradle file.

Now, you can define it directly in the package.json with:

  "codegenConfig": {
    "name": "CustomAnimationView",
    "type": "components",
    "jsSrcsDir": "./src",
    "android": {
      "javaPackageName": "com.custom.animation"
    }
  }

This improvement provides a more consistent experience for library maintainers in migrating their codebases to the New Architecture.

If you are a library maintainer, please make sure to let us know how the process is going for you in this discussion in the React Native New Architecture working group.

Android Auto-linking for New Architecture libraries​

With 0.70, users on New Architecture are able to automatically link libraries without any additional configuration on their Android.mk or CMake files.

Autolinking is a crucial part of the React Native development experience. It allows you to include external libraries with a yarn add command, without dealing with CocoaPods or Gradle setups.

The New Architecture required us to adapt the auto-linking features to support libraries which are using the Codegen and exposing native code to app developers.

While Autolinking worked well for New Architecture libraries on iOS, the same was not true for Android. With 0.70 we closed this gap and you can now keep on including libraries with yarn add to your project: they will be linked correctly on any architecture.

Full CMake support for Android builds​

Starting from 0.70, users can now use CMake to configure their Native builds. While we don’t expect app users to directly write C++ code, you still need an entry point for the native compilation.

From now on you can use a CMakeLists.txt file instead of an Android.mk file for anything Android/Native related in your project.

This change benefits both app and library users on the New Architecture as:

• The CMake file created in your app is way smaller (3 lines of code versus 50+ for Android.mk files). This makes for an easier update experience between React Native versions in the future and less code to maintain on your end.
• Codegen is now generating both Android.mk and CMakeLists.txt, so libraries should not worry about doing anything if they're using the default setup we provide for New Architecture libraries.
• The Auto-linking mentioned above will work with both CMake and Android.mk files out of the box.
• Despite apps being free to use either Android.mk or CMake files, the recommended solution in the future would be CMake files (due to better documentation, tooling and ecosystem around CMake).

Highlights of 0.70​

As mentioned above, some of the more important improvements in this release are centered around the New Architecture experience. However, there have been other notable changes, including:

• Fix for Catalyst is live, set mac_catalyst_enabled to true in Podfile (see upgrade-helper diff for details).
• Bumping metro to 0.72.0 which will enable the new React JSX Transform: reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html.
• Removing reactnativeutilsjni as it is built from the same sources as reactnativejni which results in ~220 KBs saved from every Android APK build. (https://github.com/facebook/react-native/pull/34339).

Breaking changes​

There have also been a few breaking changes:

• Removed jest/preprocessor from the react-native package (0301cb285b by @motiz88)
• Remove nonstandard Promise.prototype.done (018d5cf985 by @motiz88)

Please also note that the version of Metro has been bumped to 0.72, which comes with 5 breaking changes.

Upgrades​

And we upgraded some of our dependencies:

• Bump RN CLI to v9.0.0
• Bump Android Gradle Plugin to 7.2.1
• Bump Gradle to 7.5.1
• Bump RCT-Folly to 2021-07-22
• Bump Metro to 0.72
• Bump SoLoader to 0.10.4

You can check out the full list of changes in the changelog.

Acknowledgements​

88 contributors with their 493 commits have helped to make this release possible - thanks everyone! We are also thankful to everyone else who gave their feedback to ensure this release would be as stable as possible.

Hermes has provided a lot of value to React Native inside of Meta, and we believe the open-source community will benefit as well. Hermes is designed for resource constrained devices and optimizes for start up, app size, and memory consumption. One key difference between Hermes and other JS engines is its ability to compile JavaScript source code to bytecode ahead of time. This precompiled bytecode is bundled inside the binary, and saves the interpreter from having to perform this expensive step during app startup.

Since the announcement, a lot of work has gone into making Hermes better, and today, we are excited to share that React Native 0.70 will ship with Hermes as the default engine. This means that all new projects starting on v0.70 will have Hermes enabled by default. With the rollout coming up in July, we want to work closely with the community and make sure the transition is smooth and brings value to all users. This blogpost will go over what you can expect from the change, performance benchmarks, new features, and more. Note that you don’t need to wait for React Native 0.70 to start using Hermes - you can follow these instructions to enable Hermes on your existing React Native app.

Note that while Hermes will be enabled by default in new React Native projects, support for other engines will continue.

Benchmarking​

We measured three different metrics important to app developers: TTI, binary size, and memory consumption. We used the React Native app Mattermost for testing. We ran these experiments for both Android and iOS on high end hardware from 2020.

• TTI, or time to interactive, is the duration of time from the app being launched to the user being able to interact with it. For this benchmark, we define it as the time from pressing the app icon to the first screen being rendered. We also show screen recordings of starting up Mattermost.
• The binary size was measured as APK size on android and IPA size on iOS.
• The memory consumption data was collected by using the Mattermost app over the span of a couple minutes. The same actions were performed in the app on both engines.

Android Benchmarking Data​

All the android tests were performed on a Samsung Galaxy S20.

TTI Video​

iOS Benchmarking Data​

All the iOS tests were performed on an iPhone 12 Pro.

TTI Video​

Slowed Down TTI Video, to better show the difference in startup time.​

React Native/Hermes Integration​

We addressed a long-standing problem that has caused compatibility issues and is a recurrent problem when releasing new React Native versions: React Native depended on Hermes via prebuilt binaries distributed through CocoaPods and npm, which makes it possible to have API or ABI incompatibilities. To solve this problem, starting on React Native 0.69, Hermes is built alongside every version of React Native. This ensures full compatibility with each version React Native. This also creates a much tighter integration. It unlocks a more rapid iteration time to develop features or deploy bug fixes, and will give us greater confidence in making sure big changes to Hermes are done correctly. There is more in-depth information on the new integration change here.

iOS Intl​

We finished the iOS counterpart implementation for Intl, the ECMAScript Internationalization API that provides a broad range of language sensitive functionality. This was a long-standing gap that prevented some developers from using Hermes. The Android implementation, done in partnership with Microsoft, was shipped in React Native 0.65. With React Native 0.70, developers will have native support on both platforms.

Typical implementations for Intl require importing large lookup tables or data like Unicode CLDR. However, that can come with an expensive size increase of up to 6MB, so in order to avoid bloating the binary size of Hermes, we implemented Intl by calling into APIs exposed by iOS itself. This means we can take advantage of all the locale and internationalization data that comes with iOS already.

Ongoing Work​

As we continue evolving Hermes, we want to give the community a sense of our immediate priorities: improving developer experience and ensuring nobody avoids using Hermes due to lack of JavaScript language features. More specifically, we're:

• Enabling developers to run the sampling profiler directly from the Chrome devtools UI.
• Adding support for BigInt, a long-standing request from the community that may block some developers from using Hermes as it can’t be polyfilled.
• Adding support for WeakRef, which will expose new memory management controls to developers.

Wrap Up​

Hermes becoming the default marks the beginning of a long-term journey. We are working on new features that will enable the community to write efficient apps for many years to come. We also encourage the community to reach out on our GitHub Repo to post any bugs, questions, feedback or ideas! We have created a hermes label that can be used for any Hermes-specific posts.

Sections​

• React 18
• Bundled Hermes
• Highlights of 0.69

React 18​

We are delighted to share with you that React Native 0.69 is the first release to support React 18. React 18 has brought lots of improvements, like new hooks such as useId. Additionally, React 18 includes new concurrency features such as useTransition or full Suspense support.

On React Native 0.69, React 18 is enabled by default. However, if you have not migrated to the New Architecture, you will only be able to leverage the features that don't use concurrent rendering and concurrent features. The New Architecture has been built with concurrent rendering in mind but we cannot add that support for the old architecture.

You can learn more about the React 18 support in React Native here.

Bundled Hermes​

Before this release, Hermes and React Native were released separately. That led to confusion on which version of Hermes is compatible with which version of React Native. To remedy this issue, starting with React Native 0.69 we will be shipping a compatible version of Hermes alongside React Native. Making this change will make using Hermes in React Native much more stable.

Using the proper version of Hermes is handled by React Native, however, make sure to follow the steps in the upgrade helper to ensure the integration works as intended. If you don't have Hermes enabled already, you can follow the steps here to do so. While we will continue supporting other JavaScript engines, we recommend everyone to migrate to Hermes to have the best experience and to make sure we can support you better.

Note that users on the New Architecture on Android will need to build Hermes from source. For building Hermes from source, Windows users will need to additionally follow these steps.

If you are interested to learn more about how React Native bundles Hermes works under the hood, you can check out the deep-dive documentation here.

New Architecture​

We are continuing the roll-out of the New Architecture for both Android and iOS. If you have not migrated your app or library, yet, follow the steps here. You can also read the latest update on tools and resources for the New Architecture to learn more.

Highlights of 0.69​

As mentioned above, the most important improvements in this release are centered around React 18 support and bundled Hermes. However, there have been other notable changes, including:

• Deprecating support for iOS/tvOS SDK 11.0, version 12.4+ is now required
• Better support for M1 users developing for Android
• Addition of the new .xcode.env configuration file for more deterministically sourcing the node executable
• React Native now uses the latest status bar API from Android 11
• Support for C++17
• New hotkeysEnabled option in the iOS debug menu

Breaking changes​

There have also been a few breaking changes:

• React Native CLI has been bumped to a new major version of 8.0:
  • link and unlink commands have been removed in the favour of autolinking
  • Deprecated initCompat has been removed, use init command instead
  • Removed deprecated run-android properties
  • Removed install and uninstall commands
  • Removed assets and hooks from react-native.config.js – you'll need to remove these properties from your config
  • podspecPath was removed from the iOS dependency config
  • Removed --project-path option from a run-ios
  • Changed iOS source directory detection from looking for an Xcode project to looking for a Podfile
• Support for console.disableYellowBox has been dropped
• Already deprecated prop types have been removed (cdfddb4dad, 3e229f27bc, 10199b1581)
• removeListener, deprecated since RN 0.65, was removed from Appearance
• If you were using SegmentedComponentIOS, you will now need to replace it with the third-party library, for example segmented-control (235f168574)

Upgrades​

And we upgraded some of our dependencies:

• Bump of AGP to 7.1.1 - we recommend sticking to this version in your apps
• boost for Android was updated to 1.76 to align with iOS
• Ruby was bumped to 2.7.5
• Direct metro dependencies have been upgraded to 0.70.1

You can check out the full list of changes in the changelog.

Acknowledgements​

80 contributors with their 629 commits have helped to make this release possible - thanks everyone!

We are also thankful to the release testers, supporters, and everyone else who gave their feedback to ensure this release will be as stable as possible.

Introduction​

In this post we are sharing an update on tools and resources to help you migrate your Native Modules and Native Components to their New Architecture equivalents, TurboModule and Fabric Components.

React Native users leverage vast number of open source libraries for building apps. For a complete and consistent ecosystem, it is necessary that these libraries migrate such that everyone can benefit from the unlocked capabilities and performance improvements of the New Architecture.

Here is what we’re working on to support library developers in migrating to the New Architecture:

• Documentation: We are expanding the New Architecture guide on the website to cover more concepts of the New Architecture and how to develop your components.
• Example Migrations: We’ve set up two repositories to demonstrate how to migrate a React Native app to the New Architecture (RNNewArchitectureApp) and how to create a Fabric Component and a TurboModule that work with both architectures (RNNewArchitectureLibraries).
• Support: Earlier this year, we created a GitHub Working Group dedicated to discussion and questions around the New Architecture.

In this post, we will dig deeper into these resources and explain in more detail how you can use them most efficiently. Finally, we will provide a snapshot of the current migration state for the most used React Native libraries.

Documentation​

In the past 6 months, we’ve added a guide on adopting the New Architecture and an architecture deep-dive on Fabric. We plan to expand this to include more guides and documentation around creating TurboModules, understanding CodeGen, and more. We plan to have updates to share by the 0.70 release.

Currently, the New Architecture guide covers how to migrate your app and your libraries to support the New Architecture properly.

If you are interested in the evolution of this guide, or have feedback, you can follow along on this pull request.

Example Migrations​

For developers who may want to follow along in code, we’ve prepared two example repositories.

RNNewArchitectureApp​

This repo was created to demonstrate how to migrate an app, the native modules and the native components from the legacy architecture on the React Native version 0.67 to the New Architecture and the most recent version of React Native. Each commit corresponds to an isolated migration step.

The repo is organized as follows:

• A main branch has no code but a README.md which advertises other branches.
• Several migration branches which show a migration from a specific version of RN to another.

Some of the migration branches also have a RUN.md file which describes in a more human-readable fashion the exact steps that have been applied in every commit.

We plan to keep this example up to date with the most recent stable releases, adding migrations to any minor release of React Native we are going to release. If you notice issue with any of the steps, please file an issue in the repository. This will hold until we have the reasonable feeling that most of the React Native users have migrated to the New Architecture.

RNNewArchitectureLibraries​

Similarly, this repo provides a step-by-step guide on how to create a TurboModule and a Fabric Component. It has a focus on ensuring backward compatibility between the New Architecture and the legacy one.

The repository is organized in a similar way to the previous one:

• A main branch has no code but a README.md which advertises other branches.
• Other branches to show how to develop TurboModules and Fabric Components.

We plan to keep this example updated onto new releases of React Native, especially releases that affect library development, as well as add more examples on how to use advanced features (for example: implementing commands, event emitters, custom state). If you notice errors, please file an issue in the example repository.

Support​

We’ve created a dedicated working group to give the community space to ask questions and get updates on the New Architecture. If you are a library maintainer, this is a valuable resource to find answers to your questions, and for us to know about your requirements. To join, please follow these instructions. Everyone is welcome.

The working group is organized into several sections:

• Announcements: A place to share milestones and significant updates on the RN New Architecture Rollout
• Deep Dive: A place to chat about deep dives and technical-specific topics
• Documentation: A place to chat about the New Architecture documentation and migration material
• Libraries: A place to chat about 3rd party libraries and their migration story to the New Architecture
• Q&A: A place to ask the community for help on the New Architecture topics
• Releases: A place to chat about release specific bugs & build problems

To use this group effectively:

• Make sure your library is listed inside the Libraries section. This will help us share a status update on the migration of your library and will help us understand which struggles library authors are facing to support you better.
• Leverage the Q&A section if you face a blocker and need support. Our team and community experts are monitoring and will support at our best effort.
• Keep an eye on the other sections for topics that may affect you. A new release may introduce exactly the API that you were looking for. You can subscribe to particular discussions via GitHub.

We plan to support this group until the New Architecture is enabled by default and all the major libraries have been migrated to it.

Migration Status of Popular Libraries​

Libraries maintainers have been sharing with us in the working group the status of their migration effort, and we wanted to provide you with a quick overview:

• react-native-gesture-handler: ✅ Migrated
• react-native-navigation: 🏃‍♂️ Ongoing
• react-native-pager-view: 🏃‍♂️ Ongoing
• react-native-reanimated: ✅ Migrated. In the process of testing and profiling for performances
• react-native-screens: 🏃‍♂️ Ongoing
• react-native-slider: 🎬 Started
• react-native-template-new-architecture: ✅ Migrated. Gradually adopting/testing more companion Libraries
• react-native-template-typescript: ✅ Migrated
• react-native-webview: 🎬 Started

Next Steps​

We are invested in supporting the React Native community’s adoption of the New Architecture. Concretely, we will continue to:

• Offer best-effort support in the Working Group.
• Provide more examples about how to achieve amazing results with the New Architecture in the RNNewArchitecture repositories.
• Provide clear and up-to-date documentation on the New Architecture.
• Track the migration status of essential React Native libraries in the Working Group.
• Simplify the migration path for developers

In addition, React Native 0.69 will ship with improved devX for app and library developers for New Architecture adoption. You can find more information about the 0.69.0 release here.

We are excited about what we will build together with the New Architecture!

“We hope this pledge makes it easier for developers using React Native to create fully accessible mobile apps and inspires other organizations to make similar commitments to a more accessible future.”

— Mike Shebanek, head of accessibility Meta, 2020

The process initially began with a thorough review and gap analysis of the framework focused on React Native utilized the iOS and Android APIs to support accessibility features. Dozens of issues have since been fixed or closed out, making good on the pledge to make React Native accessible and advancing the accessibility of the framework ever forward.

We didn’t stop there, and in early 2022, we reviewed and prioritized the remaining issues from this gap analysis on the Improved React Native Accessibility Board based on their impact on developers and end users.

Fixes that have already landed in 2022​

• Android: Disabled state not announced/disabled functionality not applied for some components
• Android: Position in collection not supported by some components
• Android: Make links independently focusable by Talkback

Fixes currently in progress​

• iOS/Android: Text input error announcement
• Android: Form field error state announcement
• Android: Role description is announced before the components text, rather than after

Contributor highlight​

We want to recognize and send a tremendous thank you to Fabrizo Bertoglio who has contributed several high-quality accessibility fixes to React Native in 2021 and 2022.

Fabrizio has made it a personal goal to enable users through high quality solutions. By learning how to use TalkBack and VoiceOver himself, he has discovered how difficult it can be for screen reader users to experience everyday applications. He wants to build software that removes friction from these experiences and please disabled users.

His pull requests have been very high quality, well documented, and include thorough test cases. Well done Fabrizio! The React Native Accessibility community thanks you for your many outstanding contributions.

What’s next in 2022​

Our goal is to fix as many of the remaining accessibility issues as possible in 2022. We will also be reviewing the backlog of React Native community reported issues to look for any new accessibility-related requests.

Sections​

• Highlights of 0.68
• Opting in to the New Architecture
• Website updates
• Interested in helping React Native stabilise new releases?

Highlights of 0.68​

Andrei Calazans helped us selecting the most relevant changes that 0.68 brings along:

Breaking changes and version bumps​

This version brings along a few breaking changes:

• React Native has been updated to Node 16, the latest LTS. Since on CI we test for LTS and the previous LTS, this change means that users are now required to use a version of Node >= 14.
• Android Gradle Plugin was updated to 7.0.1, enforcing JDK 11 for Android builds, so make sure to upgrade your configurations (we recommend you use the zulu11 JDK flavor for both Intel and M1 Macs)
• Removed fallbackResource from RCTBundleURLProvider API on iOS. This parameter can be safely removed from the method call without replacement.

Tooling has also been updated - here are the main bumps:

• @react-native-community/cli to 7.0.3
• Metro to 0.67
• react-devtools-core dependency to 4.23.0
• Flipper to 0.125.0
• react-native-codegen to 0.0.9
• Kotlin to 1.6.10
• Soloader to 0.10.3
• Gradle to 7.3
• Android compile and target SDK to 31

Also, thanks to this commit by Nicola Corti the Android Gradle Plugin will download the default version of NDK by itself, so you don’t have to specify and install it separately anymore.

Other improvements​

There are a lot of other changes and fixes landed in this release, but here’s a small selection that you might be interested in:

• Gijs Weterings fixed Forwarding testID to RCTModalHostView for easier E2E targeting of Modals.
• Liam Jones fixed an issue where calling console.error caused the RedBox to appear alongside the LogBox.
• Sam Kline fixed the empty blank screen after a BundleDownloader failure in dev mode on Android.
• Jeffrey Hyer fixed an issue where the KeyboardAvoidingView didn't work as expected with the onLayout prop.

If you are interested in the full list of changes, you can read it in the changelog at the link here.

Acknowledgements​

This release includes 614 commits by 68 contributors! Thank you all!

We wanted to also thank the release testers and supporters who helped us catch regressions before the stable 0.68.0 release: you are incredibly valuable to the success of this release!

If you, your app or your company is interested in joining the “Release Tester” program, you can sign up here.

Opting in to the New Architecture​

As briefly mentioned above, React Native 0.68 is the first version with opt-in support for the Fabric Renderer and the TurboModule system. This marks a crucial milestone for the rollout of the New React Native Architecture. To help you get up to speed with the changes, we added the Architecture section to the website, where you can find several in-depth guides about internals of the new systems.

At the same time, we added the migration guide to the documentation and launched a working group dedicated to the New Architecture. You can find more information, including how to opt in, in the previous blog post.

Please note that the New Architecture still needs some fine tuning. Some of the third-party libraries that you depend on might not be migrated yet, and you may encounter issues that we haven’t discovered yet. If you do so, please report them to our New Architecture Working Group.

About React 18: React 18's new rendering engine is not supported by React Native 0.68, this will happen in a future version. This is because React 18 relies on the New Architecture to benefit from the new capabilities presented in the React 18 announcement blog post. For more information, see the React Conf keynote here.

Website updates​

Along with improvements to the main codebase, with the help of Simek, Megatron4537 and slorber there have been quite a few improvements landing on the website too! In particular, you will now be able to learn how to contribute to React Native via the new section in the top toolbar. Moreover, the “Contributing” section and the new “Architecture” section are now unversioned — there is now only one copy of these sections, rather than one for each React Native version.

2022 is going to be the year of the New Architecture in open source

If you still haven’t had the time to look into the New React Native Architecture (the Fabric Renderer and the TurboModule system), there is no better time to do it than now!

We would like to share with the community some initiatives and material we prepared to make sure everyone is onboard on this endeavor.

The Working Group​

Recently, we launched the React Native New Architecture Working Group on GitHub, a discussion only repository to coordinate and support the rollout of the New Architecture across the ecosystem.

We envision this working group as a space where the community can meet, share ideas, and discuss challenges during the adoption of the New Architecture. Moreover, we're going to use this working group to share information and updates with the wider community for the sake of transparency.

To keep the discussion focused, we decided to have this working group open to read publicly and restricted to write only for approved users.

If you wish to join the conversation, you can fill in this form to either apply or nominate someone that you think would be a valuable addition to the discussion.

Everyone is welcome to apply to join the conversation.

As every discussion forum, we would like to stress once more the importance of being respectful and welcoming towards others’ opinions. Please take the chance to read our code of conduct if you haven’t yet done it.

The Migration Guide​

After several rounds of review & feedback, we finally merged the Migration Guide (f.k.a. the Playbook). You can find it on the website in the Guides section.

This Migration Guide will show you how to create a custom Fabric component or a TurboModule with a step-by-step approach. The guide will also show you how to adapt your existing app or library to use the New Architecture.

Moreover, we would like to remind you the brand-new Architecture section of our website. There you can find several in-depth articles and explanation of the React Native internals. Specifically, the Fabric section can help you understand the rendering pipeline in the New Architecture world.

Finally, please consider sharing your feedback to this documentation material on the working group. We’re constantly looking for developer’s opinion, and we want to make sure we’re delivering the content that you find most useful.

Over the next months, we will look into refining and adding more documentation to help you further.

The New Architecture Template​

React Native 0.68.0 is close to release. This version of React Native marks a crucial milestone in the New Architecture Rollout as it’s the first version to include an opt-in switch in the new app template.

This means that you will be able to try the New Architecture by changing one line in the template. We also added extensive comments and documentation to the template to make sure you don’t need extra reading to use it out of the box. We hope this will help you adopt the New Architecture by reducing the amount of code your have to write.

In the next releases, we will keep on updating the template to make it even more streamlined and simple to use.

To enable the New Architecture on either platform, you can:

• On iOS, run RCT_NEW_ARCH_ENABLED=1 bundle exec pod install inside the ios folder.
• On Android, set the newArchEnabled property to true by either:
  • Changing the corresponding line inside the android/gradle.properties file.
  • Set an environment variable ORG_GRADLE_PROJECT_newArchEnabled=true
  • Invoke Gradle with -PnewArchEnabled=true

Then you can run your app with yarn react-native run-android or run-ios and you’ll be running using Fabric and TurboModules enabled.

Please consider trying this new template, and report any bug or unexpected behavior that you might face. Over the last months we worked hard to fix bugs and build failures that would have been hard to catch without the constant community feedback and testing.

The 3rd-party Libraries Ecosystem​

The community won't be able to migrate to the New Architecture without the full support of 3rd-party libraries author & maintainers.

We understand how this can be a tedious process, and we understand the importance of supporting users on both old and New Architecture. Over the next months, we will focus on supporting our library developers to help them migrate over.

If you’re a library developer, we invite you to post an update in the New Architecture working group with the status of your libraries. This will help you attract early adopters and us to understand if any library is facing a blocker.

If instead you’re a library user, you can post a message here to request a migration of a library. If we identify a library that becomes a blocker for a number of users, we will try to reach out to the maintainer and understand why they haven’t migrated yet.

Finally, we would like to give a shout out to Software Mansion for releasing a new version of react-native-screens, which has support for both architectures. Moreover, they published a blog-post (Introducing Fabric to react-native-screens) where they tell their migration story. We hope you will find this story inspiring and useful to tackle your migration.

Releases​

Work on the 0.68 pre-release has realized much of the improved release process we had defined last half.

We’re happy to share that with 0.68 we were able to:

• Successfully onboard release work to an internal rotation. Much of this is supported by improved documentation on the release process which will reduce the bus factor of the release process.
• Initiated discussions with partners to support a Copilot rotation. We hope this effort will improve transparency of the process and inform our partners where to invest to support React Native releases and eco-system.
• Onboarded several Release Supporters and Testers from the community. We had put a call-out for help last half and so many folks stepped up! The feedback from our testers and supporters have helped us fix crucial bugs and regressions, especially around the new architecture, for the upcoming release. Thank you to everyone who signed up and tested out the release!

With React Native 0.69 we will continue refining this process, ideally getting partners to provide earlier release signal and onboarding co-pilots. As always, any feedback is more than welcome. If you’d like to join as a release tester or supporter, please sign up here.

Towards Hermes as Default engine​

One of the crucial point of the New Architecture Rollout is the adoption of the new JavaScript engine: Hermes.

With the New React Native Architecture, we’re going to set Hermes as default engine. This means that all the new documentation and templates will have Hermes enabled.

Please note that we'll continue working with the community to make sure other engines, such as JSC (JavaScript Core), are supported. You can still use the engine you wish, but you’ll have to explicitly disable Hermes.

To improve the stability of Hermes, we’re working towards changing the distribution model of Hermes. Specifically, we envision the Hermes release process to be closer to the React Native release process.

This will allow us to ship a version of React Native, with a bundled JS engine that is fully compatible. You won’t have to deal with run-time crashes and Hermes incompatibilities that are really hard to debug and understand.

Moreover, this will shorten the cycle for picking up improvements and bug fixes in Hermes, which will allow us to be more responsive to the needs of React Native users.

We will be sharing more on this matter in the coming months. In the meanwhile, feel free to join the discussion about it on the Working Group.

If you haven’t tried Hermes yet, now is the time to give it a go. And please make sure to flag any issues or blockers you might face.

With this, that’s a wrap.

I’d like to thank Andrei, Aleksandar, Dmitry, Eli, Luna, Héctor & Neil for reviewing this blog-post and providing valuable contributions to those efforts.

And looking forward to reading your migration stories.

Specifically, H2 2021 was an exciting half for both us and the community where we had the opportunity to invest more in our open-source ecosystem. We revamped some of our processes and created new ones from scratch that will help you, us, and the community to enjoy a better React Native experience.

Repository Health​

In H2 2021, we invested in tackling some of the OSS debt that our repository built up over the years. Specifically, most of our focus was around pull requests. We built an internal process to make sure all the new pull requests are addressed in a timely manner.

Although this is not a complete list, we would like to highlight some impactful PRs we received from our contributors:

• Accessibility
  • #31630 Added Support for Entrance/exit from collection by Flatlist by @anaskhraza
• Crash
  • #29452 Fix - TextInput Drawable to avoid Null Pointer Exception RuntimeError by @fabriziobertoglio1987
• Display
  • #31777 fix: TouchableNativeFeedback ripple starts on previous touch location by @intergalacticspacehighway
  • #31789 Fix support for blobs larger than 64 KB on Android by @tomekzaw
  • #31007 Fix selectionColor doesn't style Android TextInput selection handles by @fabriziobertoglio1987
  • #32398 Fix Android border positioning regression by @oblador
  • #29099 [Android] Allows to set individual (left,top,right,bottom) dotted/dashed by @fabriziobertoglio1987
  • #29117 [Android] Fix font weight numeric values by @fabriziobertoglio1987
• Interaction
  • #28995 [Android] Fix TextInput Cursor jumping to the right when placeholder null by @fabriziobertoglio1987
  • #28952 [Android] Fix non selectable Text in FlatList by @fabriziobertoglio1987
  • #29046 [Android] onKeyPress event not fired with numeric keys by @fabriziobertoglio1987
  • #31500 fix#29319 - ios dismiss modal by @intergalacticspacehighway
  • #32179 Fix: multiline textinput start "jerking" when trying to move cursor. by @xiankuncheng
  • #29039 Fix to make taps on views outside parent bounds work on Android by @hsource
• Performance
  • #31764 Optimize font handling on iOS by @Adlai-Holler
  • #32536 Don't reconstruct app component on split-screen by @Somena1
• Testing
  • #31401 Add unit tests for VirtualizedList render quirks by @NickGerleman

Some of those PRs addressed issues that were impacting both Meta and the overall OSS community, given the number of reactions on the corresponding issue they closed.

There are so many more PRs we would like to call out, and we want to thank again all the people that are spending their time to help us address bugs and improve React Native.

Community Engagement​

At the beginning of the half we set a goal to communicate with our community more and set process for the behavior to continue. Here were some of our engagements in H2 2021:

• We had the opportunity to participate in React Native EU with a talk from Joshua Gross - Bringing the Fabric renderer to the “Facebook” app
• We hosted an “Ask Us Anything“ (AUA) on Reddit and received over 100 questions! AUAs are a great opportunity for both us, to get a sense of the community engagement, and you all, to ask any kind of questions. If you haven’t yet, make sure you check the answers as some of them are extremely insightful
• We shared our Many Platform Vision, a guide for gotchas for Android 12 and iOS 15, and the progress and vision for Hermes to become the default JS engine for React Native!
• Our own Kevin Gozali appeared on an episode of React Native Radio podcast to talk about the new architecture.
• At ReactConf 2021, ReactConf Rick Hanlon shared the unified many-platform vision for React and React Native. Moreover, Eric Rozell and Steven Moyes got to share the amazing progress React Native Desktop has made in supporting both Meta and Microsoft apps and showcasing the Many Platform Vision in practice.

Beyond sharing more updates in H2 2021, we also leaned on our community more than ever. We relied on critical feedback from contributors as they dogfooded early drafts of the New Architecture material. As well, we were heavily supported by the expertise of our community in debugging critical release issues and improvements.

There is a wealth of knowledge that our community brings into React Native, and we need to continue to nurture it.

The New Architecture Rollout and Releases​

2022 is going to be the year of the New Architecture in open source.

We’ve been working hard to deliver the infrastructure needed to rollout the New Architecture to apps and libraries. We involved some of our partners and core contributors/library maintainers to refine our support for the new architecture to get early stage feedback.

We are now preparing to release a new guide on our website: Getting Started with the New Architecture. That will be the entry point to a collection of material that we’re going to release in 2022 and will help you migrate/start your project with the new architecture.

Moreover, we would like to stress the importance of giving feedback on the New Architecture material. We’re still in the process of finalizing the last details and your input will help everyone adopt the new architecture more seamlessly.

Releases play a critical role in the New Architecture rollout. Our goal last half was to ensure any release blocking issues did not stagnate. We approached the problem by clarifying and improving process and responsibilities for better accountability. Our release coordination now occurs in a dedicated discussions repository with clearer release issue reporting.

In H1 2022, we will continue to iterate on release responsibilities to support new architecture rollout. If you’d like to help out testing release candidates or working on improvements, feel free to join the discussion!

To Mobile and beyond​

As you can see from the ReactConf talk lineup, React Native is not only Android & iOS.

Earlier in 2021, we shared our Many Platform Vision, and we had a successful time rolling out React Native on both Desktop and VR.

We’re looking forward to converging patterns that are platform-specific into the React Native experience.

Finally, we want to thank again the community for the enormous support in H2 2021. It’s always amazing to see how contributors come together and support each other on GitHub, fixing bugs, sharing their and helping us deliver React Native to millions of users.

Stay tuned and looking forward to an even more amazing 2022 🎉!

Sections​

• Highlights of 0.67
• Improvements to Release Process
• Interested in helping React Native stabilise new releases?

Highlights of 0.67​

As mentioned in Meta's H2 2021 plans, React Native is attempting more frequent releases for a shorter turnaround time for new features and fixes (like the new architecture) to land in the community. Naturally, many releases will focus on fixes and improvements.

Here are some notable changes coming in 0.67.0:

• Lean-core removals: DatePickerAndroid
• Bump Gradle version to 7.2, Bump Kotlin version to 1.5.31 Bump Kotlin and Gradle versions (#32319)
• A notable callout: 0.67 continues to depend on Hermes 0.9.0, unchanged from 0.66

You can find the full changelog here.

You can participate in the conversation on the status of this release at this discussion - and, as always, to help you upgrade to this version, you can use the upgrade helper ⚛️

Acknowledgements​

This release includes 379 commits with 74 contributors! Thank you, to all our contributors (old and new)! You can find the full changelog here.

We wanted to also thank the release testers who helped us make sure that 0.67.0 could reach your codebases without any massive regression. Specifically, we wanted to thank:

• Marc Rousavy (@mrousavy) from Margelo, that surfaced a regression for Hermes 0.10 (that would have never been caught on CI testing) which will be fixed in Hermes 0.11 in the 0.68 release of React Native.
• The Reanimated team for quickly preparing a 0.67 compatible version of their lib early in the 0.67 RC phase.
• Elias Nahum (@enahum) from Mattermost
• Mike Hardy (@mikeHardy) working with Invertase

We appreciate also Rainbow, Comm and Ledger Live for also being part of the pilot of the "Release Tester" program (more details below).

Improvements to Release Process​

As mentioned, React Native has been restructuring the release pipeline to allow for more frequent releases such that new features and fixes can roll out faster to the community.

Over the last few months we tackled some issues that delay releases.

Coordination and Knowledge Sharing​

We invested in our documentation of releases to cover how to run a release, FAQs, coordination of release issues, etc – all of which can be found in this section of the react-native wiki. By documentation, releases are no longer blocked on any individual or tribal knowledge.

In addition to documentation, we have also revamped the coordination of releases and have moved discussion of pre-release status and patches to a dedicated discussion group: react-wg/react-native-releases.

Clarity of responsibility​

Following more documentation, release work can scale such that no one person is critical to running a release.

A React Native release is susceptible to a broad spectrum of potential points of failure and has a lot of dependencies and follow-up. Considering that usage of React Native varies across the community, it’s essential to have stakeholders involved in releases. We have defined a set of roles and responsibilities in supporting a release.

Release candidate signal​

Another issue with releases is getting a good signal that a release will not suffer from build regressions. This can be addressed with growing investment in testing build variants, etc. but signal from adoption will continue to be useful for some time.

In the 0.67 release we piloted a “Release Tester” program where React Native developers working on Open Source apps commit to testing release candidates on their apps. Prior, there was no formal expectation that the community will test out release candidates to raise any potential issues. This program helps us get faster signal to ensure a level of stability of the release.

Open source React Native apps are particularly useful due to availability of source code to help debug any regressions. With this program in place, a release tester surfaced a regression in 0.67 and we were able to resolve it without thrashing the larger community with a faulty release.

Interested in helping React Native stabilise new releases?​

A great way to help us catch regressions is to integrate the React Native pre-release version react-native@next or react-native@nightly to your CI. For any regressions, you can file a release issue and notify the appropriate discussion.

If your app or company is interested in joining the “Release Tester” program, head to the dedicated section at the bottom of the Release Roles and Responsibilities wiki to learn more.

Lastly any help on trying our release candidates or helping unblock release issues is much appreciated!

Optimizing for React Native​

Hermes’s defining feature is how it performs compilation work ahead-of-time, meaning that React Native apps with Hermes enabled ship with precompiled optimized bytecode instead of plain JavaScript source. This drastically reduces the amount of work needed to start up your product for users. Measurements from both Facebook and community apps have suggested that enabling Hermes often cut a product’s TTI (or Time-To-Interactive) metric by nearly half.

That being said, we’ve been working on improving Hermes in many other aspects to make it even better as a JavaScript engine specialized for React Native.

Building a New Garbage Collector for Fabric​

With the upcoming Fabric renderer in the new React Native architecture, it will be possible to synchronously call JavaScript on the UI thread. However, this means if the JavaScript thread takes too long to execute, it can cause noticeable UI frame drops and block user inputs. The concurrent rendering enabled by React Fiber will avoid scheduling long JavaScript tasks by splitting rendering work into chunks. However, there is another common source of latency from the JavaScript thread — when the JavaScript engine has to “stop the world” to perform a garbage collection (GC).

The previous default garbage collector in Hermes, GenGC, was a single-threaded generational garbage collector. The new generations uses a typical semi-space copying strategy, and the old generations uses a mark-compact strategy to make it really good at aggressively returning memory to the operating system. Due to its single-thread, GenGC has the downside of causing long GC pauses. On apps that are as complicated as Facebook for Android, we observed an average pause of 200ms, or 1.4s at p99. We have even seen it be as long as 7 seconds, considering the large and diverse user base of Facebook for Android.

In order to mitigate this, we implemented a brand new mostly concurrent GC named Hades. Hades collects its young generation exactly the same as GenGC, but it manages its old generation with a snapshot-at-the-beginning style mark-sweep collector. which can significantly reduce GC pause time by performing most of its work in a background thread without blocking the engine’s main thread from executing JavaScript code. Our statistics show that Hades only pauses for 48ms at p99.9 on 64-bit devices (34x faster than GenGC!) and around 88ms at p99.9 on 32-bit devices (where it operates as a single-threaded incremental GC). These pause time improvements can come at the cost of overall throughput, due to the need for more expensive write barriers, slower freelist based allocation (as opposed to a bump pointer allocator), and increased heap fragmentation. We think those are the right trade-offs, and we were able to achieve overall lower memory consumption via coalescing and additional memory optimizations that we’ll talk about.

Striking on Performance Pain Points​

Startup time of applications is critical to the success of many apps, and we are continuously pushing the boundary for React Native. For any new JavaScript feature we implement in Hermes, we carefully monitor their impact on production performance and ensure that they don’t regress metrics. At Facebook, we are currently experimenting with a dedicated Babel transform profile for Hermes in Metro to replace a dozen Babel transforms with Hermes’s native ESNext implementations. We were able to observe 18-25% TTI improvements on many surfaces and overall bytecode size decreases and we expect to see similar results for OSS.

In addition to startup performance, we identified memory footprint as an opportunity for improvement in React Native apps especially for virtual reality. Thanks to the low-level control we have as a JavaScript engine, we were able to deliver rounds of memory optimizations by squeezing bits and bytes out:

1. Previously, all JavaScript values were represented as 64-bit NaN-boxing encoded tagged values to represent floating point doubles and pointers on 64-bit architecture. However, this is wasteful in practice because most numbers are small integers (SMI) and JavaScript heap of client-side applications is not expected to be larger than 4GiB generally. To address this, we introduced a new 32-bit encoding in which SMI and pointers are encoded in 29 bits (because pointers are 8-byte aligned, we can assume the bottom 3 bits are always zero), and the rest of JS numbers are boxed onto the heap. This reduced the JavaScript heap size by ~30%.
2. Different kinds of JavaScript objects are represented as different kinds of GC-managed cells in the JavaScript heap. By aggressively optimizing the memory layout of headers for those cells, we are able to reduce memory usage by another ~15%.

One of our key decisions with Hermes was to not implement a just-in-time (JIT) compiler because we believe that for most React Native apps, the additional warm-up costs and extra footprints on binary and memory would not actually be worthwhile. For years, we invested a lot of effort in optimizing interpreter performance and compiler optimizations to make Hermes’s throughput competitive with other engines for React Native workloads. We are continuing to focus on improving throughput by identifying performance bottlenecks from everywhere (interpreter dispatch loop, stack layout, object model, GC, etc.). Expect some more numbers in upcoming releases!

Pioneering at Vertical Integrations​

At Facebook, we prefer to colocate projects within a large monorepo. By having the engine (Hermes) and the host (React Native) closely iterating together, we opened a lot of room for vertical integrations. To name a few:

• Hermes supports on-device JavaScript debugging with the Chrome debugger by speaking the Chrome DevTools Protocol. It’s better than the legacy “Remote JS Debugging” (which uses an in-app proxy to run JS in desktop Chrome) because it supports debugging synchronous native calls and guaranteed a consistent runtime environment. Together with React DevTools, Metro, Inspector, and so on, Hermes debugger is now part of Flipper to provide a one-stop developer experience.
• Objects allocated during the initialization path of React Native apps are often long-lived and don’t follow the generational hypothesis leveraged by generational GCs. Therefore, we configured Hermes in React Native to allocate the first 32MiB directly into old generations (known as pre-tenuring) to avoid triggering GC pauses and delaying TTI.
• The new React Native architecture is heavily based on JSI (or JavaScript Interface), a lightweight, general-purposed API for embedding a JavaScript engine into a C++ program. By having the team maintaining the JS engine also maintains the JSI API implementation, we are confident in providing the best possible integration that is reliable, performant and battle-tested at the Facebook’s scale.
• Getting JavaScript concurrency primitives (e.g. promises) and platform concurrency primitives (e.g. microtasks) both semantically correct and performant are critical to React concurrent rendering and the future of React Native apps. Historically, promises in React Native were polyfilled using non-standardized setImmediate APIs. We are working on making native promises and microtasks from JS engines available via JSI, and introducing queueMicrotask, a recent addition to the web standard, to the platform, to better support modern asynchronous JavaScript code.

Bringing Along the Whole Community​

Hermes has been really great for us at Facebook. But our work is not done until our community can use Hermes to power experiences throughout the ecosystem, so that everyone leverage all of its features and to embrace its full potential.

Expanding to New Platforms​

Hermes was initially open sourced only for React Native on Android. Since then, we have been thrilled to see our members of the community expanding Hermes support into many other platforms that React Native’s ecosystem has expanded.

Callstack led the effort of bringing Hermes to iOS in React Native 0.64. They wrote a series of articles and hosted a podcast on how they achieved it. According to their benchmarks, Hermes was able to consistently deliver ~40% improvement to startup and ~18% reduced memory on iOS compared to JSC for the Mattermost app, with only 2.4 MiB of app size overhead. I encourage you to see it live with your own eyes.

Microsoft has been bringing Hermes to React Native for Windows and macOS. At Microsoft Build 2020, Microsoft shared that Hermes’s memory impact (working set) is 13% lower than the Chakra engine on React Native for Windows. Recently, on some synthetic benchmarks, they’ve found Hermes 0.8 (shipped with Hades and aforementioned SMI and pointer compression optimization) uses 30%-40% less memory than other engines. Not surprisingly, the desktop Messenger video calling experience built on React Native, is also powered by Hermes.

Last but not least, Hermes has also been powering all virtual reality experiences built with the React family of technologies on Oculus, including Oculus Home.

Supporting our Community​

We acknowledge there are still blockers that prevent parts of the community from adopting Hermes and we are committed to building support for these missing features. Our goal is to be fully featured so that Hermes is the right choice for most React Native apps. Here is how the community has already shaped the Hermes roadmap:

• Proxy and Reflect were originally excluded from Hermes because Facebook does not use them. We were also concerned that adding Proxy would hurt property lookup performance even when Proxy is not used. But Proxy quickly become the most requested feature of Hermes due to popular libraries such as MobX and Immer. We carefully evaluated and decided to build it just for the community, and we managed to implement it with very low cost. Since this is a feature we don’t use, we relied on our community to prove its stability. We started by testing Proxy behind a flag and created opt-in npm packages for release v0.4 and v0.5, and it’s enabled by default starting from v0.7.
• ECMAScript Internationalization API Specification (ECMA-402, or Intl) was the second most requested feature. Intl is a huge set of APIs and often requires the implementation to include 6MB worth of Unicode CLDR data. This is why polyfills like FormatJS (a.k.a. react-intl) and JS engines like the international variant build of community JSC are so huge. To avoid substantially increasing the binary size of Hermes, we decided to implement it with another strategy by consuming and mapping the ICU facilities provided by the libraries included in the operating systems, at the cost of some (often minor) variance in behaviors across platforms.
  • Microsoft collaborated to build support on Android. It covers almost everything from ECMA-402 up to ES2020, with only a size impact as small as 3% (57-62K per ABI). We ran a poll on Twitter and the results were strongly in favor of including Intl by default, so that’s what we did and it’s available starting from release v0.8.
  • Facebook has sponsored Major League Hacking to launch a remote open source fellowship program. Last year, we launched the Hermes sampling profiler. This year, our fellows will be working with members from Hermes, React Native, and Callstack, to add support for Hermes Intl on iOS. Stayed tuned!
• We appreciate that people have been working with us to discover issues affecting the community.
  • People have helped us identify critical spec divergence such as stability of Array.prototype.sort amended in ES2019. This has been fixed and will be available in the next release.
  • People found out that our default heap size limit was too small and caused unnecessary GC pressure and OOM crashes for many users who are not familiar with customizing Hermes’s GC configs. So we increased it from 512MiB to 3GiB to be more than sufficient for most users by default.
  • People also reported that our specialized Function.prototype.toString implementation caused performance to drop in libraries doing improper feature detection and blocked users from doing source code injecting. This helped us strengthen our stance that Hermes, whenever possible, should not get in the way of developers and to respect de-facto practices.

Summary​

In summary, our vision is to make Hermes ready to be the default JavaScript engine across all React Native platforms. We’ve already started working towards it, and we want to hear from all of you about this direction.

It’s extremely important for us to prepare the ecosystem for a smooth adoption. We encourage you to try out Hermes, and file issues on our GitHub repository for any feedbacks, questions, feature requests and incompatibilities.

Thanks​

We’d love to thank the Hermes team, the React Native team, and the many contributors from the React Native community for their work to improve Hermes.

I’d also love to personally thank (in alphabetic order) Eli White, Luna Wei, Neil Dhar, Tim Yung, Tzvetan Mikov, and many others for their help during the writing.

Highlights​

• Handle taps on views outside parent bounds on Android
• New Bluetooth Permissions on Android
• Better Support for Apple Silicon, Xcode 13, and iOS 15
• Hermes 0.9.0
• Nightly and “Commitly” Releases

Handle taps on child views outside parent boundaries on Android​

Thanks to @hsource for adding interaction support for children rendered outside of parent view boundaries via overflow: visible. This is a common use-case and aligns React Native on Android more closely with web standards.

Find more details on the pull request.

New Bluetooth Permissions on Android​

We’ve added support for new Bluetooth permissions in preparation for Android 12 and we plan to update the targetSDKVersion to 31 in the next release.

Better Support for Apple Silicon, Xcode 13, and iOS 15​

This release provides a number of solutions to make Xcode builds for iOS on Apple Silicon (M1) Mac machines more reliable.

Notably, the new app template now includes a CocoaPods workaround (thanks to @mikehardy!). To apply, make sure your app’s Podfile has __apply_Xcode_12_5_M1_post_install_workaround(installer) added in the post_install step.

In addition RCT-Folly.podspec has been updated to prevent arm64 linker failure.

Check out this post we shared on preparing your app for iOS 15 and Android 12.

Hermes 0.9.0​

Hermes 0.9.0 is primarily about closing the gap between Hermes release cut point and this React Native release.

Among ~400 commits, there have been general bug fixes alongside memory and size wins.

See Hermes 0.9.0 release issue for more details

Nightly and “Commitly” Releases​

In a recent blog post we shared that one of our goals in the second half of 2021 is to improve our release process to be faster and more stable. As part of this effort we are working to make React Native more stable on main and to reduce the bugs identified during our Release Candidate process.

While we have been publishing nightly releases of React Native for over a year, these releases haven’t been effectively used by most projects. They are now easier to access and we hope to use them as release candidates going forward. Nightly releases are published to npm under the “nightly” tag.

To improve the process of testing individual commits, React Native’s CI will now create a tarball artifact for each commit on the main and release branches as well as for each PR. We refer to them as commitlies. These commitlies will not be published to npm, but they can be downloaded directly from CircleCI. See instructions below.

Want to help get a PR merged? By trying out the related commitly and verifying the change, you will be providing valuable signal to help get the change landed!

Using Nightly Releases (Nightlies)​

The process for migrating your project to a React Native nightly release is very similar to the one you would follow when upgrading to a regular version, with the exception that tools like the Upgrade Helper do not currently work with nightlies. With that in mind, we recommend that you first upgrade your project to the most recent stable release if you have not done so yet. Then, run yarn upgrade react-native@nightly to install the most recent nightly release. Note that there may be additional changes that are needed for your project to work properly on a nightly release.

Using Commitly Releases (Commitlies)​

Just like with a nightly release, first make sure that your project has been upgraded to the most recent stable version. Then, go to the react-native dashboard on Circle CI and look up the workflow that was triggered by the commit in question. There, you should see a job named build_npm_package. That job will have an “Artifacts” panel which will provide a link that you may use to download a tarball file. You can then run the following:

# Update your react-native dependency to the tarball
# using your preferred package manager
$ yarn add <path to tarball>
$ npm add <path to tarball>

Acknowledgements​

This release includes 621 commits with 92 contributors! Thank you to all our contributors new and old! You can find the full changelog here.

As well, thank you to the following contributors for their support in preparing, testing and unblocking this release!

• @acoates-ms
• @dulmandakh
• @kelset
• @kraenhansen
• @mikehardy
• @NickGerleman
• @pvinis
• @satya164
• @Simek
• @swrobel
• @thymikee
• @tido64
• @titozzz

With new mobile OS versions releasing late this year, we recommend preparing your React Native apps beforehand to avoid regressions when the releases become generally available.

iOS 15​

The release date of iOS 15 hasn’t been announced yet, but based on previous iOS releases, it will likely be around September 16th. Please also account for App Store review time if any changes are required to prepare your app for iOS 15.

What to watch out for​

QuickType Bar​

The way to disable QuickType bar in TextInput has changed. QuickType bar is the bar above keyboard with three suggested words. In case your UI needs to have the bar hidden, setting autoCorrect to false no longer disables QuickType bar in iOS 15 like earlier versions. In order to hide the QuickType bar, you need to also set spellCheck to false. This will disable spell check, the red underlines, in your TextInput. Disabling QuickType bar with spell check enabled is no longer an option.

To disable QuickType bar in iOS 15, set prop spellCheck and autoCorrect to false.

<TextInput
  placeholder="something"
  autoCorrect={false}
  spellCheck={false}
/>

Transparent Navigation Bar​

iOS 15 changes the default behaviour of the navigation bar. Unlike in iOS 14, the navigation bar becomes transparent when the content is scrolled all the way up. Make sure to watch out for this as it can make content difficult to read. For tips on how to work around this issue, check out this thread.

How to install iOS 15​

Device​

If you have a spare device, you can join the beta program and install iOS 15. At this point, beta releases are generally stable, but keep in mind that the upgrade to iOS 15 is irreversible.

Simulator​

To test your app on a simulator with iOS 15, you will need to download Xcode 13. You can find Xcode 13 here.

Android 12​

Android 12 will be released this autumn and it introduces some changes which can potentially affect your app experience. Traditionally, Google Play requires target SDK of your app to be upgraded before November of the following year. (see requirements for previous release here).

What to watch out for​

Overscroll Effect​

Android 12 introduces new overscroll effect which affects all scroll containers. As React Native scroll views are based on the native views, we recommend to check your scrollable containers to ensure the effect is applied correctly. You can opt-out from it by setting overScrollMode prop to never.

Permission Updates​

Android 12 allows users of your app to only provide access to the approximate location if you request it with ACCESS_FINE_LOCATION permission. Learn more about it here.

Check out Google’s detailed behavior changes for all apps running on Android 12.

How to install Android 12​

Device​

If you have a spare Android device, check if you’re able to install Android 12 Beta via instructions here.

Emulator​

If you don’t have a device available, you can set up an emulator following instructions here.