React Native Blog

React Native Comes to Meta Quest

Tue, 24 Feb 2026 00:00:00 GMT

React Native has always focused on helping developers reuse knowledge across platforms. What started with Android and iOS has steadily expanded to Apple TV, Windows, macOS, and even the web with react-strict-dom. In 2021, the Many Platform Vision post outlined a future where React Native could adapt to new devices and form factors without fragmenting the ecosystem.

At React Conf 2025, we took another step toward that vision by announcing official React Native support for Meta Quest devices. This post focuses on how to get started with React Native on Meta Quest, what works today, and how developers can build and ship VR apps using familiar tools and patterns.

Highlights

React Native on Meta Quest

React Native apps running on Meta Quest.

Meta Quest devices run Meta Horizon OS, an Android-based operating system. From a React Native perspective, this means all of the existing Android tooling, build systems, and debugging workflows work with minimal changes. For developers already building React Native apps on Android, much of existing development model carries over.

This aligns with how React Native has expanded to other Android-based environments over time. Rather than introducing a new runtime or development model, Meta Quest builds on the same Android foundation and integrates with React Native's existing abstractions. This allows platform-specific capabilities to be added without fragmenting the framework or requiring a separate approach to development.

Getting started on Meta Quest

This section walks through the basic development workflow on Meta Quest, starting with Expo Go and moving toward development builds and platform-specific configuration.

Step-by-step: Run an Expo app on Meta Quest

To run an Expo app on Meta Quest, start a standard Expo project, launch the dev server, and open the app through Expo Go on the headset. Beyond a few Meta Horizon OS-specific requirements, the workflow is the same as on Android.

Install Expo Go on the headset

Expo Go is available on the Meta Horizon Store and can be installed directly on Meta Quest devices. It is used for rapid iteration during development.
Create (or use) an Expo project

If you're starting fresh, create a standard Expo app. No special template is required.
```
npx create-expo-app@latest my-quest-app
cd my-quest-app
```
Start the dev server
```
npx expo start
```
Connect with Quest using Expo Go

Open Expo Go on the headset and scan the QR code displayed by the Expo CLI with the headset camera. The application launches in a new window on the device, allowing live reloading and fast iteration.
Iterate as usual

Code changes are reflected immediately on the device, following the same edit-refresh cycle used on Android and iOS.

Development builds and native features

Expo Go is sufficient for early development and UI work. When access to native modules or deeper platform integration is required, development builds are used instead. These builds follow the standard Expo development build workflow and run directly on the Quest device.

Platform-specific setup and differences from mobile

While the overall workflow remains the same, Meta Quest requires a small set of platform-specific adjustments.

Project configuration for Meta Horizon OS

Meta Quest applications must meet specific requirements to run correctly and to be eligible for store submission. These include platform-specific Android configuration, product flavors, and application metadata.

Expo provides a plugin for Meta Horizon OS that applies these requirements at build time. Using this plugin ensures the project configuration aligns with Meta Quest expectations without manual modification of native files.

Install expo-horizon-core and add it to app.json or app.config.js:

{
  "expo": {
    "plugins": [
      [
        "expo-horizon-core",
        {
          "horizonAppId": "your-horizon-app-id",
          "defaultHeight": "640dp",
          "defaultWidth": "1024dp",
          "supportedDevices": "quest2|quest3|quest3s",
          "disableVrHeadtracking": false,
          "allowBackup": false
        }
      ]
    ]
  }
}

Also, change the orientation value:

{
   ...
   "orientation": "default",
   ...
}

Update package.json with Quest-specific scripts:

{
  "scripts": {
    "android": "expo run:android --variant mobileDebug",
    "quest": "expo run:android --variant questDebug",
    "android:release": "expo run:android --variant mobileRelease",
    "quest:release": "expo run:android --variant questRelease"
  }
}

Using React Native without Expo

Expo provides the easiest way to get started with React Native on Meta Quest. If you prefer to build without a framework, you can also apply the required Meta Horizon OS configuration directly in your Android project.

At a minimum, this includes:

Creating a Meta Quest-specific build flavor in android/app/build.gradle
Setting the horizonAppId
Defining a default panel size in the Android manifest
Declaring supported devices (for example: quest2|quest3|quest3s)
Removing prohibited permissions
Adjusting the minimum supported Android SDK version
Adding runtime checks such as isHorizonDevice() and isHorizonBuild()

To understand the full set of changes, you can inspect the expo-horizon-core plugin implementation and replicate the same configuration manually.

Android without Google Play Services

Meta Horizon OS is built on Android Open Source Project (AOSP), which provides the core Android platform without Google's proprietary services. From a development perspective, this means applications run on standard Android APIs but do not have access to Google Mobile Services such as Play Services or Play Store–specific integrations.

When targeting Meta Quest, applications should be designed to avoid direct dependencies on Google services or to provide platform-specific alternatives where needed.

A list of unsupported dependencies is available in the Meta Horizon OS documentation.

Permissions and device capabilities

Some Android permissions and hardware assumptions common on mobile devices do not apply to VR headsets. Cellular features (e.g. SMS), certain sensors (like GPS), and restricted permissions are either unavailable or prohibited. Projects must explicitly account for these differences during setup.

Evaluating library compatibility

Most React Native libraries work on Meta Quest, but compatibility depends on the assumptions a library makes about the underlying platform. In particular, libraries may rely on mobile-only hardware, touch input, or services that are not available on Horizon OS.

As a general guideline:

Libraries that are self-contained and rely only on standard React Native and Android APIs typically work without changes.
Libraries that assume touch-only input, mobile-only hardware, or Google Mobile Services require adaptation or conditional usage.
Libraries that depend on restricted permissions or unavailable device capabilities are not supported.

For some common use cases, such as location and notifications, Expo provides drop-in replacements for Meta Horizon OS. Other libraries may work as-is or require platform-specific handling depending on their dependencies.

Platform-aware code paths

Applications targeting both Meta Quest and other platforms should guard platform-specific behavior. Meta Horizon OS provides runtime utilities to detect whether the app is running on a Quest device, allowing unsupported features to be disabled or replaced when necessary.

import ExpoHorizon from 'expo-horizon-core';

// Check if running on a Horizon device
if (ExpoHorizon.isHorizonDevice) {
  console.log('Running on Meta Horizon OS!');
}

// Check if this is a Horizon build
if (ExpoHorizon.isHorizonBuild) {
  console.log('This is a Horizon build variant');
}

// Access the Horizon App ID
const appId = ExpoHorizon.horizonAppId;
console.log('Horizon App ID:', appId ?? 'Not configured');

Design and UX considerations for VR

Designing for a head-mounted display introduces constraints that differ from touch-based mobile devices. Interfaces are viewed at a distance, rendered in space, and interacted with using a wider range of input methods.

UI elements generally require larger hit targets, increased spacing, and typography that remains readable across varying distances. These challenges are similar to those encountered on desktop, tablets, and foldable devices, where applications run in resizable windows and layouts must adapt dynamically.

One of the main differences between Meta Quest and Android mobile is input. Instead of relying primarily on touch, Meta Quest applications are commonly controlled through controllers, hand tracking, and optionally mouse and keyboard. Controllers behave more like a pointer device, which introduces interaction patterns that are closer to web and desktop UIs, including hover and focus-based navigation.

React Native's event system and component model can support these interaction patterns, but applications should avoid touch-only assumptions and ensure that UI elements provide clear focus states and predictable navigation when controlled through pointing devices.

Together, these considerations favor responsive layouts and input-agnostic interactions. React Native's layout system and component model provide a solid foundation for building comfortable and usable VR interfaces.

note

For more details, check out the official design guidelines.

Examples and references

Reference project

Learn more

Acknowledgements

Bringing React Native to new platforms takes more than code. We're grateful to everyone who contributed their time, feedback, and support along the way.

React Native 0.84 - Hermes V1 by Default

Wed, 11 Feb 2026 00:00:00 GMT

Today we're excited to release React Native 0.84!

This release makes Hermes V1 the default JavaScript engine, bringing significant performance improvements to all React Native apps. We've also continued removing the Legacy Architecture on both iOS and Android, and are shipping precompiled iOS binaries by default.

Highlights

Hermes V1 as Default

Hermes V1 is now the default JavaScript engine for React Native on both iOS and Android, following the initial experimental opt-in in React Native 0.82.

Hermes V1 represents the next evolution of the Hermes engine, with significant improvements to both the compiler and VM that deliver measurably better JavaScript performance.

What This Means for Your App

Automatic performance gains: All apps will use Hermes V1 by default, bringing improved execution speed and reduced memory usage.
No migration required: If you're already using Hermes (the default since 0.70), you'll automatically get Hermes V1. No configuration changes needed.

Opting out from Hermes V1

React Native 0.83 - React 19.2, New DevTools features, no breaking changes

Wed, 10 Dec 2025 00:00:00 GMT

Today we are excited to release React Native 0.83!

This release includes React 19.2, significant new features for React Native DevTools, and support for the Web Performance and Intersection Observer APIs (Canary). This is also the first React Native release with no user facing breaking changes.

Highlights

React 19.2

This release includes React 19.2, bringing the new and useEffectEvent APIs to React Native.

Important: CVE-2025-55182

At time of release, react-native@0.83.0 depends on react@19.2.0, and you might also have seen the recent Critical Security Vulnerability in React Server Components.

We want to stress that React Native is NOT directly affected by this vulnerability, as it does not depend on the impacted packages:

react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack

However, if you are using React Native as part of a monorepo where these packages may be present, please check and upgrade them immediately.

We will update all React dependencies to 19.2.1 in our next patch release.

lets you break your app into "activities" that can be controlled and prioritized. You can use Activity as an alternative to conditionally rendering parts of your app, and it currently supports 2 modes: 'visible' and 'hidden'.

hidden: hides the children, unmounts effects, and defers all updates until React has nothing left to work on.
visible: shows the children, mounts effects, and allows updates to be processed normally.

One interesting feature of trees hidden using is that they preserve their state. So, when they become visible again, they, for example, keep the search status and the selection from a previous user interaction.

React 19.1.1	React 19.2.1

You can read more about in the React docs.

`useEffectEvent`

One common pattern with useEffect is to notify the app code about some kind of "event" from an external system. The problem with this approach is that a change to any value used inside such an event will cause the surrounding Effect to re-run.

To solve this, most users disable the lint rule and exclude the dependency. But that can lead to bugs since the linter can no longer help you keep the dependencies up to date if you need to update the Effect later.

With useEffectEvent, you can split the "event" part of this logic out of the Effect that emits it.

You can read more about useEffectEvent in the React docs.

New DevTools features

In 0.83 we're excited to deliver some long awaited features and quality of life improvements to React Native DevTools.

Network and Performance panels

Network inspection and performance tracing are two powerful new capabilities in React Native DevTools, available today.

Network inspection, now available for all React Native apps, allows you to view and understand the network requests made by your app. Logged requests provide detailed metadata such as timings and headers sent/received, as well as response previews. And — for the first time — you can use the Initiator tab to see where in your code a network request originated.

💡 Network event coverage, Expo support

React Native 0.82 - A New Era

Wed, 08 Oct 2025 00:00:00 GMT

Today we're excited to release React Native 0.82: the first React Native that runs entirely on the New Architecture.

This is a milestone release for React Native and we believe it's the start of a new era. In future versions we will be removing the remaining code from the Legacy Architecture to reduce install size and streamline the codebase.

In addition, 0.82 also ships with an experimental opt-in to a newer version of Hermes called Hermes V1. We’re also enabling several React features by updating the React version to 19.1.1, and shipping support for DOM Node APIs.

Highlights

New Architecture Only

In React Native 0.76 we announced that The New Architecture became the default architecture of React Native.

Since then, the New Architecture has been tested and refined and we're confident in making it the only architecture for this and future versions of React Native.

This means that if you try to set newArchEnabled=false on Android, or if you try to install CocoaPods with RCT_NEW_ARCH_ENABLED=0 on iOS, these will be ignored and your app will still run using the New Architecture.

How to migrate

If you haven’t migrated your project to the New Architecture, we recommend first migrating your project to React Native 0.81 or Expo SDK 54. These are the last versions that allow you to use the Legacy Architecture. They contain warnings and performance improvements specifically to help migrating to the New Architecture.
Then enable the New Architecture in 0.81 and verify that your application is working fine.
Once you're using the New Architecture in 0.81, you can update safely to React Native 0.82 which prevents enabling the Legacy Architecture.

If an incompatible 3rd party dependency is blocking you from migrating to the New Architecture, we recommend you reach out to the library maintainers directly.

If a bug in React Native core is blocking you from migrating, we recommend you reach out to us through our issue tracker.

Interop Layers & 3P library compatibility

We will keep the interop layers in the codebase for the foreseeable future. All the classes and functions that are required by the interop layers won’t be removed anytime soon. We will share further updates in the future regarding the removal of Interop Layers.

We’ve also verified that the 3P libraries that offer backward compatibility with both architectures will keep on working with 0.82 where New Architecture is the only architecture.

Removal of Legacy Architecture classes

To ensure backward compatibility and reduce breaking changes, we are not removing any APIs of the Legacy Architecture from the core of React Native in this version. Removing the Legacy Architecture will allow us to save significant size on the overall bundle size, therefore the removal is scheduled to start from the next version of React Native.

You can find more information in RFC0929: Removal of the Legacy Architecture of React Native.

Experimental Hermes V1

React Native 0.82 adds support for opting into Hermes V1.

Hermes V1 is the next evolution of Hermes. We've been experimenting with it internally in our apps, and it is now time for the community to try it as well. It comes with improvements in the compiler and in the VM that boost Hermes performance.

From initial tests and benchmarks, Hermes V1 outperforms current Hermes in various scenarios. We have seen improvements in bundle loading and TTI. The improvements strongly depend on the details of your apps.

On the Expensify app, a real world and complex application, we have seen the following improvements:

Metric	Android (low end device)	iOS
Bundle Load Time	3.2% faster	9% faster
Total TTI	7.6% faster	2.5% faster
Content TTI	7.2% faster	7.5% faster

For Total TTI, we measured the time it takes from bundle loading to when the first screen in the app is rendered and it is interactive.

For Content TTI, we measured the time it takes for a component to be interactive, starting from the first rendering of the component itself.

Hermes V1 does not yet contain JS-to-native compilation (previously known as “Static Hermes”) or the JIT compilation that was presented during React Native EU 2023. We are still testing these features, and will share more as we make progress.

How to enable Hermes V1

info

While Hermes V1 is in the experimental phase, you’ll need to build React Native from source to try it out. Once Hermes V1 ships as default in a future React Native version, this restriction will be lifted.

To try Hermes V1 in your own project, use the following steps:

Force your package manager to resolve the experimental version of Hermes V1 compiler package by modifying the corresponding section of your package.json file (note that the current versioning convention is only for the experimental phase of Hermes V1):

yarn
npm

"resolutions": {
    "hermes-compiler": "250829098.0.1"
}

"overrides": {
    "hermes-compiler": "250829098.0.1"
}

Enable Hermes V1 for Android by adding hermesV1Enabled=true inside the android/gradle.properties:

android/gradle.properties
hermesV1Enabled=true

Also, configure React Native to build from source by editing android/settings.gradle:

android/settings.gradle
  includeBuild('../node_modules/react-native') {
      dependencySubstitution {
          substitute(module("com.facebook.react:react-android")).using(project(":packages:react-native:ReactAndroid"))
          substitute(module("com.facebook.react:react-native")).using(project(":packages:react-native:ReactAndroid"))
          substitute(project(":packages:react-native:ReactAndroid:hermes-engine")).using(module("com.facebook.hermes:hermes-android:250829098.0.1"))
      }
  }

Enable Hermes V1 for iOS by installing pods with RCT_HERMES_V1_ENABLED=1 environment variable.

RCT_HERMES_V1_ENABLED=1 bundle exec pod install

Keep in mind that Hermes V1 is not compatible with the precompiled React Native builds, so make sure you don’t use the RCT_USE_PREBUILT_RNCORE flag when installing pods.

To confirm if your app is running Hermes V1, execute the following code within your app or DevTools console. This code will return the Hermes version, which should match the version specified in step 1 (250829098.0.1):

// expecting "250829098.0.1" in Hermes V1
HermesInternal.getRuntimeProperties()['OSS Release Version'];

React 19.1.1

This release of React Native ships with the latest React stable: React 19.1.1.

This release of React contains full support for owner stacks for React Native. Back in React Native 0.80, when we shipped support for 19.1.0, we mentioned that owner stacks were not fully supported if you were using the @babel/plugin-transform-function-name Babel plugin. This release lifts this restriction and enables owner stacks for all React Native users.

BEFORE	AFTER

React 19.1.1 also improves the reliability of useDeferredValue and startTransition in a Suspense boundary for React Native. These are essential React features, designed to boost app responsiveness. Previously both were wrongly showing the fallback component when used together with a Suspense boundary on React Native. With React 19.1.1, they now consistently perform as expected on React Native, aligning their behavior with Web.

DOM Node APIs

Starting from React Native 0.82, native components will provide DOM-like nodes via refs.

Before, native components provided React Native-specific objects with just a handful of methods like measure and setNativeProps. After this release, they will provide nodes implementing a subset of the DOM API to traverse the UI tree, measure layout, and more as on Web. For example:

function MyComponent(props) {
  const ref = useRef();

  useEffect(() => {
    const element = ref.current;

    // New methods
    element.parentNode;
    element.parentElement;
    element.childNodes;
    element.children;
    const bounds = element.getBoundingClientRect();
    const doc = element.ownerDocument;
    const maybeElement = doc.getElementById('some-view');

    // Legacy methods are still available
    element.measure((x, y, width, height, pageX, pageY) => {
      /* ... */
    });
  }, []);

  return <View ref={ref} />;
}

Additionally, this will expose access to leaf text nodes (created by the Text component) and document nodes representing React Native root nodes.

This is a backwards compatible change, as the new nodes will continue implementing the legacy methods (like measure).

For more information, please check our documentation.

Other changes

Web Performance APIs (Canary)

React Native now implements a subset of the performance APIs available on Web:

High Resolution Time: defines performance.now() and performance.timeOrigin.
Performance Timeline: defines PerformanceObserver and methods to access performance entries in the performance object (getEntries(), getEntriesByType(), getEntriesByName()).
User Timing: defines performance.mark and performance.measure.
Event Timing API: defines event entry types reported to PerformanceObserver.
Long Tasks API: defines longtask entry types reported to PerformanceObserver.

They allow tracking different aspects of performance in your app at runtime (for telemetry) and they will be visible in the performance panel in React Native DevTools (available in a future version of React Native).

They are currently available only in the canary release level, and will be released as stable in a future version of React Native.

Optimized Debug Build Type for Android

Starting with React Native 0.82, you will be able to use the debugOptimized build type to speed up your development experience.

Historically, Android creates two default build variants:

debug, used by default when developing and that allows you to connect to the various debugger tools such as React Native DevTools, Metro, the Android JVM and C++ debugger
release, used when shipping your application to production. This is fully optimized, with obfuscation and optimization that will make debugging harder.

As most React Native developers won’t need to use the C++ debugger when developing, we introduced the debugOptimized build type.

With debugOptimized your animations and re-rendering will be faster, because you’re running a React Native build with several C++ optimizations enabled. At the same time you will still be able to use React Native Dev Tools to debug your JavaScript code.

When using debugOptimized, you won’t be able to use the C++ native debuggers, but you will still be able to use it if you use the debug build type.

To run the debugOptimized variant for your app you can invoke:

Community CLI
Expo

npx react-native run-android --mode debugOptimized

npx expo run:android --variant debugOptimized

info

The debugOptimized build type has also been backported to React Native 0.81 and Expo SDK 54.

You can see the debugOptimized in action in these samples where we’re rendering several animations on screens.

The build running debug is running at ~20FPS while the debugOptimized one is running at ~60FPS:

`debug`	`debugOptimized`

Breaking Changes

Uncaught promise rejections will now raise `console.error`

Following the improvement of reporting uncaught JavaScript errors in the previous version, we will now be reporting uncaught promises through that mechanism as well:

Due to a bug, these were completely swallowed and ignored previously, so please expect some pre-existing errors to surface after upgrading to React Native 0.81. For that reason, previously pre-existing errors might also surface in JavaScript errors reported to your backend, and create a surge in new reports.

Other Breaking Changes

General

Move ReactNativeFeatureFlags to src/private
- In general you should not depend on ReactNativeFeatureFlags at all as that is a private API.
Type of Appearance.setColorScheme() has been updated to no longer accept a nullable value
- Use 'unspecified' instead of null/undefined in the edge case that the color scheme needs to be reset.

iOS

Migrated RCTDisplayLink away from legacy api RCTModuleData as we plan to remove it in the future.

Android

Class com.facebook.react.bridge.JSONArguments is removed as was accidentally public
Deprecate MessageQueueThreadPerfStats
- We deprecated this API and replaced it with stub. You should not rely on stats from this API anymore as the provided stats were not reliable
Bump Gradle from 8.x to 9.0.0
- List of all the changes in the next major stable version of Gradle 9.0.0 is available here but we expect no impact at all to users

C++

Delete backward compatibility headers for CallbackWrapper.h / LongLivedObject.h
- The correct include for those headers is #include and #include .
- You should not use the old includes under #import

Read the full list of breaking changes in the CHANGELOG for 0.82.

Acknowledgements

React Native 0.82 contains over 868 commits from 93 contributors. Thanks for all your hard work!

We want to send a special thank you to those community members that shipped significant contributions in this release:

Dawid Małecki and Jakub Piasecki for the help in rolling out Hermes V1.
Krystof Woldrich for the support with fixing the swallowing of uncaught promise rejections.
Riccardo Cipolleschi for the support with writing the React 19.1.1 and Hermes V1 paragraph above.
Rubén Norte for the support with writing the DOM API and Performance API paragraphs.
Tomasz Zawadzki for the support with the debugOptimized benchmarking.

Upgrade to 0.82

Please use the React Native Upgrade Helper to view code changes between React Native versions for existing projects, in addition to the upgrading to new versions docs.

To create a new project:

npx @react-native-community/cli@latest init MyProject --version latest

If you use Expo, React Native 0.82 will be available as part of the expo@canary releases.

The next SDK, SDK 55, will be shipped with the next stable release of React Native: 0.83.

info

0.82 is now the latest stable version of React Native and 0.79.x moves to unsupported. For more information see React Native's support policy.

React Native 0.81 - Android 16 support, faster iOS builds, and more

Tue, 12 Aug 2025 00:00:00 GMT

Today we are excited to release React Native 0.81!

This ships with support for Android 16 (API level 36) and includes a variety of other stability improvements and bugfixes, as well as experimental support for faster iOS builds using precompilation.

Highlights

Android 16 support

Android apps built with React Native 0.81 will now default to targeting Android 16 (API level 36).

As previously announced by Google, Android 16 requires that apps are displayed edge-to-edge with no support for opting out.

To support this, we are deprecating the component as previously announced in favor of alternatives. See below which will provide better edge-to-edge support.

We are also adding a new gradle property edgeToEdgeEnabled to let you choose if you wish to enable edge-to-edge on all supported Android versions below 16.

Predictive back gesture is now enabled by default for apps targeting Android 16. The BackHandler API should continue to work as before for most use cases. However, if your app relies on custom native code for back handling (such as overriding the onBackPressed() method), you may need to manually migrate your code or temporarily opt-out. Please test your app’s back navigation thoroughly after upgrading.

Google now expects apps to support adaptive layouts on large screen devices, regardless of orientation or size restrictions. While you can opt-out for now, it’s recommended to test and update your app for responsive UI on large screens before Android 17.

Starting November 1, 2025, all Google Play app submissions must meet the 16 KB page size requirement for native binaries. This applies to new apps and updates targeting Android 15+ devices. React Native is already 16KB page size compliant. Ensure all your native code and third-party libraries are compliant as well.

For more details on Android 16 changes and migration steps, refer to this post in the discussions-and-proposals repository.

SafeAreaView deprecation

The built-in component was originally designed to provide limited, iOS-only support for keeping content in the “safe areas” of the screen (away from camera notches, rounded corners, etc). It is not compatible with edge-to-edge rendering on Android, and does not permit customization beyond padding. As a result, many apps have opted for more portable and flexible solutions, such as react-native-safe-area-context.

In React Native 0.81, the legacy component is deprecated, and you will see warnings in React Native DevTools if your app uses it.

It will be removed in a future version of React Native. We recommend that you migrate to react-native-safe-area-context or a similar library to ensure your app looks its best across all platforms.

Community-maintained JavaScriptCore support

As we announced last year, support for the JavaScriptCore (JSC) engine has moved to a community-maintained package that is released separately from React Native itself. In React Native 0.81, we're removing the built-in version of JavaScriptCore. All apps that require JavaScriptCore should now use the community package in order to upgrade to 0.81. Read the installation instructions for the details.

This change does not affect apps that are using Hermes.

Experimental Precompiled iOS builds

React Native 0.81 introduces precompiled iOS builds, cutting compile times by up to 10x in projects where React Native is the primary dependency. This is the result of a collaboration between Expo and Meta, and expands on work we previously shipped in React Native 0.80.

This feature is still experimental, but we are hoping to enable it for all apps in a future release. If you’d like to try precompiled builds in your own app, you can enable them by specifying the following environment variables when you run pod install:

RCT_USE_RN_DEP=1 RCT_USE_PREBUILT_RNCORE=1 bundle exec pod install

Please provide feedback in this GitHub discussion.

There are two limitations we are already aware of, and are working to resolve:

In precompiled builds, you cannot debug and step into React Native's internals. You can still debug your own native code while using a precompiled version of React Native.
Prebuilds are not supported in Xcode 26 Beta, because the IDE builds all targets with Swift explicit modules enabled. To use precompiled builds with Xcode 26, set the SWIFT_ENABLE_EXPLICIT_MODULES flag to NO in your Xcode project. We will address this in an upcoming patch release.

You can read more about this feature in Expo’s full blog post, Precompiled React Native for iOS: Faster builds are coming in 0.81.

Breaking Changes

Minimum Node.js bumped to 20

React Native now requires Node.js version 20.19.4 (the latest Maintenance LTS version at the time of writing) or higher. You may need to upgrade Node.js in your development or CI environment when you upgrade to React Native 0.81.

Minimum Xcode bumped to 16.1

React Native now requires Xcode 16.1 or higher to build iOS projects. You may need to upgrade Xcode in your development or CI environment when you upgrade to React Native 0.81.

Metro: Better support for advanced configuration in Community CLI projects

Metro now respects the resolveRequest and getModulesRunBeforeMainModule options if specified in the metro.config.js file of a React Native Community CLI project. Previously, setting them would have no effect. If you have custom values for these options in your metro.config.js file, you may need to delete them in order to restore the previous behavior.

Improved reporting of uncaught JavaScript errors

React Native DevTools now shows the original message and stack trace of uncaught JavaScript errors, as well as the error’s cause if any, and an Owner Stack for errors thrown by components. This makes errors easier to debug and fix.

If you are logging JavaScript errors to your backend or to a third-party error reporting service, this may affect the logs you see after upgrading to React Native 0.81 (for example: you might see more thrown errors that used to be reported via console.error), and you may need to update some backend logic accordingly.

`RN_SERIALIZABLE_STATE` and C++ flags.

In this version of React Native, we introduced a new macro called RN_SERIALIZABLE_STATE to support serializable state for the Components on New Architecture.

If you’re a library author and you have a custom CMakeLists.txt file, you will need to specify this macro in your CMakeLists.txt file or your C++ code could fail to compile.

To support this, we introduce a new CMake function called target_compile_reactnative_options which will take care of setting up this macro and all the necessary C++ flags for you. You can invoke it as such in your CMakeLists file:

target_compile_reactnative_options(myLibraryName PRIVATE)

You can see an example of how react-native-screens has set up this macro.

This change will affect only more advanced and complex libraries. If your library is using codegen and you don’t have a custom CMake file, you won’t be affected by this change.

Other Breaking Changes

This list contains a series of other breaking changes we suspect could have a minor impact to your product code and are worth noting:

Android

We made several classes internal. Those classes are not part of the public API and should not be accessed. We already notified or submitted patches to the affected libraries:
- com.facebook.react.fabric.mounting.MountingManager
- com.facebook.react.views.text.TextLayoutManager
We moved the textAlignVertical native prop from TextAttribute.h to ParagraphAttribute.h
- The prop textAlignVertical only affects the top most text view (paragraph view). Yet, it exists in text attribute props nonetheless. To better reflect this platform limitation it was moved to paragraph props.
- This change is not affecting the JS API of the component.
- You will be affected by this change only if you implement a Fabric component that interacts with the C++ Text API.
- If you’re affected by this change, you can replace TextAttributes.h with ParagraphAttribute.h in your code

Read the full list of breaking changes in the CHANGELOG for 0.81.

Acknowledgements

React Native 0.81 contains over 1110 commits from 110 contributors. Thanks for all your hard work!

We want to send a special thank you to those community members that shipped significant contributions in this release:

Christian Falch for the amazing work on precompiled iOS builds.
Mathieu Acthernoene for crucial contributions to Android edge-to-edge support
Enrique López-Mañas and for helping test Android 16 integration and the SafeAreaView deprecation.

Upgrade to 0.81

Please use the React Native Upgrade Helper to view code changes between React Native versions for existing projects, in addition to the Upgrading docs.

To create a new project:

npx @react-native-community/cli@latest init MyProject --version latest

If you use Expo, React Native 0.81 will be supported in the upcoming Expo SDK 54 as the default version of React Native.

info

0.81 is now the latest stable version of React Native and 0.78.x moves to unsupported. For more information see React Native's support policy.

React Native 0.80 - React 19.1, JS API Changes, Freezing Legacy Arch and much more

Thu, 12 Jun 2025 16:01:00 GMT

Today we are excited to release React Native 0.80!

This release brings the version of React we ship inside React Native to the latest stable available: 19.1.0.

We’re also shipping a series of stability improvements to our JS API: deep imports will now fire a warning and we’re offering a new opt-in Strict TypeScript API which offers types that are more accurate and safer to use.

Moreover, the Legacy Architecture of React Native is now officially frozen, and you’ll start seeing warnings for APIs that will stop working once we fully sunset the Legacy Architecture.

Highlights

JavaScript deep imports deprecation

In this release, we are making moves to improve and stabilize React Native's public JavaScript API. The first step towards this is better scoping of which of our APIs are importable by apps and frameworks. In line with this, we are formally deprecating deep imports from React Native (see RFC), and are introducing warnings via ESLint and the JS console.

These warnings are scoped to imports from within your project's source code, and can be opted out from. However, please bear in mind that we aim to remove deep imports from React Native's API in a future release, and these should instead be updated to the root import.

// Before - import from subpath
import {Alert} from 'react-native/Libraries/Alert/Alert';

// After - import from `react-native`
import {Alert} from 'react-native';

Some APIs are not exported at root, and will become unavailable without deep imports. This is intentional, in order to reduce the overall surface area of React Native's API. We have an open feedback thread for user issues, and will be working with the community to finalize which APIs we export over (at least) the next two React Native releases. Please share your feedback!

Learn more about this change in our dedicated post: Moving Towards a Stable JavaScript API.

Opt-in Strict TypeScript API

With the above redefinition of the exports in our public API, we're also shipping a new set of TypeScript types for the react-native package in 0.80, which we're calling the Strict TypeScript API.

Opting into the Strict TypeScript API is a preview of our future, stable JavaScript API for React Native. These new types are:

Generated directly from our source code — improving coverage and correctness, so you can expect stronger compatibility guarantees.
Restricted to React Native's index file — more tightly defining our public API, and meaning we won't break the API when making internal file changes.

We're shipping these alongside our existing types, meaning you can choose to migrate when ready. Also, if you're using standard React Native APIs, a lot of apps should validate with no changes. We strongly encourage early adopters and newly created apps to opt in via your tsconfig.json file.

When the community is ready, the Strict TypeScript API will become our default API in future — synchronized with deep imports removal.

Learn more about this change in our dedicated post: Moving Towards a Stable JavaScript API.

Legacy Architecture Freezing & Warnings

The New Architecture of React Native is the default choice since version 0.76 and we’ve been reading success stories of projects and tools that greatly benefit from it.

We recently shared that we now consider the Legacy Architecture as frozen. We won’t be developing new bugfixes or features in the Legacy Architecture anymore and we will stop testing the Legacy Architecture while working on a release.

In order to smooth the migration, we are still allowing users to opt-out of the New Architecture if you’re experiencing bugs or regressions.

However shipping two architectures with React Native is a huge challenge, which impacts runtime performance, app size and maintenance of our codebase.

That’s why we’ll eventually have to sunset the Legacy Architecture at some point in the future.

In 0.80, we’ve added a series of warnings that will pop-up in React Native DevTools to warn you if you’re using APIs that won’t work in the New Architecture.

We recommend you to not ignore those warnings and to consider migrating your apps & libraries to the New Architecture to be ready for the future.

You can learn more about those changes in the talk "Life After Legacy: The New Architecture Future" we recently presented at App.js.

React 19.1.0

This release of React Native ships with the latest React stable: 19.1.0

You can read about all the new features and bugfixes introduced in React 19.1.0 in the release description.

warning

One notable feature of React 19.1.0 is the implementation and improvements of owner stacks. This is a development only feature that should help you identify which component is responsible for a specific error.

However, we are aware that owner stacks are not working as expected in React Native if you use the @babel/plugin-transform-function-name Babel plugin, which is enabled by default in the React Native Babel Preset. We will be shipping a fix for this in a future release of React Native.

Experimental - React Native iOS dependencies are now prebuilt

If you’re building a React Native iOS app, you probably noticed that the first native build will take some time: a couple of minutes or even longer on older machines. That’s because we need to compile the whole React Native iOS code plus all of its dependencies.

Over the last weeks we’ve been experimenting with prebuilding some of the React Native core for iOS, similarly to what happens on Android, to reduce the build time when you’re first running a React Native app.

React Native 0.80 is the first release that can ship part of React Native for iOS as a prebuild to help reduce build times.

During the release process of React Native, we are producing an XCFramework called ReactNativeDependencies.xcframework that is a prebuilt version of only the 3rd party dependencies React Native depends on.

We experimented and benchmarked how much time this initial prebuild for iOS is saving and, in our benchmarks, run on an M4 machine, iOS builds are roughly 12% faster with the prebuild rather than by building from source.

From our experience, we also observed that several bug reports from users are caused by build issues related with React Native’s 3rd party dependencies (example #39568). Prebuilding the 3rd party dependencies allows us to build them for you, so that you won’t face these build issues anymore.

Note that we are not pre-building the whole React Native: we are only pre-building the libraries Meta does not directly control, such as Folly and GLog.

In a future release, we will also ship the rest of React Native core as a prebuild.

How to use them

This feature is still experimental, so it is not turned on by default.

If you want to use them, you can install your pods by adding the RCT_USE_RN_DEP env variable:

RCT_USE_RN_DEP=1 bundle exec pod install

Alternatively, if you want to enable it for all the developers working on that, you can modify your Podfile like this:

if linkage != nil
  Pod::UI.puts "Configuring Pod with #{linkage}ally linked Frameworks".green
  use_frameworks! :linkage => linkage.to_sym
end

+ENV['RCT_USE_RN_DEP'] = '1'

target 'HelloWorld' do
  config = use_native_modules!

Please, report any issue that the prebuilds might cause to you and to your app in this discussion. We are committed to looking into them and making sure that tier usage is transparent to your app.

Other Changes

Android - Smaller APK size thanks to IPO

This release ships with significant size reduction for all the Android apps built with React Native. Starting in 0.80, we enabled Interprocedural Optimization for both React Native and Hermes builds.

This resulted in a saving of ~1Mb for all the Android apps.

You will get this size win by updating your React Native version to 0.80 and there are no further changes required to your project.

New App Screen redesign

If you’re not using Expo but you’re using the Community CLI & Template, in this version we've moved the New App Screen into its own package and given it a fresh coat of paint. This reduces initial code boilerplate when you create a new app with the Community Template, and also provides a better experience when viewed on larger screens.

Notice about JSC community support

React Native 0.80 is the last version of React Native to offer first party JSC support. The support for JSC will be offered via the community maintained package @react-native-community/javascriptcore.

In case you missed the announcement, you can read more about it here

Breaking Changes

Added `"exports"` field on main package

As part of our JS Stable API changes, we've introduced an "exports" field on the package.json manifest of react-native.

In 0.80, this mapping continues to expose all JavaScript subpaths by default, and therefore should not be a major breaking change. At the same time, this may subtly affect how modules within the react-native package are resolved:

Under Metro, platform-specific extensions will not be automatically expanded against "exports" matches. We've provided a number of shim modules to accommodate this (#50426).
Under Jest, the ability to mock deep imports may be altered, which may require updating tests.

Other Breaking Changes

This list contains a series of other breaking changes we suspect could have a minor impact to your product code and are worth noting:

JS

We bumped eslint-plugin-react-hooks from v4.6.0 to v5.2.0 (see full changelog here). The react-hooks lint rules may produce new error signals which you will have to fix or suppress

Android

This release bumps the Kotlin version shipped with React Native to version 2.1.20. Kotlin 2.1 introduces new language features in preview that you can start using in your modules/components. You can read more about it in the official release notes.
We deleted the StandardCharsets class. It has been deprecated since 0.73. You should use the java.nio.charset.StandardCharsets class instead.
We made several classes internal. Those classes are not part of the public API and should not be accessed. We already notified or submitted patches to the affected libraries:
- com.facebook.react.fabric.StateWrapperImpl
- com.facebook.react.modules.core.ChoreographerCompat
- com.facebook.react.modules.common.ModuleDataCleaner
We migrated several classes from Java to Kotlin. If you’re using those classes, the nullability and types of some parameter changed so you might need to adjust your code:
- All the classes inside com.facebook.react.devsupport
- com.facebook.react.bridge.ColorPropConverter
- com.facebook.react.views.textinput.ReactEditText
- com.facebook.react.views.textinput.ReactTextInputManager

iOS

We deleted the RCTFloorPixelValue field from RCTUtils.h - The RCTFloorPixelValue method was not used in React Native and we removed it altogether.

Further smaller breaking changes are listed in the CHANGELOG for 0.80.

Acknowledgements

React Native 0.80 contains over 1167 commits from 127 contributors. Thanks for all your hard work!

We want to send a special thank you to those community members that shipped significant contributions in this release:

Christian Falch for the work on the iOS prebuilds for React Native Dependencies
Iwo Plaza, Jakub Piasecki, and Dawid Małecki for their work on the Strict TypeScript API.

Moreover, we also want to thank the additional authors that worked on documenting features in this release post:

Riccardo Cipolleschi for authoring the part related to iOS prebuilds for React Native Dependencies.
Alex Hunt for Deep imports deprecation, Opt-in Strict TypeScript API, New App Screen redesign.
Nicola Corti for the Legacy Architecture Freezing & Warnings.

Upgrade to 0.80

Please use the React Native Upgrade Helper to view code changes between React Native versions for existing projects, in addition to the Upgrading docs.

To create a new project:

If you use Expo, React Native 0.80 will be supported in a canary release of the Expo SDK. Instructions on how to use React Native 0.80 in Expo are also available in a dedicated blogpost.

info

0.80 is now the latest stable version of React Native and 0.77.x moves to unsupported. For more information see React Native's support policy. We aim to publish a final end-of-life update of 0.77 in the near future.

Moving Towards a Stable JavaScript API (New Changes in 0.80)

Thu, 12 Jun 2025 16:00:00 GMT

In React Native 0.80, we're introducing two significant changes to React Native's JavaScript API — the deprecation of deep imports, and our new Strict TypeScript API. These are part of an ongoing effort to accurately define our API and offer dependable type safety to users and frameworks.

Quick takeaways:

Deep imports deprecation: From 0.80, we're introducing deprecation warnings for deep imports from the react-native package.
Opt-in Strict TypeScript API: We are moving to from-source TypeScript types and a new public API baseline under TypeScript. These enable stronger and more futureproof type accuracy, and will be a one-time breaking change. Opt in via compilerOptions in your project's tsconfig.json.
We'll work with the community over time to ensure that these changes work for everyone, before enabling the Strict TypeScript API by default in a future React Native release.

What's changing and why

We are moving to improve and stabilise React Native's public JavaScript API — i.e. what you get when you import 'react-native'.

Historically, we've approximated this. React Native is authored in Flow, but the community has long since moved to TypeScript in open source, which is how the public API is consumed and validated for compatibility. Our types have been (lovingly) community-contributed, and since merged and aligned in our codebase. However, these have relied on manual maintenance and no automated tooling, introducing correctness gaps.

Additionally, our public JS API has been poorly defined in terms of module boundaries — e.g. internal 'react-native/Libraries/' deep imports were reachable by app code, but could frequently change as we updated these internals.

In 0.80, we're addressing these issues by deprecating deep imports, and introducing a user opt-in to a new, generated API baseline in TypeScript. We're calling this our Strict TypeScript API. Ultimately, this is the groundwork to offer a stable React Native API in the future.

Deprecating deep imports from `react-native`

The main change we're making to our API today is deprecating the use of deep imports (RFC), with warnings in ESLint and the JS console. Deep imports of values and types should be updated to react-native's root import.

// Before - import from subpath
import {Alert} from 'react-native/Libraries/Alert/Alert';

// After - import from `react-native`
import {Alert} from 'react-native';

This change reduces the total surface area of our JavaScript API into a fixed set of exports which we can control and make stable in a future release. We're targeting a removal of these import paths in 0.82.

API feedback

Some APIs are not exported at root, and will become unavailable without deep imports. We have an open feedback thread and will be working with the community to finalize the exports in our public API. Please share your feedback!

Opting out

Please bear in mind that we aim to remove deep imports from React Native's API in a future release, and these should instead be updated to the root import.

Opting out of warnings

React Native 0.79 - Faster tooling and much more

Tue, 08 Apr 2025 00:00:00 GMT

Today we are excited to release React Native 0.79!

This release ships with performance improvements on various fronts, as well as several bugfixes. First, Metro is now faster to start thanks to deferred hashing, and has stable support for package exports. Startup time in Android will also be improved thanks to changes in the JS bundle compressions and much more.

Highlights

Metro: Faster startup and package exports support

This release ships with Metro 0.82.This version uses deferred hashing to improve the speed of first yarn start typically by over 3x (more in larger projects and monorepos) making your development experience and CI builds faster on a daily basis.

Also in Metro 0.82, we’re promoting package.json "exports" and "imports" field resolution to stable. "exports" resolution was introduced in React Native 0.72, and "imports" support was added in a community contribution - both will now be enabled by default for all the projects on React Native 0.79.

This improves compatibility with modern npm dependencies, and opens up new, standards-compliant ways to organise your projects.

Breaking change

While we've been testing package.json "exports" in the community for a while, this switchover can be a breaking change for certain packages and project setups.

In particular, we're aware of user reported incompatibilities for some popular packages including Firebase and AWS Amplify, and are working to get these fixed at source.

If you're encountering issues:

Please update to the Metro 0.81.5 hotfix, or set resolver.unstable_enablePackageExports = false to opt out.
See expo/expo#36551 for affected packages and future updates.

JSC moving to Community Package

As part of our effort to reduce the API surface of React Native, we're in the process of moving the JavaScriptCore (JSC) engine to a community-maintained package: @react-native-community/javascriptcore

This change will not affect users that are using Hermes.

Starting with React Native 0.79, you can use a community supported version of JSC by following the installation instructions in the readme. The JSC version provided by React Native core will still be available in 0.79, but we’re planning to remove it in the near future.

Moving JSC to a community maintained package will allow us to update the JSC version more frequently and offer you the latest features. The community maintained JSC will follow a separate release schedule from React Native.

iOS: Swift-Compatible Native Modules registration

In this release, we are revamping the way in which you can register your Native Module into the React Native runtime. The new approach follows the same approach of components, described in the official documentation.

Starting from this version of React Native, you can register your modules by modifying the package.json file. We introduced a new modulesProvider field in the ios property:

"codegenConfig": {
     "ios": {
+       "modulesProvider": {
+         "JS Name for the module": "ObjC Module provider for the pure C++ TM or a class conforming to RCTTurboModule"
+     }
    }
}

Codegen will take care to create all the relevant code starting from your package.json file.

If you do use a pure C++ Native Module you will have to follow this recommended configuration:

Configure pure C++Native Modules in your app

React Native 0.78 - React 19 and more

Wed, 19 Feb 2025 00:00:00 GMT

Today we are excited to release React Native 0.78!

This release ships React 19 in React Native and some other relevant features like native support for Android Vector drawables and better brownfield integration for iOS.

Highlights

React 19

React 19 is now available on React Native!

React 19 requires updating your app, as we introduced some changes from React 18. For example, we removed some APIs such as propTypes, and you need to adjust your app to make it compatible with the new version of React.

Follow our step-by-step instructions to upgrade your app to React 19.

After the migration, you’ll be able to leverage all the new features of React, including (non exhaustively):

Actions: these are functions that use async transitions. Async transitions automatically manage submitting data for you: they handle pending states, optimistic updates, error handling and more.
useActionState: a utility hook built on top of Actions. It takes a function and returns a wrapped Action to call. When the action is called, it will return the last result of the Action and its pending state.
useOptimistic: a new hook that simplifies showing the final state of an update optimistically while the async request is underway. If the request errors, React will switch back to the previous value automatically.
use: this is a new API that allows access to resources during render. You can now read a promise or a context with use and React will Suspend until they resolve.
ref as props: you can now pass ref as a prop like you do with any other prop. Function components will no longer need forwardRef and you can migrate your components now.
And many others

For a complete list of the new available features, have a look at the React 19 release blog post.

React Compiler

React Compiler is a build-time tool designed to optimize React applications by automatically applying memoization. While developers can manually use APIs like useMemo, useCallback, and React.memo to prevent unnecessary recomputation of unchanged parts of an app, they could also forget or misuse these optimizations. React Compiler addresses this by leveraging its understanding of JavaScript and of the Rules of React to automatically memoize values or groups of values within components and hooks.

With this release, we simplified the process to enable the React Compiler in your React Native apps. In previous versions, you had to install two packages: the compiler and its runtime. After those packages were installed, you had to configure a Babel plugin to enable React Compiler through Metro.

Now, you only need to install the compiler itself and to configure the Babel plugin. To learn how to enable it, you can follow our step-by-step guide.

To verify that the compiler is running, you can open the React Native DevTools: you should see that the components that are memoized have the Memo ✨ tag attached to them in the Component Inspector.

If you want to learn more about React Compiler, these are useful resources:

React Compiler docs
React Compiler Deep Dive

Towards smaller and faster releases

We’re updating our release process to ship stable React Native releases more frequently in 2025.

It will be easier for you to update the React Native version because we’ll be reducing the number of breaking changes we ship. Faster releases also means that all the bugfixes we ship internally are reaching you earlier, and you can benefit from the latest features we develop inside React Native.

We believe this new model will benefit every developer in the React Native ecosystem, as fewer breaking changes means a more stable framework that everyone can rely on.

Opt-in for JavaScript logs in Metro

We've added an opt-in to restore JavaScript log streaming via the Metro dev server, previously removed in 0.77 for Community CLI users. This is in response to user feedback, as well as reviewing where we are with our replacement offerings today.

To opt in, use the new --client-logs flag. This can also be aliased via an npm script for convenience.

npx @react-native-community/cli start --client-logs

Log streaming in Metro will still be going away in future and remains off by default. However, we intend to give developers a longer migration period to adapt to this change.

This update will also be made available in the incoming 0.77.1 minor release.

Added support for Android XML drawables

In React Native 0.78, we’re shipping a new way to load icons, illustrations, and other graphic elements on Android as XML resources. This means you can use vector drawables for displaying vector images at any scale without losing quality, or shape drawables for drawing more basic embellishments. This is all supported by the same Image component that you know and love. To use this feature today, you can import XML resources like any other static resource by referencing them in the source prop. Furthermore, using XML resources rather than bitmaps will also help you reduce your application size and will result in better rendering across screens with different DPI.

// via require
<Image
  source={require('./img/my_icon.xml')}
  style={{width: 40, height: 40}}
/>;

// or via import
import MyIcon from './img/my_icon.xml';
<Image source={MyIcon} style={{width: 40, height: 40}} />;

Performance & Quality

Like all other image types, Android’s XML resources are loaded and inflated off the main thread so you don’t drop any frames. This means the resource is not guaranteed to display instantly but also does not prevent user input while the resource is loading. Off-thread decoding is especially important when you need to render many icons at the same time. Internal apps realized some significant performance improvements when using Android’s vector drawables.

Utilizing resource types like vector drawables are the perfect way to display images without loss of quality, and can result in smaller APK files since you don't need to include an image type for every screen density. Furthermore, vector drawables are copied from memory once they’re loaded so if you render the same icon more than once they will all display at the same time.

Trade-offs

It’s important to note that drawable XML resources are not perfect, and there are constraints to using them:

They must be referenced at build time of your Android application. These resources are passed into a build step with the Android Asset Packaging Tool (AAPT) to convert raw XML into binary XML. Android does not support loading raw XML files, this is a known limitation.
They cannot be loaded over the network by Metro. If you change the directory or name of an XML resource, you will need to rebuild your Android application each time.
They have no dimensions. By default, they will display with a 0x0 size and you need to provide a width and height for them to show up.
They are not fully customizable at runtime; you can only control dimensions or the overall tint color but you can’t customize individual element attributes inside the resource like stroke widths, border radius, or colors. These types of customizations require different variants of your XML resource.

info

Android’s vector drawables are not a 1:1 replacement for libraries like react-native-svg. They are designed specifically for Android and do not work for iOS. If you want to have the same SVGs across all platforms, you'll have to continue using react-native-svg. Vector drawables merely offer performance benefits at the expense of customization.

ReactNativeFactory on iOS

With React Native 0.78 we improved the integration of React Native on iOS.

This version introduces a new class called RCTReactNativeFactory that allows you to create instances of React Native without the need of an AppDelegate. This should allow you to create a new version of React Native in a ViewController, for example. This simplifies dramatically the integration with Brownfield apps.

Imagine that you want to show a React Native view in a View Controller of your app. Starting from React Native 0.78, what you need to do, after installing all the dependencies as shown in this guide, is to add this code:

+import React
+import React_RCTAppDelegate

public class ViewController {

+  var reactNativeFactory: RCTReactNativeFactory?
+  var reactNativeDelegate: ReactNativeDelegate?

  public func viewdidLoad() {
    super.viewDidLoad()
    // …
+ reactNativeDelegate = ReactNativeDelegate()
+ reactNativeFactory = RCTReactNativeFactory(delegate: reactNativeDelegate!)
+ view = reactNativeFactory.rootViewFactory.view(withModuleName: "")
  }

}

+class ReactNativeDelegate: RCTDefaultReactNativeFactoryDelegate {

+  override func sourceURL(for bridge: RCTBridge) -> URL? {
+    self.bundleURL()
+  }
+
+  override func bundleURL() -> URL? {
+    #if DEBUG
+    RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
+    #else
+    Bundle.main.url(forResource: "main", withExtension: "jsbundle")
+    #endif
+  }
+}

React Native will be loaded in the View Controller as soon as you navigate to it.

This code creates an RCTReactNativeFactory, assigns a delegate to it, and asks it to create a rootView for a React Native’s view.

The delegate is defined below, and it overrides the sourceURL and the bundleURL properties to tell React Native where it can find the JS bundle to load in the view.

Other Breaking Changes

General

React Native DevTools
- Removed FuseboxClient CDP domain
Codegen
- Separate component array types and command array types

Android

Nullability changes: migrating RootView to Kotlin resulted in changes of parameter types from nullable to non nullable.
The following classes have been moved from public to internal, or removed, and can’t be accessed anymore:
- com.facebook.react.bridge.GuardedResultAsyncTask
- com.facebook.react.uimanager.ComponentNameResolver
- com.facebook.react.uimanager.FabricViewStateManager
- com.facebook.react.views.text.frescosupport.FrescoBasedReactTextInlineImageViewManager

iOS

Change Image load event size info from logical size to pixel (This only affects the Old Architecture)

Acknowledgements

React Native 0.78 contains over 509 commits from 87 contributors. Thanks for all your hard work!

Thanks to all the additional authors that worked on documenting features in this release post:

Dream11 team for the thorough testing of React 19 features in React Native
Nicola Corti for the work on Faster Releases
Alex Hunt for the work on the Metro logs opt-in
Peter Abbondanzo for the work on Android XML Drawable Support
Oskar Kwaśniewski for the work on the ReactNativeFactory

Upgrade to 0.78

Please use the React Native Upgrade Helper to view code changes between React Native versions for existing projects, in addition to the Upgrading docs.

To create a new project:

npx @react-native-community/cli@latest init MyProject --version latest

If you use Expo, React Native 0.78 will be supported in a canary release of the Expo SDK.

info

0.78 is now the latest stable version of React Native and 0.75.x moves to unsupported. For more information see React Native's support policy. We aim to publish a final end-of-life update of 0.75 in the near future.

React Native Core Contributor Summit 2024 Recap

Mon, 03 Feb 2025 00:00:00 GMT

Every year, the core contributors in the React Native Community get together with the React Native team to collaboratively shape the direction of this project.

Last year was no different—with small exception. We usually meet a day before React Universe Conf (formerly React Native EU) at Callstack HQ in Wrocław. In 2024, learning from past experiences, we hosted the Summit for two consecutive days, so that we can have more unstructured time together.

This annual tradition has become a valuable opportunity for contributors to share insights and voice their concerns, and for the core team to share their plans and gather feedback from key contributors to the React Native ecosystem—including partner companies, individual library authors and friends.

We divided the Summit into two tracks covering following topics:

In this blog post, we’d like to give you a sneak peek of the results of this gathering.

Releases

We had an extensive discussion about the release process for React Native. Core Team appreciates the value of having contributors from outside Meta involved in releases and emphasizes the importance of having nightly releases, which are particularly beneficial for Out-of-Tree platforms like React Native visionOS, library maintainers (Reanimated) and frameworks (Expo). We discussed the frequency of releases, with some folks asking for more frequent releases to ship fixes faster, while others expressed concerns about the impact on 3rd party libraries and upgrading efforts.

We also brainstormed ways to reduce unintentional breaking changes and improve communication about compatibility between React Native and 3rd party dependencies.

This session showed how complex it is to manage releases for React Native, and how delicate this topic is, given all the different parts of the ecosystem that need to be considered.

What's next after the New Architecture?

Now that the New Architecture has shipped as stable, we discussed what we should focus on next. What could be the next big thing? The topics revolved around:

Web compatibility – concluded in the discussion around direction of the React Strict DOM project, which should be treated as a temporary polyfill, while the Xplat team implements proper cross-platform functionality into the core of React Native.
Stabilizing the core API – turned out we need more consensus on what this means for app developers, library authors, Out-of-Tree platforms. E.g. it may be necessary to extract platform-native logic for iOS and Android from the shared C++ codebase. Part of which was covered by the LeanCore 2.0 discussion.
Old architecture support – as expected, the team confirmed that new React 19 features based on concurrent rendering, won’t work in old architecture. New features are primarily targeted for the new architecture. Due to blockers in React 19 release schedule it’s still not clear where to draw the line between functionality supported by both new and old architecture.
3rd party libraries for React Native – today we library authors can use TurboModules, ExpoModules, recently NitroModules to achieve the same goal of bridging native platform functionality. We need better documentation on how to make it well.
Brownfield docs – at the time of the summit, the official documentation for integrating React Native into native apps was quite dated. Since then the team has followed through with up-to-date and simpler docs for Android and iOS.
Tree-shaking for Metro web – core Metro team is open to merge the work from the Expo team in this area.

Web APIs for Native Modules

This session was dedicated to Microsoft's RFC revolving around the idea of bringing a subset of Web APIs to React Native. It aims to enhance React Native’s scalability and attract more web developers by leveraging familiar APIs. Opening access to a wealth of existing open-source web libraries that don't have explicit React Native support.

Standardizing on Web API specifications is not only beneficial but also essential for React Native growth, and aligns well with our Many Platforms vision and react-strict-dom project. The web offers a unified interface through its specifications, which React Native community modules currently lack. Microsoft has identified around 200 essential Web APIs that could be implemented first for platforms they support: iOS, Android, Windows and macOS.

We encourage library developers to align their APIs with web specifications whenever possible, as this standardization will improve code portability and developer experience across platforms.

While the proposal seems beneficial for the future of React Native, we're still brainstorming the next steps forward. One concern we noticed is governance of the APIs, and whether they’d need to live in a separate repository from the platform implementations. Another around diverging from the official specification in case a specific platform allows for behaviors not specified by the W3C. We would need to figure out how to avoid bundling unnecessary modules, e.g. with a Babel plugin. Not to mention the scope of such initiative is quite large.

The session conclusion reinforced two key points: First, there is strong alignment across the React Native community on adopting web-compatible specifications where possible. Second, we need to establish a clear technical strategy for how these Web API implementations can be maintained separately for different platforms. Microsoft together with Callstack could work on refining the original RFC and produce a proof of concept implementation for a smaller number of APIs as a community initiative. This incremental approach will help us validate the design and developer experience before expanding the scope.

LeanCore 2.0

In 2019, the React Native team started the Lean Core initiative. The goal was to tackle the surface area of React Native’s core and reduce APIs and components that were outdated and legacy. Since then, the React Native components and API surfaces have been long overdue another round of clean up.

Today, there are many components that are not actively being maintained with better community alternatives. Additionally, there are components that have duplicates that should eventually be consolidated for maintainability.

On the API side, a lot of the JS layer APIs are tied to native iOS & Android implementations, rather than being truly platform agnostic. For example, with Pressable, we have props like android_disableSound and android_ripple. Ideally, React Native components should have the smallest possible API surface that is not tied to any specific platform.

As Out-of-Tree platforms are growing and being adopted more by the ecosystem, there needs to be a path to reduce the component and API surface of React Native core, reducing the load on the React Native core team, and also making it significantly easier for Out-of-Tree platform & library maintainers to stay up-to-date.

As an added bonus, this would make it easier for beginner app developers to pick up React Native, as there are less duplicated components and "gotchas" for them to learn. Where there is a better community alternative, developers can be signposted and encouraged to use the community alternatives available.

During the session, we discussed:

The high level motivations of Lean Core and the benefits to the parties involved (developers, library maintainers, Meta)
An aggregated view of what components are being used in some real-world production React Native apps
The criteria of what is a candidate to be removed from core
A clear action plan for executing Lean Core 2.0 with:
- The high-level process for deprecation
- Handling cases where Meta is using components internally that have better community alternatives,

As a next step, a group of the core contributors will look at collecting more telemetry and data, assessing community alternatives, and putting together an RFC detailing the proposed changes.

Nitro Modules - Unblocking View Components by exposing props as jsi::Values

Recently, Marc Rousavy introduced Nitro Modules as an alternative approach to creating Native Modules. Nitro Modules utilize experimental C++ Swift Interop and incorporate a bunch of enhancements that can lead to improved performance in certain scenarios. However, during this session, we discussed the various trade-offs involved between Nitro Modules and existing TurboModules.

While Nitro Modules offer some performance benefits, they also have limitations and considerations that need to be addressed. For example, the use of experimental interop features might introduce complexity or compatibility issues that are not present in TurboModules. Our discussion focused on these trade-offs and the potential for upstreaming some of Nitro Modules' improvements into React Native Core, which could allow developers to benefit from more performant modules for everyone.

Out-of-Tree Platforms & CocoaPods

Out-of-Tree Platforms presents the full power of React Native, where we can share one JS codebase between different platforms running on our mobile devices, desktops or even on VR/XR devices. Creating such a platform currently isn’t the easiest process, actually there are no guidelines on how things should be created, developed and maintained. Also React Native Core in a way is tied to Android and iOS platforms. In the future we could aim for a scenario where all the platforms are treated equally and integrate with a C++/JS core through the same APIs.

During this session maintainers of different platforms discussed what are the problems, what they struggle with and what should be the solution to unify the process of creating and maintaining new Out-of-Tree platforms.

Another aspect of this session was to discuss CocoaPods and future plans related to managing native dependencies. Recently the CocoaPods team announced that they’ve moved to maintenance mode and new major improvements or features won’t be shipped. There are various alternatives that could be used and during this session we discussed their pros and cons, and what migration would look like.

React Native on Desktop

Steven and Saad from Microsoft, maintainers of react-native-windows and react-native-macos, hosted a session to listen and gather feedback from contributors related to Desktop platforms. Topics discussed included exploring how to increase adoption of React Native for Desktop (such as having a dedicated workflow in Visual Studio, or exposing desktop as part of Nx), as well as how to support Expo, which is a continual pain point for more adoption.

There’s a big discrepancy in availability of community modules between macOS and Windows, largely due to the fact that iOS code is mostly compatible with macOS, while RNW needs bespoke implementations. While working on the New Architecture for React Native for Windows, the team sees potential in C++ modules allowing for even more code sharing across platforms which will hopefully ease the burden of targeting desktop platforms. It’s worth noting that on the community side Software Mansion is working on adding desktop support for their most popular modules, such as React Native Screens, Gesture Handler and Reanimated.

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.

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!

React Native 0.77 - New Styling Features, Android’s 16KB page support, Swift Template

Tue, 21 Jan 2025 00:00:00 GMT

Today we are excited to release React Native 0.77!

This release ships several features: new styling capabilities such as support for display: contents, boxSizing, mixBlendMode, and outline-related properties to provide a more powerful layout options; Android 16KB page support to be compatible with the newer Android devices. We are also modernizing the community template by migrating it to Swift, while continuing to support and maintain compatibility with Objective-C for developers who prefer it.

Highlights

Breaking Changes

Removal of console.log() streaming in Metro

Highlights

New CSS Features for better layouts, sizing and blending

React Native 0.77 furthers our goal of aligning React Native with the web. We've added support for new CSS properties to give you more control over your app's layout, sizing, and blending. These changes can help simplify complex layouts, add texture, and make your app more accessible.

info

All these new features are available only for the New Architecture.

Simpler layouts with `display: contents`

The display: contents prop allows an element to disappear from the layout structure while its children are still rendered as if they were direct children of the parent element. It can be useful for styling purposes where you want to apply styles to child elements without affecting the layout, when building wrapper components which must handle events, or if you need to interact with the ShadowTree.

Technically speaking, display: contents renders an element without generating a layout box, but it preserves the layout boxes of the element’s children. The element with display: contents is effectively flattened out of the view hierarchy.

Let’s have a look at this example where we want to display an alert when a widget is pressed. We have a red Widget inside of a container view:

Container.jsx
function Container() {
  return (
    <View style={styles.container}>
      <Widget />
    View>
  );
}

Now, let's build a new Alerting wrapper component, with the goal of alerting the user when a component beneath it is pressed, using experimental pointer events. For clarity, the background of this component is made blue. That might look something like the component below:

Container.jsx
function Alerting({children}) {
  return (
    <View
      style={{backgroundColor: 'blue'}}
      onPointerDown={() => alert('Hello World!')}>
      {children}
    View>
}

function Container() {
  return (
    <View style={styles.container}>
      <Alerting>
        <Widget />
      Alerting>
    View>
  );
}

This doesn’t do quite what we want it to. Alerting adds a new layout box, with its own bounds, separate from the child Widget. Depending on the styling of the element it is wrapping, this may result in significant visual and functional changes. In this example, the blue background responds to taps with an alert when we want for only the red "Hello World" box to alert when tapped.

If we try this again, while setting display: contents on the View wrapper of Alerting, we only see alerts when the user presses within the original bounds of the Widget. This is because Alerting no longer adds its own box, but can still observe the pointer events bubbled from Widget.

Container.jsx
function Alerting({children}) {
  return (
    <View
      style={{display: 'contents'}}
      onPointerDown={() => alert('Hello World!')}>
      {children}
    View>
  );
}

// ... function Container ...

Box sizing

The boxSizing prop defines how the element's various sizing props (width, height, minWidth, minHeight, etc.) are computed. If boxSizing is border-box, these sizes apply to the border box of the element. If it is content-box they apply to the content box of the element. The default value is border-box, this is different from the default value on the web. The web documentation is a good source of information if you wish to learn more about how this prop works.

warning

border-box has been the default forever at this point, and has been the only boxSizing value up until we added content-box. Changing the default would have been a breaking change that would suddenly break several layouts. We decided to keep border-box as default value to ensure backward compatibility.

To understand the difference between border-box and content-box, have a look at these example, where both Views have padding: 20 and borderWidth: 10. When using border-box, we consider border and padding for the sizing; when using content-box, we consider only the content for the sizing.

CSS mixBlendMode

The mixBlendMode prop lets you control how an element blends its colors with the other elements in its stacking context. Check out the MDN documentation for a full overview of each blending function.

To help have more granular control about what is blending together, we also added the isolation property. Setting isolation: isolate on a View will force it to form a stacking context. So, you can set this on some ancestor View to ensure that some descendent View with mixBlendMode does not blend beyond the isolated View.

mixBlendMode Values

normal: The element is drawn on top of its background without blending.
multiply: The source color is multiplied by the destination color and replaces the destination.
screen: Multiplies the complements of the backdrop and source color values, then complements the result.
overlay: Multiplies or screens the colors, depending on the backdrop color value.
darken: Selects the darker of the backdrop and source colors.
lighten: Selects the lighter of the backdrop and source colors.
color-dodge: Brightens the backdrop color to reflect the source color. Painting with black produces no changes.
color-burn: Darkens the backdrop color to reflect the source color. Painting with white produces no change.
hard-light: Multiplies or screens the colors, depending on the source color value. The effect is similar to shining a harsh spotlight on the backdrop.
soft-light: Darkens or lightens the colors, depending on the source color value. The effect is similar to shining a diffused spotlight on the backdrop.
difference: Subtracts the darker of the two constituent colors from the lighter color.
exclusion: Produces an effect similar to that of the Difference mode but lower in contrast.
hue: Creates a color with the hue of the source color and the saturation and luminosity of the backdrop color.
saturation: Creates a color with the saturation of the source color and the hue and luminosity of the backdrop color.
color: Creates a color with the hue and saturation of the source color and the luminosity of the backdrop color. This preserves the gray levels of the backdrop and is useful for coloring monochrome images or tinting color images.
luminosity: Creates a color with the luminosity of the source color and the hue and saturation of the backdrop color. This produces an inverse effect to that of the Color mode.

Outline props

We’ve also introduced outlineWidth, outlineStyle, outlineSpread and outlineColor. These outline props work very similar to the respective border props, but it is rendered around the border box as opposed to around the padding box. These props allow to highlight elements by drawing their outline without affecting their layout.

Check out the MDN documentation for more details.

Android version 15 support & 16KB page support

Forced edge-to-edge on Android 15

We’ve already done some work to support Android 15 on the prior release. One of the noticeable changes in Android 15 is forced edge-to-edge display when you build apps with targetSdk 35.

If you have not looked into this yet, please refer to our prior recommendation on how this should be handled as ignoring this can potentially break your UI in the app.

note

If you are using the react-native-safe-area-context in your app, the library is already handling the forced edge-to-edge for you.

16 KB page size support for Android

Android 15 introduces support for 16KB memory page size enabling performance improvements for apps and more, but making previous 4KB-based apps potentially incompatible on future devices; it's currently an opt-in feature for developers to test on select devices to prepare for 16 KB page size being the OS default.

With the 0.77 release, React Native is ready to fully support 16 KB page size and developers will be able to test and ship apps for 16 KB devices using it.

Please refer to the official Android Developers site for further information on 16 KB support.

Community CLI and Template Updates

Community CLI: react-native init deprecation

This version fully completes the deprecation of the react-native init command that was introduced in React Native 0.75.

As a reminder, you won’t be able to use the react-native init command anymore, but you’ll have to either:

Use a framework such as Expo, with its own dedicated command to create a new project: npx create-expo-app
Invoke the Community CLI directly with npx @react-native-community/cli init

Community CLI: Removal of "run on iOS/Android" key handlers from Metro

In this version, we removed the ‘a’ and ‘i’ keyboard shortcuts from Metro. Those shortcuts were used to invoke the run-android & run-ios community CLI commands. Those keyboard shortcuts provided worse developer experience and were rarely used. Moreover, we believe that frameworks are better suited to orchestrate the terminal outputs.

You can read more about this change in this dedicated post.

Community Template: Swift as programming language for iOS apps

info

Projects using Expo should not be affected by this change.

This change let us slim down the community template by replacing three files (main.m, AppDelegate.h and AppDelegate.mm) with a single, new AppDelegate.swift.

This is technically a breaking change: you’ll see the change from Objective-C to Swift in the upgrade helper like this:

You don’t have to migrate to Swift: the Objective-C++ variant of the iOS community template is still supported (note that you still need to integrate the RCTAppDependencyProvider). New projects will be generated by using Swift as the iOS app language, although you can always migrate back to Objective-C if you need to.

Limitations

If your app has some local modules that are written in C++, you would not be able to register them in Swift as shown in this guide.

If your app falls in this category, please skip the migration of the AppDelegate to Swift, and keep using Objective-C++ for your app.

React Native core is mostly developed using C++ to encourage code sharing between iOS and Android and other platforms. The interoperability between Swift and C++ is not mature nor stable, yet. We are looking into ways to fill this gap and let you migrate to Swift too.

RCTAppDependencyProvider

React Native 0.77 slightly changes how the app loads third party dependencies. This is a new line in the community template that, if missed, can cause some runtime issues. Make sure to add it to your app.

The equivalent Objective-C lines are the following:

AppDelegate.mm
#import "AppDelegate.h"

#import <React/RCTBundleURLProvider.h>
#import <ReactAppDependencyProvider/RCTAppDependencyProvider.h>


@implementation AppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
  self.moduleName = @"";
  self.dependencyProvider = [RCTAppDependencyProvider new];
  // You can add your custom initial props in the dictionary below.
  // They will be passed down to the ViewController used by React Native.
  self.initialProps = @{};

  return [super application:application didFinishLaunchingWithOptions:launchOptions];
}

// remaining of the AppDelegate

Breaking Changes

Removal of `console.log()` streaming in Metro

We want every aspect of React Native debugging to behave reliably and to match the functionality of modern browser tooling. To meet this quality bar, log forwarding via Metro, originally deprecated in 0.76, is removed in 0.77.

This integration relied on a custom approach to communicate with the debugging target on device. With this change, we are moving exclusively to the Chrome DevTools Protocol (CDP).

To view JS logs, please use React Native DevTools and its fully featured Console panel — supporting log filtering, rich object inspection, Live Expressions, and more.
You can also connect VS Code as a CDP debugger, via third party extensions such as Expo Tools and Radon IDE.
- Please note that these integrations are not directly supported by the React team. However, we are working on first party VS Code support in 2025.
Expo continues to offer log streaming in Expo CLI.

For more info, see Why are JavaScript logs leaving Metro?

Other Breaking Changes

General

Animation
- Native looping animation do not send a React state update every time the loop ends.
Layout
- position of sticky headers on ScrollView will now be taken into account.
- Absolute positioning is now behaving in a more compliant way
JS Modules:
- Remove ReactFabricInternals module
  - This is not going to be accessible anymore
Native Modules
- NativeModules object can now be used to load turbomodules in JS .
  - This improves compatibility between Native Modules and Turbo Native Modules
Packages
- dev-middleware: Frameworks should specify serverBaseUrl relative to the middleware host
API Changes:
- Removed type for useConcurrentRoot from AppRegistry, as it was already ignored
- Removed refs property from NativeMethods TypeScript definition.
UX Changes:
- Remove "run on iOS" and "run on Android" from the dev server key commands

Android

Kotlin
- This is the first version of React Native that builds against Kotlin 2.0.21. You can read more about the changes coming with Kotlin 2.0 on the language release notes.
API Changes:
- Nullability:
  - Non-primitive getters in ReadableArray are now correctly typed as optional
  - Make ReactHost.createSurface() method non nullable
- Renamed:
  - DevSupportManagerBase.getCurrentContext() to DevSupportManagerBase.getCurrentReactContext()

Additionally, several APIs have been removed or restricted in visibility, so they can’t be accessed anymore. Those APIs were internal and not needed to React Native developers directly. You can find the full list below:

List of Removed Android APIs:

New Architecture is here

Wed, 23 Oct 2024 16:01:00 GMT

React Native 0.76 with the New Architecture by default is now available on npm!

In the 0.76 release blog post, we shared a list of significant changes included in this version. In this post, we provide an overview of the New Architecture and how it shapes the future of React Native.

The New Architecture adds full support for modern React features, including Suspense, Transitions, automatic batching, and useLayoutEffect. The New Architecture also includes new Native Module and Native Component systems that let you write type-safe code with direct access to native interfaces without a bridge.

This release is the result of a ground-up rewrite of React Native we’ve been working on since 2018, and we’ve taken extra care to make the New Architecture a gradual migration for most apps. In 2021, we created the New Architecture Working Group to collaborate with the community on ensuring a smooth upgrade experience for the entire React ecosystem.

Most apps will be able to adopt React Native 0.76 with the same level of effort as any other release. The most popular React Native libraries already support the New Architecture. The New Architecture also includes an automatic interoperability layer to enable backward compatibility with libraries targeting the old architecture.

Over the past several years of development, our team has publicly shared our vision for the New Architecture. If you missed any of these talks, check them out here:

What is the New Architecture

The New Architecture is a complete rewrite of the major systems that underpin React Native, including how components are rendered, how JavaScript abstractions communicates with native abstractions, and how work is scheduled across different threads. Although most users should not have to think about how these systems work, these changes bring improvements and new capabilities.

In the old architecture, React Native communicated with the native platform using an asynchronous bridge. To render a component or call a native function, React Native needed to serialize and enqueue native functions calls with the bridge, which would be processed asynchronously. The benefit of this architecture is that the main thread was never blocked for rendering updates or handling native module function calls, since all work was done on a background thread.

However, users expect immediate feedback to interactions to feel like a native app. This means some updates need to render synchronously in response to user input, potentially interrupting any in-progress render. Since the old architecture was only asynchronous, we needed to rewrite it to allow for both asynchronous and synchronous updates.

Additionally, in the old architecture, serializing function calls over the bridge quickly became a bottleneck, especially for frequent updates or large objects. This made it hard for apps to achieve 60+ FPS reliably. There were also synchronization issues: when the JavaScript and native layer got out of sync, it was impossible to reconcile them synchronously, resulting bugs like lists showing frames of empty space and visual UI jumps due to intermediate states rendering.

Finally, since the old architecture kept a single copy of the UI using the native hierarchy, and mutated that copy in place, layout could only be computed on a single thread. This made it impossible to process urgent updates like user inputs, and layout could not be read synchronously, such as reading in a layout effect to update the position of a tooltip.

All of these problems meant that it was not possible to properly support React’s concurrent features. To solve these problems, the New Architecture includes four main parts:

The New Native Module System
The New Renderer
The Event Loop
Removing the Bridge

The New Module system allows the React Native Renderer to have synchronous access to the native layer, which allows it to handle events, schedule updates, and read layout both asynchronously and synchronously. The new Native Modules are also lazily loaded by default, giving apps a significant performance gain.

The New Renderer can handle multiple in progress trees across multiple threads, which allows React to process multiple concurrent update priorities, either on the main thread or a background thread. It also supports reading layout from multiple threads synchronously or asynchronously, to support more responsive UIs without jank.

The new Event Loop can process tasks on the JavaScript thread in a well-defined order. This allows React to interrupt rendering to process events so urgent user events can take priority over lower priority UI transitions. The Event Loop also aligns with web specifications, so we can support for browser features like microtasks, MutationObserver, and IntersectionObserver.

Finally, removing the bridge allows for faster startup and direct communication between JavaScript and the native runtime, so that the cost of switching work is minimized. This also allows for better error reporting, debugging, and reducing crashes from undefined behavior.

The New Architecture is now ready to be used in production. It is already used at scale at Meta in the Facebook app and in other products. We successfully used React Native and the New Architecture in the Facebook and Instagram app we developed for our Quest devices.

Our partners have already been using the New Architecture in production for months now: have a look at these success stories by Expensify and Kraken, and give Bluesky a shot with their new release.

New Native Modules

The new Native Module System is a major rewrite of how JavaScript and the native platform communicate. It’s written entirely in C++, which unlocks many new capabilities:

Synchronous access to and from the native runtime
Type safety between JavaScript and native code
Code sharing across platforms
Lazy module loading by default

In the new Native Module system, JavaScript and the native layer can now synchronously communicate with each other through the JavaScript Interface (JSI), without the need to use an asynchronous bridge. This means your custom Native Modules can now synchronously call a function, return a value, and pass that value back to another Native Module function.

In the old architecture, in order to handle a response from native function calls, you needed to provide a callback, and the value returned needed to be serializable:

// ❌ Sync callback from Native Module
nativeModule.getValue(value => {
  // ❌ value cannot reference a native object
  nativeModule.doSomething(value);
});

In the New Architecture, you can make synchronous calls to native functions:

// ✅ Sync response from Native Module
const value = nativeModule.getValue();

// ✅ value can be a reference to a native object
nativeModule.doSomething(value);

With the New Architecture, you can finally leverage the full power of a C++ native implementation while still accessing it from JavaScript/TypeScript APIs. The New Module System supports modules written in C++ so you can write your module once, and it works across all platforms, including Android, iOS, Windows, and macOS. Implementing modules in C++ allows for more fine-grained memory management and performance optimizations.

Additionally, with Codegen, your modules can define a strongly typed contract between the JavaScript layer and the native layer. From our experience, cross-boundary type errors are one of the most common sources of crashes in cross-platform apps. Codegen lets you overcome those problems while also generating boilerplate code for you.

Finally, modules are now lazily loaded: they are loaded in memory only when they’re effectively needed rather than at startup. This reduces the app startup time and keeps it low as the application grows in complexity.

Popular libraries such as react-native-mmkv have already seen benefits from migrating to the new Native Modules:

“The new Native Modules greatly simplified setup, autolinking, and initialization for react-native-mmkv. Thanks to the New Architecture, react-native-mmkv is now a pure C++ Native Module, which allows it to work on any platform. The new Codegen allows MMKV to be fully type-safe, which fixed a long-standing NullPointerReference issue by enforcing null-safety, and being able to call Native Module functions synchronously allowed us to replace custom JSI access with the new Native Module API.”

Marc Rousavy, creator of react-native-mmkv

New Renderer

We've also completely rewritten the Native Renderer, adding several benefits:

Updates can be rendered on different threads at different priorities.
Layout can be read synchronously and across different threads.
The renderer is written in C++ and shared across all platforms.

The updated Native Renderer now stores the view hierarchy in an immutable tree structure. This means that the UI is stored in a way that cannot be changed directly, allowing for thread-safe processing of updates. This allows it to handle multiple in-progress trees, each representing a different version of the user interface. As a result, updates can be rendered in the background without blocking the UI (such as during transitions) or on the main thread (in response to user input).

By supporting multiple threads, React can interrupt a low-priority update to render an urgent one, such as those generated by user inputs, and then resume the low-priority update as needed. The new renderer can also read layout information synchronously and across different threads. This enables background computation for low-priority updates and synchronous reads when needed, such as repositioning a tooltip.

Finally, rewriting the renderer in C++ allows it to be shared across all platforms. This ensures that the same code runs on iOS, Android, Windows, macOS, and any other React Native-supported platform, providing consistent rendering capabilities without needing re-implementation for each platform.

This is a significant step towards our Many Platform Vision. For example, View Flattening was an Android-only optimisation to avoid deep layout trees. The new renderer, with shared C++ core, brings this feature to iOS. This optimisation is automatic and does not require setup, it comes for free with the shared renderer.

With these changes, React Native now fully supports Concurrent React features like Suspense and Transitions, making it easier to build complex user interfaces that respond quickly to user input without jank, delays, or visual jumps. In the future, we will leverage these new capabilities to bring more improvements to built-in components such as FlatList and TextInput.

Popular libraries like Reanimated are already taking advantage of the New Renderer:

“Reanimated 4, currently in development, introduces a new animation engine that works directly with the New Renderer, allowing it to handle animations and manage layout across different threads. The New Renderer’s design is what truly enables these features to be built without relying on numerous workarounds. Moreover, because it’s implemented in C++ and shared across platforms, large portions of Reanimated can be written once, reducing platform-specific issues, minimizing the codebase, and streamlining adoption for out-of-tree platforms.”

Krzysztof Magiera, creator of Reanimated

The Event Loop

The New Architecture allowed us to implement a well-defined event loop processing model, as described in this RFC. This RFC follows the specifications described in the HTML Standard, and it describes how React Native should perform tasks on the JavaScript thread.

Implementing a well-defined event loop closes gaps between React DOM and React Native: the behavior of a React Native application is now closer to the behavior of a React DOM application, making it easier to learn once, and write anywhere.

The event loop brings many benefits to React Native:

The ability to interrupt rendering to process events and tasks
Closer alignment with web specifications
Foundation for more browser features

With the Event Loop, React is able to predictably order updates and events. This allows React to interrupt a low priority update with an urgent user event, and the New Renderer allows us to render those updates independently.

The Event Loops also aligns the behavior of events and task like timers with web specifications, which means React Native works more like what users are familiar with in the Web, and allows for better code sharing between React DOM and React Native.

It also allows for the implementation of more compliant browser features like microtasks, MutationObserver, and IntersectionObserver. These features are not ready to use in React Native yet, but we are working on bringing them to you in the future.

Finally, the Event Loop and the New Renderer changes to support reading layout synchronously allow React Native to add proper support for useLayoutEffect to read layout information synchronously and update the UI in the same frame. This allows you to position elements correctly before they are displayed to the user.

See useLayoutEffect for more details.

Removing the Bridge

In the New Architecture, we've also fully removed React Native's dependency on the bridge, replacing it with direct, efficient communication between JavaScript and native code using JSI:

Removing the bridge improves startup time by avoiding bridge initialization. For example, in the old architecture, in order to provide global methods to JavaScript, we would need to initialize a module in JavaScript on startup, causing a small delay in app startup time:

// ❌ Slow initialization
import {NativeTimingModule} from 'NativeTimingModule';
global.setTimeout = timer => {
  NativeTimingModule.setTimeout(timer);
};

// App.js
setTimeout(() => {}, 100);

In the New Architecture, we can directly bind methods from C++:

// ✅ Initialize directly in C++
runtime.global().setProperty(runtime, "setTimeout", createTimer);

// App.js
setTimeout(() => {}, 100);

The rewrite also improves error reporting, particularly for JavaScript crashes at startup, and reduces crashes from undefined behavior. If crashes occur, the new React Native DevTools simplify debugging and support the New Architecture.

The bridge remains for backward compatibility to support gradual migration to the New Architecture. In the future, we will remove the bridge code completely.

Gradual Migration

We expect most apps can upgrade to 0.76 with the same effort as any other release.

When you upgrade to 0.76, the New Architecture and React 18 are enabled by default. However, to use concurrent features and gain the full benefits of the New Architecture, your app and libraries will need to be gradually migrated to fully support the New Architecture.

When you first upgrade, your app will run on the New Architecture with an automatic interoperability layer with the old architecture. For most apps, this will work without any changes, but there are known limitations with the interop layer, as it does not support accessing custom Shadow Nodes or concurrent features.

To use concurrent features, apps will also need to be updated to support Concurrent React by following the Rules of React. To migrate your JavaScript code to React 18 and its semantics, follow the React 18 Upgrade guide.

The overall strategy is to get your application running on the New Architecture without breaking existing code. You can then gradually migrate your app at your own pace. For new surfaces that have migrated all modules to the New Architecture, you can start using concurrent features immediately. For existing surfaces, you may need to address some issues and migrate modules before adding concurrent features.

We've collaborated with the most popular React Native libraries to ensure support for the New Architecture. More than 850 libraries are already compatible, including all libraries with over 200K weekly downloads (~10% of downloaded libraries). You can check library compatibility with the New Architecture on the reactnative.directory website:

For more details on upgrading, see How to Upgrade below.

New Features

The New Architecture includes full support for React 18, concurrent features, and useLayoutEffect in React Native. For a full list of React 18 features, please see the React 18 blog post.

Transitions

Transitions are a new concept in React 18 to distinguish between urgent and non-urgent updates.

Urgent updates reflect direct interaction, like typing and pressing.
Transition updates transition the UI from one view to another.

Urgent updates need immediate response to match our intuitions about how physical objects behave. However, transitions are different because the user doesn’t expect to see every intermediate value on screen. In the New Architecture, React Native is able to support rendering urgent updates and transition updates separately.

Typically, for the best user experience, a single user input should result in both an urgent update and a non-urgent one. Similar to ReactDOM, events like press or change are handled as urgent and rendered immediately. You can use the startTransition API inside an input event to inform React which updates are “transitions” and can be deferred to the background:

import {startTransition} from 'react';

// Urgent: Show the slider value
setCount(input);

// Mark any state updates inside as transitions
startTransition(() => {
  // Transition: Show the results
  setNumberOfTiles(input);
});

Separating urgent events from transitions allows for a more responsive user interface, and a more intuitive user experience.

Here's a comparison of the old architecture without transitions and the new architecture with transitions. Imagine that each tile isn't a trivial view with a background color, but a rich component containing images and other components that are expensive to render. After using useTransition you avoid thrashing your app with updates and falling behind.

Before: rendering tiles without marking it as a transition.

After: rendering tiles with transitions to interrupt in-progress renders of stale state.

For more information, see Support for Concurrent Renderer and Features.

Automatic Batching

When upgrading to the New Architecture, you will benefit from automatic batching from React 18.

Automatic batching allows React to batch together more state updates when rendering to avoid the rendering of intermediate states. This allows React Native to be faster and less susceptible to lags, without any additional code from the developer.

Before: rendering frequent state updates with legacy renderer.

After: rendering frequent state updates with automatic batching.

In the old architecture, more intermediate states are rendered, and the UI keeps updating even when the slider stops moving. The New Architecture, renders fewer intermediate states and completes the rendering much sooner thanks to automatically batching the updates.

For more information, see Support for Concurrent Renderer and Features.

useLayoutEffect

Building on the Event Loop and the ability to read layout synchronously, in the New Architecture we added proper support for useLayoutEffect in React Native.

In the old architecture, you needed to use the asynchronous onLayout event to read layout information of a view (which was also asynchronous). As a result there would be at least one frame where the layout was incorrect until the layout was read and updated, causing issues like tooltips placed in the wrong position:

// ❌ async onLayout after commit
const onLayout = React.useCallback(event => {
  // ❌ async callback to read layout
  ref.current?.measureInWindow((x, y, width, height) => {
    setPosition({x, y, width, height});
  });
}, []);

// ...
<ViewWithTooltip
  onLayout={onLayout}
  ref={ref}
  position={position}
/>;

The New Architecture fixes this by allowing synchronous access to layout information in useLayoutEffect:

// ✅ sync layout effect during commit
useLayoutEffect(() => {
  // ✅ sync call to read layout
  const rect = ref.current?.getBoundingClientRect();
  setPosition(rect);
}, []);

// ...
<ViewWithTooltip ref={ref} position={position} />;

This change allows you to read layout information synchronously and update the UI in the same frame, allowing you to position elements correctly before they are displayed to the user:

In the old architecture, layout was read asynchronously in onLayout, causing the position of the tooltip to be delayed.

In the New Architecture, layout can be read in useLayoutEffect synchronously, updating the tooltip position before displaying.

For more information, see the docs for Synchronous Layout and Effects.

Full Support for Suspense

Suspense lets you declaratively specify the loading state for a part of the component tree if it’s not yet ready to be displayed:

<Suspense fallback={<Spinner />}>
  <Comments />
Suspense>

We introduced a limited version of Suspense several years ago, and React 18 added full support. Until now, React Native was not able to support concurrent rendering for Suspense.

The New Architecture includes full support for Suspense introduced in React 18. This means that you can now use Suspense in React Native to handle loading states for your components, and the suspended content will render in the background while the loading state is displayed, giving higher priority to user input on visible content.

For more, see the RFC for Suspense in React 18.

How to Upgrade

To upgrade to 0.76, follow the steps in the release post. Since this release also upgrades to React 18, you will also need to follow the React 18 Upgrade guide.

These steps should be enough for most apps to upgrade to the New Architecture thanks to the interop layer with the old architecture. However, to take full advantage of the New Architecture and to start using concurrent features, you will need to migrate your custom Native Modules and Native Components to support the new Native Module and Native Component APIs.

Without migrating your custom Native Modules, you will not get the benefits of shared C++, synchronous method calls, or type-safety from codegen. Without migrating your Native Components, you will not be able to use concurrent features. We recommend migrating all Native Components and Native Modules to the New Architecture as soon as possible.

note

In a future release, we will remove the interop layer and modules will need to support the New Architecture.

Apps

If you are an app developer, to fully support the New Architecture, you will need to upgrade your libraries, custom Native Components, and custom Native Modules to fully support the New Architecture.

We've collaborated with the most popular React Native libraries to ensure support for the New Architecture. You can check library compatibility with the New Architecture on the reactnative.directory website.

If any of the libraries your app depends on are not compatible yet, you can:

Open an issue with the library and ask the author to migrate to the New Architecture.
If the library is not maintained, consider alternative libraries with the same features.
Opt-out from the New Architecture while those libraries are migrated.

If your app has custom Native Modules or custom Native Components, we expect them to work fine, thanks to our interop layer. However, we recommend upgrading them to the new Native Module and Native Component APIs to fully support the New Architecture and adopt concurrent features.

Please follow these guides to migrate your modules and components to the New Architecture:

Libraries

If you are a library maintainer, please first test that your library works with the interop layer. If it does not, please open an issue on the New Architecture Working Group.

To fully support the New Architecture, we recommend migrating your library to the new Native Module and Native Component APIs as soon as possible. This will allow users of your library to take full advantage of the New Architecture and support concurrent features.

You can follow these guides to migrate your modules and components to the New Architecture:

Opt-out

If, for any reason, the New Architecture is not behaving properly in your application, there is always the option to opt-out from it until you are ready to turn it on again.

To opt-out from the New Architecture:

On Android, modify the android/gradle.properties file and turn off the newArchEnabled flag:

-newArchEnabled=true
+newArchEnabled=false

On iOS, you can reinstall the dependencies by running the command:

RCT_NEW_ARCH_ENABLED=0 bundle exec pod install

Thanks

Delivering the New Architecture to the OSS community has been a huge effort that took us several years of research and development. We want to take a moment to thank all the current and past members of the React team who helped us achieve this result.

We are also extremely grateful to all the partners who collaborated with us to make this happen. Specifically, we would like to call out:

Expo, for adopting the New Architecture early on, and for supporting the work on migrating the most popular libraries.
Software Mansion, for maintaining crucial libraries in the ecosystem, for migrating them to the New Architecture early and for all the help in investigating and fixing various issues.
Callstack, for maintaining crucial libraries in the ecosystem, for migrating them to the New Architecture early and for the support with the work on the Community CLI.
Microsoft, for adding the New Architecture implementation for react-native-windows and react-native-macos as well as in several other developer tools.
Expensify, Kraken, Bluesky and Brigad for pioneering the adoption of the New Architecture and reporting various issues so that we could fix them for everyone else.
All the independent library maintainers and developers who contributed to the New Architecture by testing it, fixing some of the issues, and opening questions on unclear matters so that we could clear them.

React Native 0.76 - New Architecture by default, React Native DevTools, and more

Wed, 23 Oct 2024 16:00:00 GMT

Today we are excited to release React Native 0.76!

This is a major milestone for React Native, as we’re enabling the New Architecture by default, and we’re introducing React Native DevTools. This has been the culmination of 6 years of hard work from our team, together with the support of our incredible community of developers.

Highlights

Breaking Changes

Highlights

React Native New Architecture by default

Starting from React Native 0.76, the New Architecture is enabled by default in your projects. The New Architecture is a rewrite of the internals of React Native to enable app developers to develop high quality native applications using React.

Today, we’re excited to declare the New Architecture ready for production use.

This change is a milestone in the evolution of React Native, and we invite you to read the dedicated blogpost to understand what's included in the New Architecture and how it will shape the future of React Native: The New Architecture is Here.

React Native DevTools

We're releasing the first stable version of React Native DevTools, our new default debugging experience.

We want the tooling you use to debug React across all platforms to be reliable, familiar, simple, and cohesive. React Native DevTools delivers on these principles — browser-aligned developer tools that are deeply integrated with React Native. Key features include:

Familiar, web-aligned tooling — A fully featured debugger based on Chrome DevTools with reliable breakpoints, watch values, step-through debugging, stack inspection, and a rich JavaScript console. These core features now work reliably and across reloads.
Improved and integrated React DevTools — The built-in React Components Inspector and Profiler work seamlessly, with faster and more reliable component highlighting.
Improved UX — See a new Paused in Debugger overlay, making it clear when your app is paused on a breakpoint. Warnings in LogBox are now displayed as a summary, and hidden when DevTools is attached.
Fixed reconnection behaviour — JavaScript breakpoints now work reliably across reloads and when DevTools is disconnected and reattached. DevTools can even reconnect to the same app after a native rebuild.
Instant launch — React Native DevTools is ready by default with zero config. Open it from the in-app Dev Menu or via j to debug in the CLI server, which now supports multiple emulators and devices.

React Native DevTools is fundamentally different from our previous debugging options, including being different from the Experimental Debugger experience first shipped in 0.73. It switches to a new backend debugging stack that we’ve rebuilt over the last year. This means that compatibility with previous tooling has changed, and you should also expect a much more reliable experience end-to-end. We intend to build upon this new stack to allow us to reliably implement more features in future, such as the Performance and Network panels.

Phasing out logs in Metro

In our next release, we're removing forwarded logs in Metro to align with modern browser tooling, and remove old debugging integrations. Instead, use React Native DevTools' fully featured Console panel for logging. See more under our FAQs.

Links

Faster Metro resolution

We've shipped several performance improvements to Metro's resolver, the component responsible for finding a module from an import path, making it around 15x faster. This improves the overall performance of Metro, particularly for warm builds, which we've seen at around 4x faster.

Box Shadow and Filter style props

We’ve added two New Architecture only style props in 0.76 - boxShadow and filter. Both of these props exist on the web, and the team stick to the specs when possible so that these props are predictable, familiar, and ultimately easier to adopt (see the limitations and spec deviations sections for the exceptions). As a result, you can look up the web documentation to fully understand how these work, but there are a few important differences which are noted below.

`boxShadow`

boxShadow adds a shadow to an element, with the ability to control the position, color, size, and blurriness of the shadow. Check out the MDN documentation for a full overview of each of these arguments, along with a fiddle to try them out for yourself. Below are a few examples of the shadows you can make.

boxShadow can take either a string, which mimics the CSS syntax, or JS objects which can embed variables. For example the string ‘5 5 5 0 rgba(255, 0, 0, 0.5)’ and the object {offsetX: 5, offsetY: 5, blurRadius: 5, spreadDistance: 0, color: ‘rgba(255, 0, 0, 0.5)’} would yield the same box shadow.

The previous shadow functionality had some shortcomings addressed now addressed by boxShadow:

Does not work on Android
Cannot be inset
Does not have spread
Does not work on Views if there is no background color
Is a separate prop, so it cannot share the same web syntax

Limitations & Spec Deviations

The default shadow color is black, not the parent’s color
Android normal shadows are supported on Android 9+
Android inset shadows are supported on Android 10+

`filter`

filter adds certain graphical filters to an element. There are a mix of color filters that let you modify things like brightness, saturation, and hue as well as non-color filters that let you add blurs and shadows. Check out the MDN documentation for a full overview of each individual filter function, along with a fiddle to try them out for yourself. Below is a hot dog image with various filters applied to it.

From left to right: no filter, saturate filter, blur filter, invert filter

Like boxShadow, filter can take either a string, which mimics the CSS syntax, or an array of JS objects which can embed variables. For example the string ‘saturate(0.5) grayscale(0.25)’ and the array [{saturate: 0.5}, {grayscale: 0.25}] would yield the same filter. filter has a dropShadow value which varies slightly from boxShadow. The biggest difference is that dropShadow is an alpha mask - so the shadow will only be cast by a pixel if it has a nonzero alpha component. boxShadow, on the other hand, will cast around the border box of the element, even if nothing is inside of it. Additionally, dropShadow does not have a spread distance parameter and cannot be inset (shadow cast inside of the element).

Limitations and Spec Deviations

iOS filter only supports brightness and opacity
iOS filter will not apply to shadows, outlines, or any other graphical elements outside the bounds of the element
Android blur and drop-shadow are only supported on Android 12+
filter implies overflow: hidden, so children of an element with a filter will be clipped if they are positioned outside of the parents bounds.

Breaking Changes

Removed the dependency on the @react-native-community/cli

As previously shared in 0.75, our vision is for React Native to be framework agnostic. Therefore, we completed the work to remove @react-native-community/cli as a direct dependency of React Native.

Decoupling React Native from the CLI allows us to move faster through releasing these projects independently and to better separate the responsibilities of both projects.

If you are relying on the CLI in your daily workflow, make sure to explicitly add the dependency on the CLI in your package.json:

//…
  “devDependencies”: {
   // …
+  “@react-native-community/cli”: “15.0.0”,
+  "@react-native-community/cli-platform-android": “15.0.0”,
+  "@react-native-community/cli-platform-ios": “15.0.0”,
  },

Android Apps are ~3.8Mb smaller thanks to Native Library merging

React Native 0.76 will ship with a reduced number of native libraries, as we merged a lot of our native code into a single library called libreactnative.so.

This change comes with reduction in app size, and improvement in app startup performance on Android. From our benchmarks, we found out that App size will be reduced by ~3.8MB (20% of the total) and median App startup time will be reduced by ~15ms (~8%) (source).

On the other hand, this is a breaking change for both app and library developers.

App developers will have to update their Application’s onCreate as follows:

+import com.facebook.react.soloader.OpenSourceMergedSoMapping
import com.facebook.soloader.SoLoader

class MainApplication : Application(), ReactApplication {

  override fun onCreate() {
    super.onCreate()
+   SoLoader.init(this, OpenSourceMergedSoMapping)
-   SoLoader.init(this, false)
  }
}

This change is necessary in order to properly load libreactnative.so and is included in the upgrade-helper.

Library authors won’t be affected by this change, unless you have custom C++ code.

For a technical deep dive into this change, and suggestions for library authors, you can read more about it in the dedicated post.

Updates to Minimum iOS and Android SDK requirements

We have updated our minimum platform and SDK versions:

iOS - from 13.4 to 15.1
Android - from SDK 23 to SDK 24 (Android 7)

This change was announced earlier in the year when 0.75 was released. For more background, please see the dedicated posts for Android and iOS.

Other Breaking Changes

Animation
- Stop sending state updates to React in looping animation. This was causing unnecessary re-rendering with looping animations.
devtools:
- Remove Inspector Panel perf + network tabs under New Arch. (RFC)
text engine
- Always use AttributedStringBox instead of AttributedString in TextLayoutManager

Android

rendering:
- View backgrounds are no longer directly ReactViewBackgroundDrawable or CSSBackgroundDrawable

iOS

turbomodule
- Removed the RCT_EXPORT_CXX_MODULE_EXPERIMENTAL Macro for autolinking pure Cxx module.

Acknowledgements

React Native 0.76 contains over 1070 commits from 156 contributors. Thanks for all of your hard work!

Thanks to all the additional authors that worked on documenting features in this release post:

Joe Vilches and Nick Gerleman box-shadow and filter style props.
Alex Hunt React Native DevTools.
Nicola Corti Android shipping as a single library.

Upgrade to 0.76

Please use the React Native Upgrade Helper to view code changes between React Native versions for existing projects, in addition to the Upgrading docs.

If you use Expo, React Native 0.76 will be supported in Expo SDK 52.

If you need to create a new project using the CLI, you can run this command:

npx @react-native-community/cli@latest init MyProject --version latest

info

0.76 is now the latest stable version of React Native and 0.73.x moves to unsupported. For more information see React Native's support policy. We aim to publish a final end-of-life update of 0.73 in the near future.

React Native 0.75 - Support for Percentage Values in Layout, New Architecture Stabilization, Template & init Updates, and more

Wed, 14 Aug 2024 00:00:00 GMT

Today we are excited to release React Native 0.75!

This release ships several features, such as Yoga 3.1 with support for % values, several stabilization fixes for the New Architecture, and the introduction of the recommendation for users to use a React Native Framework.

Highlights

Breaking Changes

Highlights

Yoga 3.1 and Layout Improvements

Since we last shipped Yoga version 3.0 in React Native 0.74, we kept on pushing many improvements and new layout capabilities for your applications. React Native 0.75 ships with Yoga 3.1 and you can learn more about what’s new in the official Yoga’s release blog post.

One notable and highly requested feature is the support for % values in various places, such as gaps and translation

info

These features are available only for the New Architecture. If you are keen to use them, please consider migrating to it.

Percentage Values in Gaps

With 0.75, the gap, columnGap and rowGap props described here now support a string with a % value.

For example:

function App(): React.JSX.Element {
  return (
    <SafeAreaView
      style={{
        marginTop: 20,
        alignItems: 'center',
        flex: 1,
        rowGap: '20%',
      }}>
      <View
        style={{flex: 1, flexDirection: 'row', columnGap: '10%'}}>
        <View
          style={{
            backgroundColor: 'purple',
            width: 100,
            height: 100,
          }}
        />
        <View
          style={{
            backgroundColor: 'blue',
            width: 100,
            height: 100,
          }}
        />
        <View
          style={{
            backgroundColor: 'green',
            width: 100,
            height: 100,
          }}
        />
      View>
      <View
        style={{flex: 1, flexDirection: 'row', columnGap: '10%'}}>
        <View
          style={{
            backgroundColor: 'lime',
            width: 100,
            height: 100,
          }}
        />
        <View
          style={{
            backgroundColor: 'yellow',
            width: 100,
            height: 100,
          }}
        />
        <View
          style={{
            backgroundColor: 'orange',
            width: 100,
            height: 100,
          }}
        />
      View>
      <View
        style={{flex: 1, flexDirection: 'row', columnGap: '10%'}}>
        <View
          style={{
            backgroundColor: 'red',
            width: 100,
            height: 100,
          }}
        />
        <View
          style={{
            backgroundColor: 'violet',
            width: 100,
            height: 100,
          }}
        />
        <View
          style={{
            backgroundColor: 'magenta',
            width: 100,
            height: 100,
          }}
        />
      View>
    SafeAreaView>
  );
}

Will be rendered as follows:

Android	iOS

Percentage values in Translation

The transform prop can also now accept % as values for the translate transformations.

For example, the following component would move the red square’s X coordinate by 100% of its width and the Y coordinate by 100% of its height:

function Translated() {
  return (
    <SafeAreaView
      style={{
        marginTop: 20,
        flex: 1,
        rowGap: '20%',
      }}>
      <View
        style={{
          backgroundColor: 'red',
          width: 100,
          height: 100,
          transform: [{translateY: '100%'}, {translateX: '100%'}],
        }}
      />
    SafeAreaView>
  );
}

Will be rendered as follows:

Android	iOS

New Architecture Stabilization

Since our announcement of the New Architecture being in Beta at React Conf, we shipped several bug fixes and improvements to its stability.

Our goal is for the New Architecture to be considered stable in the near future. Therefore, in the last few months we focused on bridging the gaps between the Old and the New Architecture. Some examples of bugs and missing features we fixed are:

Fix adjustsFontSizeToFit on Android (#44075)
Fix textAlign not working with inline views on Android (#44146)
Fix text baseline being moved up on iOS (#44932)

Together with the folks at Expo, we also worked on adding information about New Architecture support in the React Native Directory, so it will be immediately clear for you if a library already supports the New Architecture or not:

We also invite you to take part in the New Architecture survey. This survey is key for us to collect precious feedback on the next steps for the New Architecture rollout.

We also want to share a post we published in the New Architecture Working Group about Supporting UIManager in the New Architecture. This post offers an API overview of the UIManager API on Android and how it can help the migration of more advanced apps & libraries.

This release contains also a new API which is now the blessed way to access the jsi::Runtime.

Accessing `jsi::Runtime` in TurboModules

In the past, there has never been a recommended way from native modules to access the jsi::Runtime, and consumers would work around the framework to do so in risky ways. In 0.74, we introduced experimental APIs providing safe access to the jsi::Runtime, and we’re happy to announce their stability for 0.75.

Examples on how to access the jsi::Runtime

Use a framework to build React Native apps

Tue, 25 Jun 2024 00:00:00 GMT

At React Conf, we updated our guidance on the best tool to get started building React Native apps: a React Native framework - a toolbox with all the necessary APIs to let you build production-ready apps.

Using React Native frameworks, such as Expo, is now the recommended approach to create new apps.

In this blogpost we want to walk you through what they are in detail and what they mean for you as a React Native developer starting a new project.

What is a React Native framework?

If you’ve been building production apps, you probably know that there is a set of common problems you will need to solve sooner or later.

When building any application on either web or native, you probably want your users to navigate through different screens, fetch data, and store the state of your user. But for native apps there is even more to deal with: you need tools to upgrade your native code between React Native versions, manage compatible versions of all of your dependencies, and deal with native build tools.

It takes a village to bring an app from idea to production without the right tools.

We want you to focus on writing beautiful applications and features for your users, and not solving those common problems over and over.

That’s why we believe that the best way for you to experience React Native is through a framework that offers a toolbox with all the necessary tools you need to build production-ready applications.

We’ve found that you’re either using a framework or you’re building your own framework.

There is nothing wrong with building your own framework, by crafting your own solutions for routing, navigation, deploying, and so on. Major corporations like Meta and Microsoft build their own frameworks internally to integrate deeply into their brownfield apps. But we believe that most people will be better off by using an existing framework.

If you’ve been using React on web, you’re probably familiar with a similar concept of production-grade React frameworks.

As of today, the only recommended community framework for React Native is Expo. Folks at Expo have been investing in the React Native ecosystem since the early days of React Native and as of today, we believe the developer experience offered by Expo is best in class.

note

Expo, the framework, is and will remain free and open source, while Expo Application Services (EAS) is an optional paid service.

If you haven’t used Expo recently, make sure you don’t miss this talk from Kadi @ Expo where she’s showcasing what you can do with Expo in 2024.

We’ve also updated the Getting Started page on the website to reflect this recommendation.

How will frameworks affect you?

If you’re already using a recommended framework such as Expo, you’re already good to go!

If you'd like to migrate your existing app to Expo, you can find instructions on the official Expo website. Expo offers many benefits, such as an easier way to upgrade your React Native version, a better developer experience, and much more.

However, if you can't or don't want to migrate to Expo, that's fine too. Using React Native without an official framework will continue to be supported. The tools you’ve been using such as React Native Community CLI, Template and Upgrade Helper will keep on working as usual.

The react-native init command has moved out of core and is now accessible via:

npx @react-native-community/cli@latest init

and on GitHub at react-native-community/cli.

If you’re a React Native library developer, we collected a list of recommendations on which APIs to use. Read more in the RFC.

React Native 0.74 - Yoga 3.0, Bridgeless New Architecture, and more

Mon, 22 Apr 2024 00:00:00 GMT

Today we're releasing React Native 0.74! This release adds Yoga 3.0, Bridgeless by default under the New Architecture, batched onLayout updates (New Architecture), and Yarn 3 as the default package manager for new projects.

We are also removing deprecated APIs, with the removal of PropTypes and breaking changes to PushNotificationIOS. On Android, SDK 23 (Android 6.0) is now the minimum supported version.

Highlights

Breaking Changes

Highlights

Yoga 3.0

New Layout Behaviors

React Native 0.74 includes Yoga 3.0, the newest version of our layout engine. Yoga 3.0 improves layout by making styling more predictable, and supports rendering components written for the web.

React Native continues to intentionally preserve some incorrect layout behaviors, where fixing them was found to effect a significant number of real-world components. Layout conformance will be able to be configured more granularly in future versions of React Native.

warning

React Native previously flipped left/right (and start/end) edges when dealing with margin, padding, or border, set on a row-reverse container. Now, behavior of these properties lines up with web. Code which previously relied on edges being inverted may need to be updated to continue rendering correctly.

Style Before After

Style	Before	After
`<View style={{ flexDirection: 'row', backgroundColor: 'red', margin: 10, width: 200, height: 100, }}> <View style={{ flexDirection: 'row-reverse', backgroundColor: 'blue', flex: 1, marginLeft: 50, }}> <View style={{ backgroundColor: 'green', height: '50%', flex: 1, marginLeft: 50, }} /> View> View>`

<View
  style={{
    flexDirection: 'row',
    backgroundColor: 'red',
    margin: 10,
    width: 200,
    height: 100,
  }}>
  <View
    style={{
      flexDirection: 'row-reverse',
      backgroundColor: 'blue',
      flex: 1,
      marginLeft: 50,
    }}>
    <View
      style={{
        backgroundColor: 'green',
        height: '50%',
        flex: 1,
        marginLeft: 50,
      }}
    />
  View>
View>

Support for `align-content: 'space-evenly'`

Yoga 3.0 brings support for alignContent: 'space-evenly'. space-evenly distributes the lines in a multi-line flex container using evenly spaced gaps, placed between line and container edges.

Source: World Wide Web Consortium

Support for `position: 'static'`

info

position: 'static' is supported only in the New Architecture.

Elements marked as position: 'static' may not be offset, and are not considered when determining the containing block of an absolutely positioned element. This allows positioning an element relative to an ancestor which is not its direct parent.

<View
  style={{
    backgroundColor: 'blue',
    width: 200,
    height: 200,
    flexDirection: 'row-reverse',
  }}>
  <View
    style={{
      backgroundColor: 'red',
      width: 100,
      height: 100,
      position: 'static',
    }}>
    <View
      style={{
        backgroundColor: 'green',
        width: 25,
        height: '25%',
        left: 25,
        top: 25,
        position: 'absolute',
      }}
    />
  View>
View>

Notice how the green declares left and top and it is positioned relative to the blue , not its parent.

React Native continues to default to position: 'relative' when no position is set.

New Architecture: Bridgeless by Default

In this release, we are making Bridgeless Mode the default when the New Architecture is enabled. You can learn more about our switch to Bridgeless as the default in this post. To make the transition smoother we enhanced the interop layers to cover Bridgeless and worked with several libraries to make sure they will work in Bridgeless from day one.

Bridgeless is not the only interop layer we worked on: we improved the New Renderer Interop layers too. The most exciting bit is that it is now enabled by default: you don't need to specify the components that have to go through it! You can read more about them here.

Finally, if you want to learn more about the New Architecture, you can find documentation in the react-native-new-architecture repo. When the New Architecture becomes the default, this information will be incorporated into reactnative.dev.

New Architecture: Batched `onLayout` updates

State updates in onLayout callbacks are now batched. Previously, each state update in the onLayout event would result in a new render commit.

function MyComponent(props) {
  const [state1, setState1] = useState(false);
  const [state2, setState2] = useState(false);

  return (
    <View>
      <View
        onLayout={() => {
          setState1(true);
       }}>
      <View
         onLayout={() => {
          // When this event is executed, state1's new value is no longer observable here.
          setState2(true);
        }}>
      View>
    View>
  );
}

In 0.74, setState1 and setState2 updates are batched together. This change is expected behavior in React and allows for less re-renders.

danger

This change may break code that has relied on un-batched state updates. You'll need to refactor this code to use updater functions or equivalent.

Yarn 3 for New Projects

Yarn 3 is now the default JavaScript package manager for new projects initialized with React Native Community CLI.

Yarn 3.x will be used with nodeLinker: node-modules, a mode providing compatibility with React Native libraries. This replaces Yarn Classic (1.x, deprecated) as the previous default. To upgrade Yarn version inside your existing app you can follow this guide.

$ yarn --help
━━━ Yarn Package Manager - 3.6.4 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  $ yarn <command>

The Community CLI also supports initializing projects with other package managers via the --pm flag (read more).

Breaking Changes

Android Minimum SDK Bump (Android 6.0)

React Native 0.74 has a minimum Android SDK version requirement of 23 (Android 6.0). Previously, this was Android 5.0 (API 21). See our context for this change here.

Bonus: Android app size reduction

The minimum SDK bump, together with several improvements at our native build, allowed us to greatly reduce the app size on user devices.

For example a newly created app with React Native 0.74 occupies ~13% less space on user device, resulting in ~4MB saved on device.

Removal of Deprecated `PropTypes`

Before 0.74, React Native continued to ship with PropTypes, an API that has been deprecated since React 15.5 in 2017! We are now removing all built-in PropTypes from React Native, reducing app size (26.4kB in a minified bundle) and memory overhead.

The following PropTypes properties are removed: Image.propTypes, Text.propTypes, TextInput.propTypes, ColorPropType, EdgeInsetsPropType, PointPropType, ViewPropTypes (see commit).

If your app or library relies on PropTypes, we highly recommend migrating to a type system like TypeScript.

API Changes to PushNotificationIOS (Deprecated)

In React Native 0.74, we are making steps to remove the deprecated PushNotificationIOS library. The changes in this release are focused on removing references to older iOS APIs. PushNotificationIOS has been migrated onto Apple’s User Notifications framework and exposes new APIs for scheduling and handling notifications.

In the next release (0.75), we are planning to remove this library, relocating it out of React Native core and into the community package, @react-native-community/push-notification-ios. If you are still relying on PushNotificationIOS, you’ll need to migrate over before the next release.

API Changes

The didRegisterUserNotificationSettings: callback on RCTPushNotificationManager was a no-op and has been deleted.

The following callbacks on RCTPushNotificationManager have been deprecated and will be removed in 0.75:

+ (void)didReceiveLocalNotification:(UILocalNotification *)notification;
+ (void)didReceiveRemoteNotification:(NSDictionary *)notification;

In order to retrieve the notification which launched the app using getInitialNotification(), you’ll now need to explicitly set the initialNotification on RCTPushNotificationManager:

[RCTPushNotificationManager setInitialNotification:response.notification];

On the JS side, properties on Notification have changed. alertAction and repeatInterval are now deprecated and will be removed in 0.75:

type Notification = {
  ...
  // NEW: Seconds from now to display the notification.
  fireIntervalSeconds?: ?number,

  // CHANGED: Used only for scheduling notifications. Will be null when
  // retrieving notifications using `getScheduledLocalNotifications` or
  // `getDeliveredNotifications`.
  soundName?: ?string,

  // DEPRECATED: This was used for iOS's legacy UILocalNotification.
  alertAction?: ?string,

  // DEPRECATED: Use `fireDate` or `fireIntervalSeconds` instead.
  repeatInterval?: ?string,
};

Finally, the handler parameter on PushNotificationIOS.removeEventListener is unused and has been removed.

💡 How to Migrate

React Native 0.73 - Debugging Improvements, Stable Symlink Support, and more

Wed, 06 Dec 2023 00:00:00 GMT

Today we're releasing React Native 0.73! This release adds improvements to debugging with Hermes, stable symlink support, Android 14 support, and new experimental features. We are also deprecating legacy debugging features, and are releasing the next pillar of the New Architecture: Bridgeless Mode!

Highlights

Breaking Changes

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.

note

The new debugger is experimental and has some known issues we are actively working to solve in a future release of React Native. If you are trying it out, please use the same discussion thread to report feedback.

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.

info

Monorepo workarounds

We are aware there are still edge cases when using React Native in a monorepo layout. We have planned work to address some of these, which didn't quite make it into 0.73 — but which we aim to ship as soon as possible.

For React Native template projects (npx react-native init), you will need to configure any watchFolders outside of the project root in order for Metro to discover them (more info). You may also need to update file paths if your react-native dependency is installed to a folder at a different level.

For Expo apps, support for Yarn (Classic) workspaces is configured out of the box. See also the Work with monorepos guide in the Expo docs.

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 install --cask zulu@17

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.

info

Remote JavaScript Debugging was previously the default debugging experience for apps using JavaScriptCore (JSC). We recommend Safari Developer Tools (direct JSC debugging) instead, for iOS apps.

We recommend using Hermes for a consistent debugging experience on all platforms.

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:

Old Package Name	New Package Name
`metro-react-native-babel-preset`	`@react-native/babel-preset`
`metro-react-native-babel-transformer`	`@react-native/metro-babel-transformer`

info

@react-native/babel-preset now includes @react-native/babel-plugin-codegen, this no longer needs to be specified separately in your Babel config file.

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.

info

0.73 is now the latest stable version of React Native and 0.70.x now moves to unsupported. For more information see React Native’s support policy.

React Native 0.72 - Symlink Support, Better Errors, and more

Wed, 21 Jun 2023 00:00:00 GMT

Today we’re releasing 0.72!

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

Breaking Changes

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.

tip

See Package Exports Support in React Native to learn more about this feature and our plans for stable rollout.

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.

info

Please update your config file to the following format. You can also follow the upgrade-helper.

These format changes to metro.config.js will become required in 0.73. For 0.72, we will log a warning if not updated.

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.

Old Package Name	New Package Name
`@react-native-community/eslint-config`	`@react-native/eslint-config`
`@react-native-community/eslint-plugin`	`@react-native/eslint-plugin`
`@react-native/polyfills`	`@react-native/js-polyfills`
`@react-native/normalize-color`	`@react-native/normalize-colors`
`@react-native/assets`	`@react-native/assets-registry`
`react-native-codegen`	`@react-native/codegen`
`react-native-gradle-plugin`	`@react-native/gradle-plugin`

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.

info

0.72 is now the latest stable version of React Native and 0.69.x version moves now to unsupported. For more information see React Native’s support policy.

Package Exports Support in React Native

Wed, 21 Jun 2023 00:00:00 GMT

With the release of React Native 0.72, Metro — our JavaScript build tool — now includes beta support for the package.json "exports" field. When enabled, it adds the following functionality:

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.

note

The full capabilities for "exports" are detailed in the Node.js Package Entry Points spec.

Since these features overlap with existing React Native concepts (such as platform-specific extensions), and since "exports" had been live in the npm ecosystem for some time, we reached out to the React Native community to make sure our implementation would meet developers' needs (PR, final RFC).

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'.

tip

Remember to use the React Native Jest preset! Jest includes support for Package Exports by default. In tests, you can override which customExportConditions are resolved using the testEnvironmentOptions option.

If you are using TypeScript, resolution behaviour can be matched by setting moduleResolution: 'bundler' and resolvePackageJsonImports: false within your project's tsconfig.json.

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.

💡 Validating changes in your project

React Native 0.71-RC0 Android outage postmortem

Fri, 27 Jan 2023 00:00:00 GMT

Now that 0.71 is available, we want to share some key information about the incident that broke Android builds for all React Native versions while releasing the first 0.71 release candidate for React Native & Expo Android builds on November 4th, 2022.

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.

React Native Blog

React Native Comes to Meta Quest

Highlights​

React Native on Meta Quest​

Getting started on Meta Quest​

Step-by-step: Run an Expo app on Meta Quest​

Development builds and native features​

Platform-specific setup and differences from mobile​

Project configuration for Meta Horizon OS​

Using React Native without Expo​

Android without Google Play Services​

Permissions and device capabilities​

Evaluating library compatibility​

Platform-aware code paths​

Design and UX considerations for VR​

Examples and references​

Reference project​

Learn more​

Acknowledgements​

React Native 0.84 - Hermes V1 by Default

Highlights​

Hermes V1 as Default​

React Native 0.83 - React 19.2, New DevTools features, no breaking changes

Highlights​

React 19.2​

​

useEffectEvent​

New DevTools features​

Network and Performance panels​

React Native 0.82 - A New Era

Highlights​

New Architecture Only​

How to migrate​

Interop Layers & 3P library compatibility​

Removal of Legacy Architecture classes​

Experimental Hermes V1​

How to enable Hermes V1​

React 19.1.1​

DOM Node APIs​

Other changes​

Web Performance APIs (Canary)​

Optimized Debug Build Type for Android​

Breaking Changes​

Uncaught promise rejections will now raise console.error​

Other Breaking Changes​

General​

iOS​

Android​

C++​

Acknowledgements​

Upgrade to 0.82​

React Native 0.81 - Android 16 support, faster iOS builds, and more

Highlights​

Highlights​

Android 16 support​

SafeAreaView deprecation​

Community-maintained JavaScriptCore support​

Experimental Precompiled iOS builds​

Breaking Changes​

Minimum Node.js bumped to 20​

Minimum Xcode bumped to 16.1​

Metro: Better support for advanced configuration in Community CLI projects​

Improved reporting of uncaught JavaScript errors​

RN_SERIALIZABLE_STATE and C++ flags.​

Other Breaking Changes​

Android​

Acknowledgements​

Upgrade to 0.81​

React Native 0.80 - React 19.1, JS API Changes, Freezing Legacy Arch and much more

Highlights​

Highlights​

JavaScript deep imports deprecation​

Opt-in Strict TypeScript API​

Legacy Architecture Freezing & Warnings​

React 19.1.0​

Experimental - React Native iOS dependencies are now prebuilt​

How to use them​

Other Changes​

Android - Smaller APK size thanks to IPO​

New App Screen redesign​

Highlights

React Native on Meta Quest

Getting started on Meta Quest

Step-by-step: Run an Expo app on Meta Quest

Development builds and native features

Platform-specific setup and differences from mobile

Project configuration for Meta Horizon OS

Using React Native without Expo

Android without Google Play Services

Permissions and device capabilities

Evaluating library compatibility

Platform-aware code paths

Design and UX considerations for VR

Examples and references

Reference project

Learn more

Acknowledgements

Highlights

Hermes V1 as Default

Highlights

React 19.2

`useEffectEvent`

New DevTools features

Network and Performance panels

Highlights

New Architecture Only

How to migrate

Interop Layers & 3P library compatibility

Removal of Legacy Architecture classes

Experimental Hermes V1

How to enable Hermes V1

React 19.1.1

DOM Node APIs

Other changes

Web Performance APIs (Canary)

Optimized Debug Build Type for Android

Breaking Changes

Uncaught promise rejections will now raise `console.error`

Other Breaking Changes

General

iOS

Android

C++

Acknowledgements

Upgrade to 0.82

Highlights

Highlights

Android 16 support

SafeAreaView deprecation

Community-maintained JavaScriptCore support

Experimental Precompiled iOS builds

Breaking Changes

Minimum Node.js bumped to 20

Minimum Xcode bumped to 16.1

Metro: Better support for advanced configuration in Community CLI projects

Improved reporting of uncaught JavaScript errors

`RN_SERIALIZABLE_STATE` and C++ flags.

Other Breaking Changes

Android

Acknowledgements

Upgrade to 0.81

Highlights

Highlights

JavaScript deep imports deprecation

Opt-in Strict TypeScript API

Legacy Architecture Freezing & Warnings

React 19.1.0

Experimental - React Native iOS dependencies are now prebuilt

How to use them

Other Changes

Android - Smaller APK size thanks to IPO

New App Screen redesign

Notice about JSC community support

Breaking Changes

Added `"exports"` field on main package

Other Breaking Changes

JS

Android

iOS

Acknowledgements