React Native Blog

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 previosly 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 0.71: TypeScript by Default, Flexbox Gap, and more...

Thu, 12 Jan 2023 00:00:00 GMT

Today we’re releasing React Native version 0.71! This is a feature-packed release including:

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

info

For a full list of changes, check out CHANGELOG.md.

TypeScript by default

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

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

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

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

note

After upgrading to React Native 0.71, we recommend removing @types/react-native from your package.json devDependencies.

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

Simplifying layouts with Flexbox gap

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

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

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

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

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

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

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

Web-inspired props for accessibility, styles, and events

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

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

note

For more background on aligning React Native to web standards, check out this proposal and related discussion.

Accessibility

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

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

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

See this issue for more details.

Component-Specific Behavior

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

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

See this issue for more details.

Styles

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

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

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

See this issue for more details.

Events

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

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

onPointerOver, onPointerOut
onPointerEnter, onPointerLeave

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

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

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

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

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

note

You’ll also need to enable React feature flags on your Android and iOS native setup.

Check out our dedicated PointerEvents post to learn more.

Restoring PropTypes

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

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

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

caution

As part of this change, we are also removing the console filtering from LogBox.ignoreLog. This means logs that you have previously filtered with Logbox.ignoreLog will start appearing again in the console when you upgrade.

This is expected, because it allows logs such as deprecation warnings to be found and fixed.

Developer Experience Improvements

React DevTools

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

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

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

Here are both features in action:

Hermes

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

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

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

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

New Architecture

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

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

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

Other Notable Fixes

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

Breaking changes

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

Acknowledgements

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

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

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

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

Try out 0.71.0 now!

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

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

info

0.71 is now the latest stable version of React Native and 0.68.x versions are now unsupported. For more information see React Native’s support policy.

First-class Support for TypeScript

Tue, 03 Jan 2023 00:00:00 GMT

With the release of 0.71, React Native is investing in the TypeScript experience with the following changes:

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

New App Template is TypeScript By Default

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

npx react-native init My71App --version 0.71.0

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

Declarations Shipped with React Native

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

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

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

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

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

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

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

How to Migrate

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

App Maintainer

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

note

If you have warnings because a library you use references @types/react-native as a peerDependency, file an issue or open a PR for that library to use optional peerDependencies and ignore the warning for now.

Library Maintainer

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

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

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

What if I use Flow?

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

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

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

What if I find a bug in the TypeScript declaration?

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

Documentation is TypeScript First

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

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

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

Thank you to the React Native TypeScript community!

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

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

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

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

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

Pointer Events in React Native

Tue, 13 Dec 2022 00:00:00 GMT

Today we are sharing an experimental cross-platform pointer API for React Native. We’ll go over motivations, how it works, and its benefits to React Native users. There are instructions on how to enable and we’re excited to hear your feedback!

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

Going Beyond Touch

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

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

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

Looking to Web

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

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

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

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

Porting Web Platform Tests

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

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

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

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

How it works

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

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

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

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

Implementation Progress

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

Events

Implemented	Work in Progress	Yet to be Implemented
onPointerOver	onPointerCancel	onClick
onPointerEnter		onContextMenu
onPointerDown		onGotPointerCapture
onPointerMove		onLostPointerCapture
onPointerUp		onPointerRawUpdate
onPointerOut
onPointerLeave

info

onPointerCancel has been hooked up to the native platform’s "cancel" event but this does not necessarily correspond to when the web platform expects them to fire.

Event Properties

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

Future Work and Exploration

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

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

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

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

Trying it Out

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

Enable Feature Flags

note

Pointer Events are only implemented for the New Architecture (Fabric) and are only available for React Native 0.71+ which at the time of writing is a release candidate.

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

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

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

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

iOS-specific

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

#import <React/RCTConstants.h>

// ...

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

    // ...
}

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

Android-specific

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

import com.facebook.react.config.ReactFeatureFlags;

//... somewhere in initialization

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

JavaScript

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

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

Feedback Welcome

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

React Native Core Contributor Summit 2022

Tue, 22 Nov 2022 00:00:00 GMT

After years of pandemic and online-only events, we really felt it was time to bring the Core Contributors of React Native together!

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

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

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

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

React Native Codegen & TypeScript Support

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

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

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

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

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

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

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

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

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

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

React Native New Architecture Library Migration

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

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

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

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

React Native Monorepo

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

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

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

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

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

Metro Web and Ecosystem Alignment

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

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

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

From the Node.js documentation:

info

The "exports" provides a modern alternative to "main" allowing multiple entry points to be defined, conditional entry resolution support between environments, and preventing any other entry points besides those defined in "exports". This encapsulation allows module authors to define the public interface for their package clearly.

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

This discussion resulted in:

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

2. Web and bundler ecosystem

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

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

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

Metro Simplified Release Workflow

As mentioned, releasing React Native is not trivial.

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

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

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

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

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

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

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

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

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

Announcing React Native 0.70

Mon, 05 Sep 2022 00:00:00 GMT

We are excited to release a new version of React Native, 0.70.0. This version comes with several improvements like a new unified configuration for Codegen, Hermes as default engine, and full CMake support for Android builds along with a refresh of the documentation for the New Architecture. Read on to learn more!

Sections

New Architecture’s New Documentation

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

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

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

Hermes as default engine

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

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

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

A new unified configuration for Codegen

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

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

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

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

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

Android Auto-linking for New Architecture libraries

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

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

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

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

Full CMake support for Android builds

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

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

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

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

Highlights of 0.70

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

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

Breaking changes

There have also been a few breaking changes:

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

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

Upgrades

And we upgraded some of our dependencies:

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

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

Acknowledgements

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

Hermes as the Default

Fri, 08 Jul 2022 00:00:00 GMT

Last October, we announced that we had started work towards making Hermes the default engine for all React Native apps.

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

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

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

Benchmarking

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

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

Android Benchmarking Data

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

TTI Video

iOS Benchmarking Data

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

TTI Video

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

React Native/Hermes Integration

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

iOS Intl

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

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

Ongoing Work

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

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

Wrap Up

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

Announcing React Native 0.69

Tue, 21 Jun 2022 00:00:00 GMT

We are excited to release a new version of React Native, 0.69.0. This version comes with several improvements for the New Architecture of React Native and new features: React 18 support & bundled Hermes. Read on to learn more!

Sections

React 18

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

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

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

Bundled Hermes

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

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

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

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

New Architecture

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

Highlights of 0.69

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

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

Breaking changes

There have also been a few breaking changes:

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

Upgrades

And we upgraded some of our dependencies:

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

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

Acknowledgements

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

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

Helping migrate React Native libraries to the New Architecture

Thu, 16 Jun 2022 00:00:00 GMT

tl; dr: We are working on improving the resources supporting the React Native New Architecture. We have already released a repository to help migrate your app (RNNewArchitectureApp) and one for your libraries (RNNewArchitectureLibraries). We are also revamping the New Architecture guide on the Website and we created a GitHub Working Group to answer questions related to the New Architecture.

Introduction

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

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

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

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

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

Documentation

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

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

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

Example Migrations

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

RNNewArchitectureApp

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

Commit list for a migration in the RNNewArchitectureApp repository

The repo is organized as follows:

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

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

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

RNNewArchitectureLibraries

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

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

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

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

Support

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

The working group is organized into several sections:

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

To use this group effectively:

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

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

Migration Status of Popular Libraries

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

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

Next Steps

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

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

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

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

React Native Accessibility - GAAD 2022 Update

Thu, 19 May 2022 00:00:00 GMT

May 19th, 2022 marks the 11th annual celebration of Global Accessibility Awareness Day and we wanted to update everyone on the accessibility progress we’ve made on the React Native Framework. Meta (formerly Facebook) was the first organization to take the GAAD pledge in 2020, committing to making the React Native framework accessible.

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

— Mike Shebanek, head of accessibility Meta, 2020

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

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

Fixes that have already landed in 2022

Fixes currently in progress

Contributor highlight

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

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

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

What’s next in 2022

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

Announcing React Native 0.68

Wed, 30 Mar 2022 00:00:00 GMT

Hello everyone! Today we are announcing the 0.68.0 release of React Native, with opt-in to the New React Native Architecture, bug fixes and more.

Sections

Highlights of 0.68

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

Breaking changes and version bumps

This version brings along a few breaking changes:

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

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

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

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

Other improvements

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

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

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

Acknowledgements

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

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

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

Opting in to the New Architecture

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

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

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

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

Website updates

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

An update on the New Architecture Rollout

Tue, 15 Mar 2022 00:00:00 GMT

Hi everyone, As previously announced:

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

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

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

The Working Group

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

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

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

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

Everyone is welcome to apply to join the conversation.

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

The Migration Guide

After several rounds of review & feedback, we finally merged the Migration Guide (f.k.a. the Playbook). You can find it on the New Architecture working group.

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

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

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

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

The New Architecture Template

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

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

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

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

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

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

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

The 3rd-party Libraries Ecosystem

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

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

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

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

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

Releases

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

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

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

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

Towards Hermes as Default engine

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

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

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

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

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

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

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

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

With this, that’s a wrap.

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

And looking forward to reading your migration stories.

React Native Blog

New Architecture is here

What is the New Architecture​

New Native Modules​

New Renderer​

The Event Loop​

Removing the Bridge​

Gradual Migration​

New Features​

Transitions​

Automatic Batching​

useLayoutEffect​

Full Support for Suspense​

How to Upgrade​

Apps​

Libraries​

Opt-out​

Thanks​

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

Highlights​

Breaking Changes​

Highlights​

React Native New Architecture by default​

React Native DevTools​

Phasing out logs in Metro​

Faster Metro resolution​

Box Shadow and Filter style props​

boxShadow​

Limitations & Spec Deviations​

filter​

Limitations and Spec Deviations​

Breaking Changes​

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

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

Updates to Minimum iOS and Android SDK requirements​

Other Breaking Changes​

Android​

iOS​

Acknowledgements​

Upgrade to 0.76​

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

Highlights​

Breaking Changes​

Highlights​

Yoga 3.1 and Layout Improvements​

Percentage Values in Gaps​

Percentage values in Translation​

New Architecture Stabilization​

Accessing jsi::Runtime in TurboModules​

Use a framework to build React Native apps

What is a React Native framework?​

How will frameworks affect you?​

Further reading​

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

Highlights​

Breaking Changes​

Highlights​

Yoga 3.0​

New Layout Behaviors​

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

Support for position: 'static'​

New Architecture: Bridgeless by Default​

New Architecture: Batched onLayout updates​

Yarn 3 for New Projects​

Breaking Changes​

Android Minimum SDK Bump (Android 6.0)​

Bonus: Android app size reduction​

Removal of Deprecated PropTypes​

API Changes to PushNotificationIOS (Deprecated)​

API Changes​

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

Highlights​

Breaking Changes​

Highlights​

Debugging Improvements​

Console Log History in Hermes​

Updated Debugging Docs​

Experimental New Debugger​

Stable Symlink Support in Metro​

Monorepo workarounds​

What is the New Architecture

New Native Modules

New Renderer

The Event Loop

Removing the Bridge

Gradual Migration

New Features

Transitions

Automatic Batching

useLayoutEffect

Full Support for Suspense

How to Upgrade

Apps

Libraries

Opt-out

Thanks

Highlights

Breaking Changes

Highlights

React Native New Architecture by default

React Native DevTools

Phasing out logs in Metro

Faster Metro resolution

Box Shadow and Filter style props

`boxShadow`

Limitations & Spec Deviations

`filter`

Limitations and Spec Deviations

Breaking Changes

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

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

Updates to Minimum iOS and Android SDK requirements

Other Breaking Changes

Android

iOS

Acknowledgements

Upgrade to 0.76

Highlights

Breaking Changes

Highlights

Yoga 3.1 and Layout Improvements

Percentage Values in Gaps

Percentage values in Translation

New Architecture Stabilization

Accessing `jsi::Runtime` in TurboModules

What is a React Native framework?

How will frameworks affect you?

Further reading

Highlights

Breaking Changes

Highlights

Yoga 3.0

New Layout Behaviors

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

Support for `position: 'static'`

New Architecture: Bridgeless by Default

New Architecture: Batched `onLayout` updates

Yarn 3 for New Projects

Breaking Changes

Android Minimum SDK Bump (Android 6.0)

Bonus: Android app size reduction

Removal of Deprecated `PropTypes`

API Changes to PushNotificationIOS (Deprecated)

API Changes

Highlights

Breaking Changes

Highlights

Debugging Improvements

Console Log History in Hermes

Updated Debugging Docs

Experimental New Debugger

Stable Symlink Support in Metro

Monorepo workarounds

Kotlin Template on Android

Android 14 Support

Java 17 and Android Gradle Plugin upgrade

Grant partial access to photos and videos

Min SDK bump

New Architecture Updates

Deprecated Debugging Features