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

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

TypeScript by default​

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

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

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

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

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

Simplifying layouts with Flexbox gap​

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

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

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

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

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

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

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

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

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

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

Accessibility​

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

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

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

See this issue for more details.

Component-Specific Behavior​

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

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

See this issue for more details.

Styles​

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

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

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

• objectFit
• pointerEvents
• userSelect
• verticalAlign

See this issue for more details.

Events​

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

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

• onPointerOver, onPointerOut
• onPointerEnter, onPointerLeave

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

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

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

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

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

Check out our dedicated PointerEvents post to learn more.

Restoring PropTypes​

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

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

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

Developer Experience Improvements​

React DevTools​

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

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

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

Here are both features in action:

Hermes​

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

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

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

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

New Architecture​

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

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

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

Other Notable Fixes​

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

Breaking changes​

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

Acknowledgements​

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

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

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

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

Try out 0.71.0 now!​

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

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

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

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

New App Template is TypeScript By Default​

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

npx react-native init My71App --version 0.71.0

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

Declarations Shipped with React Native​

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

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

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

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

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

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

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

How to Migrate​

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

App Maintainer​

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

Library Maintainer​

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

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

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

What if I use Flow?​

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

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

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

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

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

Documentation is TypeScript First​

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

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

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

Thank you to the React Native TypeScript community!​

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

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

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

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

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

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

Going Beyond Touch​

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

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

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

Looking to Web​

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

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

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

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

Porting Web Platform Tests​

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

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

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

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

How it works​

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

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

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

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

Implementation Progress​

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

Events​

Event Properties​

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

Future Work and Exploration​

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

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

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

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

Trying it Out​

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

Enable Feature Flags​

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

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

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

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

iOS-specific​

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

#import <React/RCTConstants.h>

// ...

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

    // ...
}

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

Android-specific​

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

import com.facebook.react.config.ReactFeatureFlags;

//... somewhere in initialization

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

JavaScript​

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

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

Feedback Welcome​

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

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

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

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

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

React Native Codegen & TypeScript Support​

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

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

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

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

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

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

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

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

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

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

​​React Native New Architecture Library Migration​

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

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

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

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

​​React Native Monorepo​

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

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

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

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

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

Metro Web and Ecosystem Alignment​

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

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

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

From the Node.js documentation:

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

This discussion resulted in:

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

2. Web and bundler ecosystem​

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

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

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

Metro Simplified Release Workflow​

As mentioned, releasing React Native is not trivial.

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

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

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

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

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

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

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

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

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

Sections​

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

New Architecture’s New Documentation​

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

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

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

Hermes as default engine​

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

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

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

A new unified configuration for Codegen​

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

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

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

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

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

Android Auto-linking for New Architecture libraries​

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

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

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

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

Full CMake support for Android builds​

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

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

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

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

Highlights of 0.70​

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

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

Breaking changes​

There have also been a few breaking changes:

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

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

Upgrades​

And we upgraded some of our dependencies:

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

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

Acknowledgements​

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

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

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

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

Benchmarking​

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

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

Android Benchmarking Data​

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

TTI Video​

iOS Benchmarking Data​

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

TTI Video​

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

React Native/Hermes Integration​

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

iOS Intl​

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

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

Ongoing Work​

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

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

Wrap Up​

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

Sections​

• React 18
• Bundled Hermes
• Highlights of 0.69

React 18​

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

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

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

Bundled Hermes​

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

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

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

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

New Architecture​

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

Highlights of 0.69​

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

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

Breaking changes​

There have also been a few breaking changes:

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

Upgrades​

And we upgraded some of our dependencies:

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

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

Acknowledgements​

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

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

Introduction​

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

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

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

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

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

Documentation​

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

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

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

Example Migrations​

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

RNNewArchitectureApp​

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

The repo is organized as follows:

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

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

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

RNNewArchitectureLibraries​

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

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

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

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

Support​

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

The working group is organized into several sections:

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

To use this group effectively:

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

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

Migration Status of Popular Libraries​

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

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

Next Steps​

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

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

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

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

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

— Mike Shebanek, head of accessibility Meta, 2020

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

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

Fixes that have already landed in 2022​

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

Fixes currently in progress​

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

Contributor highlight​

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

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

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

What’s next in 2022​

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

Sections​

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

Highlights of 0.68​

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

Breaking changes and version bumps​

This version brings along a few breaking changes:

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

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

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

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

Other improvements​

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

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

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

Acknowledgements​

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

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

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

Opting in to the New Architecture​

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

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

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

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

Website updates​

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

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

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

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

The Working Group​

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

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

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

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

Everyone is welcome to apply to join the conversation.

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

The Migration Guide​

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

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

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

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

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

The New Architecture Template​

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

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

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

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

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

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

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

The 3rd-party Libraries Ecosystem​

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

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

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

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

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

Releases​

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

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

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

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

Towards Hermes as Default engine​

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

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

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

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

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

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

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

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

With this, that’s a wrap.

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

And looking forward to reading your migration stories.

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

Repository Health​

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

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

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

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

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

Community Engagement​

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

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

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

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

The New Architecture Rollout and Releases​

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

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

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

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

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

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

To Mobile and beyond​

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

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

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

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

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

Sections​

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

Highlights of 0.67​

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

Here are some notable changes coming in 0.67.0:

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

You can find the full changelog here.

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

Acknowledgements​

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

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

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

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

Improvements to Release Process​

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

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

Coordination and Knowledge Sharing​

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

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

Clarity of responsibility​

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

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

Release candidate signal​

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

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

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

Interested in helping React Native stabilise new releases?​

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

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

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

Optimizing for React Native​

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

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

Building a New Garbage Collector for Fabric​

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

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

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

Striking on Performance Pain Points​

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

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

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

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

Pioneering at Vertical Integrations​

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

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

Bringing Along the Whole Community​

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

Expanding to New Platforms​

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

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

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

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

Supporting our Community​

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

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

Summary​

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

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

Thanks​

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

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

Highlights​

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

Handle taps on child views outside parent boundaries on Android​

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

Find more details on the pull request.

New Bluetooth Permissions on Android​

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

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

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

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

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

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

Hermes 0.9.0​

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

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

See Hermes 0.9.0 release issue for more details

Nightly and “Commitly” Releases​

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

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

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

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

Using Nightly Releases (Nightlies)​

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

Using Commitly Releases (Commitlies)​

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

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

Acknowledgements​

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

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

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

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

iOS 15​

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

What to watch out for​

QuickType Bar​

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

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

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

Transparent Navigation Bar​

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

How to install iOS 15​

Device​

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

Simulator​

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

Android 12​

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

What to watch out for​

Overscroll Effect​

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

Permission Updates​

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

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

How to install Android 12​

Device​

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

Emulator​

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

As part of our plans beginning earlier this year, we are growing our focus on these platforms and growing our teams to help us achieve our vision. In order to support our new teammates, and many more to come, we are hiring two Engineering Managers: one to help support React Native for Desktop, and one to support React Native for VR.

We are looking for managers who will care deeply about the growth and success of our engineers, and are excited about our vision. Previous React or React Native experience is not required. This role is open to anyone in the United States. If this sounds like an interesting opportunity and you are interested in learning more, please apply on Facebook’s Career’s Page. We look forward to hearing from you!

Respecting the Platform​

Our first guiding principle is to match the expectations people have for each platform. Android users expect accessible apps using TalkBack. Navigation should work the way it does in other Android apps. A button should look and feel the way buttons look and feel on Android. It should not look and feel like an iOS button. Although we seek to offer a consistent cross-platform developer experience, we resist the temptation to sacrifice users’ expectations.

We believe that React Native enables developers to meet users’ expectations while also gaining the benefits of a better developer experience. In this section, we share the following:

1. By embracing platform constraints, we actually improve the experience on other platforms.
2. We can learn from institutional knowledge to build higher level cross-platform abstractions.
3. Other players on each platform inspire us to build better developer and user experiences.

Embracing Platform Constraints​

Specific device hardware or user expectations impose unique constraints and requirements. As an example, memory is typically more constrained on Android and VR headsets than on iOS, macOS, and Windows. As another example, users expect mobile apps to start up almost instantaneously, but they are less frustrated when desktop apps take longer to start up. We have found that by approaching these problems with React Native, we can more easily borrow lessons learned and code written for one platform, and apply them to other platforms.

For example, React Native relies on an optimization known as “view flattening” which is critical for reducing memory usage on Android. We never built this optimization for iOS because it does not bear the same memory constraints. Over the past few years as we built our new cross-platform renderer, we had to reimplement “view flattening”. But this time, it was written in C++ instead of platform-specific Java. Trying out this same optimization on iOS was now only a matter of flipping a switch. In the production Facebook app, we observed that this improved performance on iOS! We likely never would have built this for iOS, but our investment on Android was able to benefit our investment on iOS.

Learning from Institutional Knowledge​

One of the reasons that React Native was originally created was to reduce engineering silos. There is a tendency for Android engineers to be siloed from iOS engineers working on the same product. Android engineers review code for Android engineers and attend Android meetups and conferences. iOS engineers review code for iOS engineers and attend iOS meetups and conferences. Engineers working on different platforms bring unique domain and institutional knowledge about how to build great product experiences.

One of the best outcomes of cross-platform frameworks like React Native is how they bring together engineers with vastly different domain expertise. We believe that by targeting more platforms, we can accelerate cross-pollination of institutional knowledge between platform experts.

As an example, the accessibility abstractions in React Native are influenced by how Android, iOS, and web each approach accessibility in different ways. This enabled us to build a common interface that improves how accessibility hints are handled on both mobile platforms.

As another example, our research into user perception of speed on the web led to concurrent features like Suspense. Over the past year, these features were vetted by the new Facebook.com website. Now with our new renderer, these features are making their way to React Native and influencing how we design event scheduling and priorities. The React team’s investment into improving the web experience is benefiting React Native for native platforms.

Competition Drives Innovation​

In addition to domain-specific engineers and meetups and conferences, each platform also brings other unique players solving similar problems. On the web, React (which directly powers React Native) frequently draws inspiration from other open source web frameworks like Vue, Preact, and Svelte. On mobile, React Native has been inspired by other open source mobile frameworks, and we have been learning from other mobile frameworks built inside Facebook.

We believe that competition leads to better outcomes for everyone in the long run. By studying what makes other players on each platform great, we can learn lessons that may apply to other platforms. For example, the race to simplify complex websites influenced the development of React and gave React Native a head start to offer a declarative framework for mobile apps. The demand for faster iteration cycles and build times for the web also led to the development of Fast Refresh which significantly benefited React Native. Similarly, performance optimizations in our internal mobile frameworks — especially around data fetching and parallelization — challenged us to improve React Native in a way that has also influenced React when we built the new Facebook.com website.

Expanding to New Platforms​

React and React Native are at a turning point. React has started the road to a React 18 release, and the new React Native renderer is now fully powering the Facebook mobile apps. Our team has grown substantially this year in order to support the growing adoption at Facebook. Teams developing on other platforms have noticed the adoption and see the opportunity for them to also reap the benefits of React Native.

For the past year, we have been partnering with Microsoft and the Messenger team to create a truly native video calling experience on Windows and macOS. Due to the high scrutiny that we place on startup time for mobile apps, our initial implementation of desktop video calling using React Native completely blew away the performance of the Electron implementation that it replaced. For the first couple weeks of building this experience, we recorded videos of us resizing a window with multiple live video calls and marveled at the smooth frame rates.

Building for desktop has been very exciting for us. We have taken what we know about building mobile experiences and applied them to desktop with eyes wide open. We’ve expanded our horizons with multiple child windows, menu bars, system trays, and more. As we continue collaborating on new desktop Messenger features, we expect to find opportunities that influence how we build on web and mobile. If you want to stay up to date, our desktop collaboration work is taking place on GitHub.

We are also partnering more closely with Facebook Reality Labs to understand how React is uniquely positioned to deliver virtual reality experiences on Oculus. Building experiences in VR with React Native will be particularly interesting because of tighter memory constraints and user sensitivity to interaction latency.

Similar to how we approach React Native for mobile, we will be validating our technology at Facebook scale before we share anything publicly. A lot is still changing and we still have many questions. We want to have confidence that the technology is production-ready and reliable before sharing with the community.

Although most of the development for VR will still be internal, we hope to share more as soon as we can. We also anticipate that improvements to React Native for VR will surface in open source. For example, we anticipate that projects to reduce memory usage for VR use cases will also reduce memory usage for React Native on mobile and desktop experiences.

When we reflect back on how the industry has adopted React, there has always been an appetite in the community for React on more platforms. Even before we announced React Native to the community, Netflix had already been crafting Gibbon, their custom renderer for building TV experiences with React. And before Facebook started building Messenger for desktop, Microsoft was already using React to build native desktop experiences in Office and Windows 10.

Summary​

In summary, our vision is to expand React Native's reach beyond mobile and we've already started by partnering with desktop and VR teams at Facebook. We know that when we embrace the platform constraints of each platform, learn from institutional knowledge, and gather inspiration from other players, it benefits every platform in the ecosystem. And most importantly, in doing so, we stay true to our guiding principles.

We are excited about what's to come as we continue to explore what many platforms unlocks for React Native. Connect with us (@reactnative) for more updates and share your thoughts!

At Facebook, our team works in half-year cycles. Each half we review our strategy, set plans, and share them internally. Today, we want to share our H2 plans with you, our community.

H2 2021 is an exciting half for React Native. Our areas of focus include nurturing the community, beginning to roll out the new architecture to open source, and pushing the technology forward.

Setting up the Community for Success​

React Native’s open source ecosystem is one of its greatest strengths. We’ve identified the following areas as the best ways to grow our partnership with the community.

Community Engagement​

In order for everyone to move in the same direction, we want to continually communicate our vision and status to the community. Sharing our incremental progress publicly isn’t second-nature for us (yet). This half, we are committing to a more consistent content schedule that exercises the muscle and sets up processes to reduce friction. Beyond sharing our updates, we also want to use this opportunity to showcase the accomplishments of the community.

New Architecture Rollout and Releases​

In H1, we finished rolling out the new React Native architecture to all React Native mobile products in the Facebook app. Facebook is made up of surfaces like Marketplace Tab and Dating Profile, and we have migrated over 1000 surfaces!

In H2, we are beginning to bring this new architecture to the community. We have put together a playbook that shows how to migrate libraries and applications. We have already shared drafts with early partners that maintain popular React Native libraries. We expect to get their feedback, support them in upgrading their libraries, and learn how to improve our playbook and implementations. We plan on sharing the playbook more broadly as soon as the work stabilizes.

We are also focused on improving React Native’s release process. We will need frequent reliable releases to progressively ship the new React Native architecture. Our aim is to catch release-blockers earlier and to reduce the turn-around time. This will enable more predictable release timelines with less burden on contributors and developers.

Repository Health​

When developers evaluate a technology, an essential signal is the health of its repository. This impression is informed by signals such as pull request throughput, stars, age of last commit, and others. The React Native repository has historically lacked a process to ensure that issues and pull requests are reviewed in a timely manner. Our work this half is two-fold: we need to resolve a large backlog of contributions, and we need to build sustainable practices for handling incoming contributions. We hope this work will also set us up for success for more engagement from the community via issues and PRs as the community starts using the new architecture. You can follow our progress on the backlog using this project board.

Pushing the Technology Forward​

New Architectural Capabilities​

As mentioned, our new architecture recently finished rolling out to the Facebook mobile apps! We are already building new capabilities that will change the performance curve for React Native. This includes supporting Concurrent Rendering in React Native. Concurrent Rendering enables React to pause and resume work and quickly respond to high priority events like a touch gesture. Something we are also really excited about is using Concurrent Rendering to make use of idle CPU cycles for rendering offscreen product features without slowing down onscreen user interactions.

Mobile and Beyond​

We have had overwhelming success with powering mobile experiences using React at Facebook, and we have seen amazing mobile products from our partners. Now we want to bring that success to more platforms! We believe that targeting many platforms lets us learn new lessons and further improve our offering on mobile platforms. (We will share more about this in a later post.) The exciting news is that we’ve already started taking steps towards making this a reality!

Messenger Desktop​

Last summer, we expanded our focus beyond mobile by partnering with Microsoft to accelerate React Native development on Windows and macOS. We partnered with the Messenger team at Facebook to enable user experiences that are only possible on desktop, and to deliver huge performance wins over their previous Electron implementation. Our vision is to combine high quality, delightful, native desktop user experiences with the great developer experience of React Native.

The Messenger team has ambitious plans for the Messenger desktop apps, including finding new ways to further unleash the unique capabilities of desktop platforms and large screens. We are excited to continue enabling these experiences by investing more into React Native on desktop.

React Native in Virtual Reality​

Oculus has long used React Native to power core experiences like Store, where people buy applications and games in VR. In H2, React Native and Oculus are partnering to bring new exciting experiences to VR. We are also bringing optimizations and improvements from VR to mobile, and from mobile to VR. This will include expanding React Native to support unique requirements of VR — from new input types like controllers to new memory usage optimizations. This is the start of an exciting journey to explore and influence how immersive experiences can built for VR using React Native.

Summary​

We hope our H2 plans excite you as much as it does us, and we look forward to sharing more with you in the upcoming months! We will also be attending React Native EU on September 1, 2021 where teammate Joshua Gross (@joshuaisgross) will share how we replaced the architecture for the world’s largest React Native app. Register for React Native EU if you haven’t already! In the meantime, connect with us on Twitter (@reactnative) for updates on events, our roadmap, and much more.

What's new in Hermes 0.8?​

Hermes, Facebook’s open source JavaScript VM optimized for React Native, has been upgraded to version 0.8.1. Some of the stand-out features in this release are:

• A new concurrent garbage collector titled “Hades” which delivers up to 30 times shorter pause times on 64 bit devices. At Facebook, we saw this improve some CPU-intensive workloads by 20%-50%. You can learn more about Hades here.
• ECMAScript Internationalization API (ECMA-402, or Intl) is now built into Hermes on Android and enabled by default, with only 57-62K per API size overhead (compared to JSC's 6MiB). With this change, Hermes users no longer require locale polyfills. A big thank you to @mganandraj and other partners at Microsoft for driving the implementation to make this happen!
• Hermes on iOS now supports Apple M1 Macs and Mac Catalyst!
• Memory improvements including SMI (Small Integers) and pointer compression that shrank JS heap by 30%.
• Changes to Function.prototype.toString that fixed a performance drop due to improper feature detection and supports the source code injecting use case.

You can find the full Hermes changelog here.

Follow steps here to opt-in your app to Hermes if you haven’t already to leverage these new features and gains!

Accessibility Fixes and Additions​

Last year Facebook took the GAAD pledge to improve accessibility within React Native. 0.65 shares the results of this pledge and other accessibility wins! Some notable changes include:

• Allow specification of high contrast light and dark values for iOS. See documentation for more details.
• Added getRecommendedTimeoutMillis API on Android. This exposes a user’s preferred default timeout value as set in Android’s accessibility options and is for users who may need extra time to review or reach controls, etc.
• General fixes to ensure TalkBack/VoiceOver properly announce UI states such as disabled and unselected on components.

You can follow along or contribute to our outstanding accessibility issues here!

Notable Dependency Version Updates and Gotchas​

• react-native-codegen version 0.0.7 is now needed as a devDependency in the package.json.
• JCenter has been sunsetted and read-only now. We have removed JCenter as a maven repository and updated dependencies to use MavenCentral and Jitpack.
• Upgraded OkHttp from v3 to v4.9.1. See Upgrading to OkHttp 4 for more details on changes.
• Upgraded to Flipper 0.93 to support Xcode 12.5. See Flipper changelog here.
• Android Gradle Plugin 7 support
• Apple Silicon requires a linker workaround. See @mikehardy’s note about this.

Thank You!​

This release includes over 1100 commits from 61 contributors. Thank you to everyone who has contributed and supported this release! You can find the full changelog here.

We started with 90 outstanding gap analysis issues and from March 2021, when the project launched on GitHub, until now:

• 11 issues have been closed by the community.

• 19 issues were evaluated and closed by the React Native team.

• 9 pull requests were merged.

• 1 pull request was merged into the React Native docs.

We want to recognize and thank the React Native community for the significant progress towards a more accessible React Native over the past year. Every contributor's effort has counted in making progress on improving React Native Accessibility.

Fixes​

Two types of issues have been fixed in multiple components and one new functionality has been added to the API by the 9 pull requests.

• An issue with Disabled state has been addressed in seven components

• An issue with Selected state was addressed in two components

• A new addition to the React Native API added the ability to query AccessibilityManager.getRecommendedTimeoutMillis().

Disabled State Announcement and Disable function​

One of the most prevalent issues found during the gap analysis was that some components do not announce or disable functionality. Now seven components announce their disabled state or disable click functionality.

Announces when Disabled

• Button - #31001

• Images - #31252

• ImageBackground - #31252

Disables click functionality when the component has a disabled prop

• Button - #31001

• Text - React Native Team commit

• Pressable - React Native Team commit

• TouchableHighlight - #31135

• TouchableOpacity - #31108

• TouchableNativeFeedback - #31224

• TouchableWithoutFeedback - #31297

Selected State Announcement​

There were some components that did not announce their selection when in focus. This behavior has now been fixed when the component is in focus and the AccessibilityState is set to selected or the component is changed to selected.

Announces when Selected

• Button - #31001

• TextInput - #31144

Accessibility Timeout Setting​

There was previously no way to query the accessibility timeout setting on Android. The fix added the ability to query AccessibilityManager.getRecommendedTimeoutMillis(). This queries the "Time to take action" before the UI elements auto-dismisses or auto-progresses.

Documentation Additions​

The React Native documentation must be updated to reflect each addition or change to the available APIs. The new addition to the React Native documentation covered the addition of getRecommendedTimeoutMillis() to AccessibilityInfo.

Community Involvement​

We want to thank all the contributors mentioned below who have submitted and merged pull requests as well as those who have reviewed and commented on issues.

Merged Pull Requests​

• @huzaifaaak closed 3 issues with:
  • Added talkback support for button accessibility: disabled prop #31001
  • Accessibility/button test #31189
• @natural_clar closed 1 issue with:
  • feat: set disabled accessibilityState when TouchableHighlight is disabled #31135
• fabriziobertoglio1987 closed 2 issues with:
  • [Android] Selected State does not annonce when TextInput Component selected #31144
  • Accessibility Fix Image does not announce "disabled" #31252
• @kyamashiro73 closed 1 issue with:
  • Added talkback support for TouchableNativeFeedback accessibility: disabled prop #31224
• @grgr-dkrk closed 1 issue and added to the React Native documentation with:
  • add getRecommendedTimeoutMillis to AccessibilityInfo #31063
  • feat: add getRecommendedTimeoutMillis section on accessibilityInfo #2581
• @crloscuesta closed 1 issue with:
  • Disable accessibilityState when TouchableWithoutFeedback is disabled #31297
• @chakrihacker closed 1 issue with:
  • Disable TouchableOpacity when accessibility disabled is set #31108

Thank you to the community members who gave their time in other ways!

Simek, saurabhkacholiya, meehawk, intergalacticspacehighway, chrisglein, jychiao and Waltari10

Get Involved!​

We've come a long way but we're not done yet. We need your support to reach the finish line. Facebook's React Native team has committed to supporting contributors working on gap analysis issues. They will continue to respond to comments on Accessibility issues and triage pull requests. The React Native team is also tackling some of the toughest gap analysis issues. This work includes the correct translation of accessibilityRoles to other languages and specifying error text for specific components.

Join us in tackling the rest. There are still open accessibility issues on the Improved React Native Accessibility project board. Issues with Checked/Unchecked State, Entrance/exit from Collection, and Position in Collection are great opportunities for current and new contributors to contribute to a more accessible React Native.

Learn More​

Read about how the gap analysis was conducted on the Facebook Tech blog or about the launch of the GitHub issues on the React Native Blog.

While this work continues, the React Native and Accessibility teams at Facebook are evaluating accessibility bugs and issues that were submitted prior to this initiative, to determine if they are already covered by our current gap analysis or if there are additional issues that need to be brought into the project. One new issue has already been discovered and moved into the project, four others directly mapped to existing issues and two others are expected to be closed by addressing existing issues that address the root cause of their issue.

Thank you to all the community members who have participated. You are truly moving the needle in making React Native more accessible for everyone!

Closed Pull Requests 🎉​

• Added talkback support for button accessibility: disabled prop #31001 - closed by @huzaifaaak

• feat: set disabled accessibilityState when TouchableHighlight is disabled #31135 closed by @natural_clar

• [Android] Selected State does not annonce when TextInput Component selected #31144 closed by fabriziobertoglio1987

• Added talkback support for TouchableNativeFeedback accessibility: disabled prop #31224 closed by @kyamashiro73

• Accessibility/button test #31189 closed by @huzaifaaak

  • Adds a test for accessibilityState for button

Fixes​

• Button component (fixed by #31001):

  • Now announces when it is disabled

  • Disables click functionality for screen readers when the button is disabled

  • Announces the selected state of the button

• TextInput component (fixed by #31144):

  • Announces "selected" when the "selected" accessibilityState is set to true and the element is focused

• TouchableHighlight component (fixed by #31135):

  • Disables click functionality for screen readers when the component is disabled

• TouchableNativeFeedback component (fixed by #31224):

  • Disables click functionality for screen readers when the component is disabled

Other Progress​

Get involved!​

• New contributors should read the contribution guide and browse the list of 37 good first issues in the React Native GitHub.

• Contributors interested in issues requiring a bit more effort should visit the project page for Improved React Native Accessibility to see the GitHub issues that need their knowledge of React Native.

• Technical writers interested in updating React Native's documentation to reflect the accessibility gaps being closed should visit the React Native Docs.

• Share this initiative with anyone who may be able to help!

• Follow the GAAD Pledge Open Source Accessibility Community Manager for React Native on Twitter or Facebook to keep up to date on progress.

Hermes opt-in on iOS​

Hermes is an open source JavaScript engine optimized for running React Native. It improves performance by decreasing memory utilization, reducing download size and decreasing the time it takes for the app to become usable or “time to interactive” (TTI).

With this release, we are happy to announce that you can now use Hermes to build on iOS as well. To enable Hermes on iOS, set hermes_enabled to true in your Podfile and run pod install.

use_react_native!(
   :path => config[:reactNativePath],
   # to enable hermes on iOS, change `false` to `true` and then install pods
   :hermes_enabled => true
)

Please keep in mind that Hermes support on iOS is still early stage. We are keeping it as an opt-in as we are running further benchmarking. We encourage you to try it on your own applications and let us know how it is working out for you!

Inline Requires enabled by default​

Inline Requires is a Metro configuration option that improves startup time by delaying execution of JavaScript modules until they are used, instead of at startup.

This feature has existed and been recommended for a few years as an opt-in configuration option, listed in the Performance section of our documentation. We are now enabling this option by default for new applications to help people have fast React Native applications without extra configuration.

Inline Requires is a Babel transform that takes module imports and converts them to be inline. As an example, Inline Requires transforms this module import call from being at the top of the file to where it is used.

Before:

import {MyFunction} from 'my-module';

const MyComponent = props => {
  const result = MyFunction();

  return <Text>{result}</Text>;
};

After:

const MyComponent = props => {
  const result = require('my-module').MyFunction();

  return <Text>{result}</Text>;
};

More information about Inline Requires is available in the Performance documentation.

View Hermes traces with Chrome​

Over the last year Facebook has sponsored the Major League Hacking fellowship, supporting contributions to React Native. Jessie Nguyen and Saphal Patro added the ability to use the Performance tab on Chrome DevTools to visualize the execution of your application when it is using Hermes.

For more information, check out the new documentation page.

Hermes with Proxy Support​

We have added Proxy support to Hermes, enabling compatibility with popular community projects like react-native-firebase and mobx. If you have been using these packages you can now migrate to Hermes for your project.

We plan to make Hermes the default JavaScript engine for Android in a coming release so we are working to resolve the remaining issues people have when using Hermes. Please open an issue on the Hermes GitHub repo if there are remaining issues holding back your app from adopting Hermes.

React 17​

React 17 does not include new developer-facing features or major breaking changes. For React Native applications, the main change is a new JSX transform enabling files to no longer need to import React to be able to use JSX.

More information about React 17 is available on the React blog.

Major Dependency Version Changes​

• Dropped Android API levels 16-20. The Facebook app consistently drops support for Android versions with sufficiently low usage. As the Facebook app no longer supports these versions and is React Native’s main testing surface, React Native is dropping support as well.
• Xcode 12 and CocoaPods 1.10 are required
• Minimum Node support bumped from 10 to Node 12
• Flipper bumped to 0.75.1

Thanks​

Thank you to the hundreds of contributors that helped make 0.64 possible! The 0.64 changelog includes all of the changes included in this release.

In May 2020 Facebook was the first company to take the GAAD pledge, by doing so they committed to making accessibility a core part of the React Native open source project. Since May, Facebook has spent that time thoughtfully reviewing and documenting accessibility gaps within React Native. So far the gap analysis has surfaced 90 issues, all of which have been translated to GitHub issues.

Overall, we found that React Native APIs provide strong support for accessibility. However, we also found many core components do not yet fully utilize platform accessibility APIs and support is missing for some platform specific features.

The enthusiasm and diversity of contributors have always played a critical role in the development of React Native and these gaps in accessibility are great opportunities for current and new contributors. If you have been interested in contributing to React Native, we encourage you to join us in making React Native more accessible.

To recognize contributors for their effort, when an accessibility issue is closed and attached to a pull request, contributors will get a shout out on Twitter from our community manager. Contributors whose pull requests are accepted into the codebase will be highlighted in our monthly issues update on the React Native blog.

Please join us in making React Native more accessible for everyone.

How you can help:​

• New contributors should read the contribution guide and browse the list of 46 good first issues in the React Native GitHub.

• Contributors interested in issues requiring a bit more effort should visit the project page for Improved React Native Accessibility to see the GitHub issues that need their knowledge of React Native.

• Technical writers interested in updating React Native's documentation to reflect the accessibility gaps being closed should visit the React Native Docs.

• Share this initiative with anyone who may be able to help!

• Follow the GAAD Pledge Open Source Accessibility Community Manager for React Native on Twitter or Facebook to keep up to date on progress.

• New Getting Started guides We launched new Getting Started with docs to explain what Native Components are to people with no mobile development background. We also included a refresher/introduction to React to help folks getting started with React for the first time!
• New Testing guide We worked with Vojtech Novak to create a new illustrated testing guide that introduces app developers to different kinds of testing strategies and how they work in a React Native workflow.
• New Security guide We worked with Kadi Kraman to create a new illustrated security guide that explains the basics of security in a React Native world and puts forth best in class solutions.
• More illustrations We've added fancy new illustrations, including the new Pressable and introduction to React Native components docs
• https://reactnative.dev After 5 years we finally moved to our own domain! reactnative.dev is easier to autocomplete from your browser bar and is easier to type out than our previous github.io address!
• Site design and architecture improvements We've updated the design and site architecture to surface and categorize more of our guides and make content in the API reference more readable. Kudos especially to Bartosz Kaszubowski whose attention to detail and collaboration has made many of these changes possible quickly!
• Updated Core Component and API docs We held a documentation drive to update reference docs! Thanks to these and other participants we were able to fully update the docs and add Snack examples to all of them in time for 0.62: Marta Dabrowka, Abraham Nnaji, Ahmed Talaat El-Hager, Mohamed Abdel Nasser Abdou, Danilo Britto, Mitul Savani, Kaio Duarte, Pablo Espinosa, Jesse Katsumata, I Gede Agastya Darma Laksana, Sebastião Bruno Kiafuka Fernando, Miguel Bolivar, Dani Akash, Luiz Celso de Faria Alves, and Bartosz Kaszubowski. With their contributions, these are the best and most up to date React Native docs yet!
• Keep those PRs coming! We are able to consistently keep our open PRs under 10 per week! Thank you for sending them!

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

What’s next?​

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

We are responding with additional content including:

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

You can help!​

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

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

Native Experience​

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

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

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

Massive Scale​

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

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

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

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

Developer Velocity​

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

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

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

Every Platform​

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

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

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

Declarative UI​

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

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

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

LogBox​

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

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

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

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

To achieve these goals, LogBox includes:

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

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

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

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

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

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

Pressable​

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

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

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

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

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

A simple example of a Pressable component in action

You can learn more about it from the documentation.

Native Colors (PlatformColor, DynamicColorIOS)​

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Changes the text color based on the system theme

You can learn more about DynamicColorIOS from the documentation.

Dropping iOS 9 and Node.js 8 support​

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

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

Other notable improvements​

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

Thanks​

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

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

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

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

Flipper by default​

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

Flipper provides the following features out of the box:

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

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

For more information, check out the Flipper documentation.

New dark mode features​

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

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

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

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

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

See the docs for Appearance and useColorScheme for more information.

Moving Apple TV to react-native-tvos​

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

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

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

More upgrade support​

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

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

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

Other improvements​

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

Breaking changes​

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

Deprecations​

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

Thanks​

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

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

Here it is in action:

How it works​

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

Try it now​

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

npx @react-native-community/cli doctor

What checks are currently supported​

doctor currently supports the following checks:

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

Specific to the Android environment:

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

And to the iOS environment:

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

Thanks​

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

Fast Refresh​

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

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

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

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

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

Here are a few Fast Refresh tips:

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

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

Other Improvements​

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

Breaking Changes​

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

Thanks​

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

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

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

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

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

Illustration by Rachel Nabors

Focus on Accessibility​

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

A Fresh Start​

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

AndroidX Support​

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

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

matt-oakes on discussions-and-proposals

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

CocoaPods by Default​

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

Lean Core Removals​

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

Native Modules are now Autolinked​

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

Upgrade Helper​

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

A Note to Library Maintainers​

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

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

Thanks​

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

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

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

Meaningful Community Contributions​

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

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

Lean Core​

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

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

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

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

User Feedback​

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

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

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

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

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

Continuous Integration​

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

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

Next​

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

Check out the video on Facebook's developer website:

Highlights from the talk:​

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

React Radio Podcast about Open Source​

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

Highlights from the podcast:​

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

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

🎣 Hooks are here​

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

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

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

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

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

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

💨 Faster app launches with inline requires​

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

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

🚅 Lean core is underway​

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

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

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

👩🏽‍💻 CLI improvements​

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

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

🚀 Upgrading to 0.59​

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

🔨 Breaking Changes​

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

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

🤗 Thanks​

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

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

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

Ryan and the whole React Native core team

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

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

Pull Requests​

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

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

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

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

Lean Core​

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

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

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

Leading User Problems​

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

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

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

0.59 Release​

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

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

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

Next Steps​

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

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

A lot of people are excited about the rewrite of React Native's architecture, widely known as Fabric. Among other things, this will fix fundamental limitations in React Native's architecture and will set up React Native for success in the future together with JSI and TurboModules.

The biggest shift in 2018 was to empower the React Native Community. From the beginning, Facebook encouraged developers from all around the world to participate in React Native's open source project. Since then, a number of core contributors emerged to handle, among other things, the release process.

These members took a few substantial steps towards making the whole community more empowered to shape the future of this project with the following resources:

react-native-releases 📬​

This repository, created in January, serves the dual purpose of allowing everyone to keep up the new releases in a more collaborative manner and opened the conversation of what would be part of a certain release to whomever wanted to suggest a cherry-pick (like for 0.57.8 and all its previous versions).

This has been the driving force behind moving away from a monthly release cycle, and the "long term support" approach currently used for version 0.57.x.

Half of the credit for reaching these decisions goes to the other repository created this year:

discussions-and-proposals 🗣​

This repository, created in July, expanded on the idea of a more open environment for conversations on React Native. Previously, this need was handled by issues labelled For Discussion in the main repository, but we wanted to expand this strategy to an RFC approach that other libraries have (e.g. React).

This experiment immediately found its role in the React Native lifecycle. The Facebook team is now using the community RFC process to discuss what could be improved in React Native, and coordinate the efforts around the Lean Core project - among other interesting discussions.

@ReactNativeComm 🐣​

We are aware that our approach to communicate these efforts has not been as effective as we would have liked, and in an attempt to give you all an easier time keeping up with everything going on in the React Native Community (from releases to active discussions) we created a new twitter account that you can rely on @ReactNativeComm.

If you are not on that social network, remember that you can always watch repositories via GitHub; this feature improved these past few months with the possibility of being notified only for releases, so you should consider using it anyway.

What awaits ahead 🎓​

Over the past 7-8 months, core contributors enhanced the React Native Community GitHub organization to take more ownership over the development of React Native, and enhance collaboration with Facebook. But this always lacked the formal structure that similar projects may have in place.

This organization can set the example for everyone in the larger developer community by enforcing a set of standards for all the packages/repos hosted in it, providing a single place for maintainers to help each other and contribute quality code that conforms to community-agreed standards.

In early 2019, we will have this new set of guidelines in place. Let us know what you think in the dedicated discussion.

We are confident that with these changes, the community will become more collaborative so that when we reach 1.0, we will all continue to write (even more) awesome apps by leveraging this joint effort 🤗

I hope you are as excited as we are about the future of this community. We're excited to see all of you involved either in the conversations happening in the repositories listed above or via the awesome code you’ll produce.

Happy coding!

This year, the React Native team has focused on a large scale re-architecture of React Native. As Sophie mentioned in her State of React Native post, we've sketched out a plan to better support the thriving population of React Native users and collaborators outside of Facebook. It's now time to share more details about what we've been working on. Before I do so, I'd like to lay out our long-term vision for React Native in open source.

Our vision for React Native is...

• A healthy GitHub repository. Issues and pull requests get handled within a reasonable period of time.
  • Increased test coverage.
  • Commits that sync out from the Facebook code repository should not break open source tests.
  • A higher scale of meaningful community contributions.
• Stable APIs, making it easier to interface with open source dependencies.
  • Facebook uses the same public API as open source
  • React Native releases that follow semantic versioning.
• A vibrant eco-system. High quality ViewManagers, native modules, and multiple platform support maintained by the community.
• Excellent documentation. Focus on helping users create high quality experiences, and up-to-date API reference docs.

We have identified the following focus areas to help us achieve this vision.

✂️ Lean Core​

Our goal is to reduce the surface area of React Native by removing non-core and unused components. We'll transfer non-core components to the community to allow it to move faster. The reduced surface area will make it easier to manage contributions to React Native.

WebView is an example of a component that we transferred to the community. We are working on a workflow that will allow internal teams to continue using these components after we remove them from the repository. We have identified dozens more components that we'll give ownership of to the community.

🎁 Open Sourcing Internals and 🛠Updated Tooling​

The React Native development experience for product teams at Facebook can be quite different from open source. Tools that may be popular in the open source community are not used at Facebook. There may be an internal tool that achieves the same purpose. In some cases, Facebook teams have become used to tools that do not exist outside of Facebook. These disparities can pose challenges when we open source our upcoming architecture work.

We'll work on releasing some of these internal tools. We'll also improve support for tools popular with the open source community. Here's a non-exhaustive list of projects we'll tackle:

• Open source JSI and enable the community to bring their own JavaScript VMs, replacing the existing JavaScriptCore from RN's initial release. We'll be covering what JSI is in a future post, in the meantime you can learn more about JSI from Parashuram's talk at React Conf.
• Support 64-bit libraries on Android.
• Enable debugging under the new architecture.
• Improve support for CocoaPods, Gradle, Maven, and new Xcode build system.

✅ Testing Infrastructure​

When Facebook engineers publish code, it's considered safe to land if it passes all tests. These tests identify whether a change might break one of our own React Native surfaces. Yet, there are differences in how Facebook uses React Native. This has allowed us to unknowingly break React Native in open source.

We'll shore up our internal tests to ensure they run in an environment that is as close as possible to open source. This will help prevent code that breaks these tests from making it to open source. We will also work on infrastructure to enable better testing of the core repo on GitHub, enabling future pull requests to easily include tests.

Combined with the reduced surface area, this will allow contributors to merge pull requests quicker, with confidence.

📜 Public API​

Facebook will consume React Native via the public API, the same way open source does, to reduce unintentional breaking changes. We have started converting internal call sites to address this. Our goal is to converge on a stable, public API, leading to the adoption of semantic versioning in version 1.0.

📣 Communication​

React Native is one of the top open source projects on GitHub by contributor count. That makes us really happy, and we'd like to keep it going. We'll continue working on initiatives that lead to involved contributors, such as increased transparency and open discussion. The documentation is one of the first things someone new to React Native will encounter, yet it has not been a priority. We'd like to fix that, starting with bringing back auto-generated API reference docs, creating additional content focused on creating quality user experiences, and improving our release notes.

Timeline​

We're planning to land these projects throughout the next year or so. Some of these efforts are already ongoing, such as JSI which has already landed in open source. Others will take a bit longer to complete, such as reducing the surface area. We'll do our best to keep the community up to date with our progress. Please join us in the Discussions and Proposals repository, a initiative from the React Native community that has led to the creation of several of the initiatives discussed in this roadmap.

The tail end of these changes were landed in this commit, and will become available in the 0.57 release.

To opt into this new implementation, please use the useWebKit prop:

<WebView
  useWebKit={true}
  source={{url: 'https://www.google.com'}}
/>

Improvements​

UIWebView had no legitimate way to facilitate communication between the JavaScript running in the WebView, and React Native. When messages were sent from the WebView, we relied on a hack to deliver them to React Native. Succinctly, we encoded the message data into a url with a special scheme, and navigated the WebView to it. On the native side, we intercepted and cancelled this navigation, parsed the data from the url, and finally called into React Native. This implementation was error prone and insecure. I'm glad to announce that we've leveraged WKWebView features to completely replace it.

Other benefits of WKWebView over UIWebView include faster JavaScript execution, and a multi-process architecture. Please see this 2014 WWDC for more details.

Caveats​

If your components use the following props, then you may experience problems when switching to WKWebView. For the time being, we suggest that you avoid using these props:

Inconsistent behavior:

automaticallyAdjustContentInsets and contentInsets (commit)

When you add contentInsets to a WKWebView, it doesn't change the WKWebView's viewport. The viewport remains the same size as the frame. With UIWebView, the viewport size actually changes (gets smaller, if the content insets are positive).

backgroundColor (commit)

With the new iOS implementation of WebView, there's a chance that your background color will flicker into view if you use this property. Furthermore, WKWebView renders transparent backgrounds differently from UIWebview. Please look at the commit description for more details.

Not supported:

scalesPageToFit (commit)

WKWebView didn't support the scalesPageToFit prop, so we couldn't implement this on the WebView React Native component.

As technology advances and mobile apps become increasingly important to everyday life, the necessity of creating accessible applications has likewise grown in importance.

React Native's limited Accessibility API has always been a huge pain point for developers, so we've made a few updates to the Accessibility API to make it easier to create inclusive mobile applications.

Problems With the Existing API​

Problem One: Two Completely Different Yet Similar Props - accessibilityComponentType (Android) and accessibilityTraits (iOS)​

accessibilityComponentType and accessibilityTraits are two properties that are used to tell TalkBack on Android and VoiceOver on iOS what kind of UI element the user is interacting with. The two biggest problems with these properties are that:

1. They are two different properties with different usage methods, yet have the same purpose. In the previous API, these are two separate properties (one for each platform), which was not only inconvenient, but also confusing to many developers. accessibilityTraits on iOS allows 17 different values while accessibilityComponentType on Android allows only 4 values. Furthermore, the values for the most part had no overlap. Even the input types for these two properties are different. accessibilityTraits allows either an array of traits to be passed in or a single trait, while accessibilityComponentType allows only a single value.
2. There is very limited functionality on Android. With the old property, the only UI elements that Talkback were able to recognize were “button,” “radiobutton_checked,” and “radiobutton_unchecked.”

Problem Two: Non-existent Accessibility Hints:​

Accessibility Hints help users using TalkBack or VoiceOver understand what will happen when they perform an action on an accessibility element that is not apparent by only the accessibility label. These hints can be turned on and off in the settings panel. Previously, React Native's API did not support accessibility hints at all.

Problem Three: Ignoring Inverted Colors:​

Some users with vision loss use inverted colors on their mobile phones to have greater screen contrast. Apple provided an API for iOS which allows developers to ignore certain views. This way, images and videos aren't distorted when a user has the inverted colors setting on. This API is currently unsupported by React Native.

Design of the New API​

Solution One: Combining accessibilityComponentType (Android) and accessibilityTraits (iOS)​

In order to solve the confusion between accessibilityComponentType and accessibilityTraits, we decided to merge them into a single property. This made sense because they technically had the same intended functionality and by merging them, developers no longer had to worry about platform specific intricacies when building accessibility features.

Background

On iOS, UIAccessibilityTraits is a property that can be set on any NSObject. Each of the 17 traits passed in through the javascript property to native is mapped to a UIAccessibilityTraits element in Objective-C. Traits are each represented by a long int, and every trait that is set is ORed together.

On Android however, AccessibilityComponentType is a concept that was made up by React Native, and doesn't directly map to any properties in Android. Accessibility is handled by an accessibility delegate. Each view has a default accessibility delegate. If you want to customize any accessibility actions, you have to create a new accessibility delegate, override specific methods you want to customize, and then set the accessibility delegate of the view you are handling to be associated with the new delegate. When a developer set AccessibilityComponentType, the native code created a new delegate based off of the component that was passed in, and set the view to have that accessibility delegate.

Changes Made

For our new property, we wanted to create a superset of the two properties. We decided to keep the new property modeled mostly after the existing property accessibilityTraits, since accessibilityTraits has significantly more values. The functionality of Android for these traits would be polyfilled in by modifying the Accessibility Delegate.

There are 17 values of UIAccessibilityTraits that accessibilityTraits on iOS can be set to. However, we didn't include all of them as possible values to our new property. This is because the effect of setting some of these traits is actually not very well known, and many of these values are virtually never used.

The values UIAccessibilityTraits were set to generally took on one of two purposes. They either described a role that UI element had, or they described the state a UI element was in. Most uses of the previous properties we observed usually used one value that represented a role and combined it with either “state selected,” “state disabled,” or both. Therefore, we decided to create two new accessibility properties: accessibilityRole and accessibilityState.

accessibilityRole

The new property, accessibilityRole, is used to tell Talkback or Voiceover the role of a UI Element. This new property can take on one of the following values:

• none
• button
• link
• search
• image
• keyboardkey
• text
• adjustable
• header
• summary
• imagebutton

This property only allows one value to be passed in because UI elements generally don't logically take on more than one of these. The exception is image and button, so we've added a role imagebutton that is a combination of both.

accessibilityStates

The new property, accessibilityStates, is used to tell Talkback or Voiceover the state a UI Element is in. This property takes on an Array containing one or both of the following values:

• selected
• disabled

Solution Two: Adding Accessibility Hints​

For this, we added a new property, accessibilityHint. Setting this property will allow Talkback or Voiceover to recite the hint to users.

accessibilityHint

This property takes in the accessibility hint to be read in the form of a String.

On iOS, setting this property will set the corresponding native property AccessibilityHint on the view. The hint will then be read by Voiceover if Accessibility Hints are turned on in the iPhone.

On Android, setting this property appends the value of the hint to the end of the accessibility label. The upside to this implementation is that it mimics the behavior of hints on iOS, but the downside to this implementation is that these hints cannot be turned off in the settings on Android the way they can be on iOS.

The reason we made this decision on Android is because normally, accessibility hints correspond with a specific action (e.g. click), and we wanted to keep behaviors consistent across platforms.

Solution to Problem Three​

accessibilityIgnoresInvertColors

We exposed Apple's api AccessibilityIgnoresInvertColors to JavaScript, so now when you have a view where you don't want colors to be inverted (e.g image), you can set this property to true, and it won't be inverted.

New Usage​

These new properties will become available in the React Native 0.57 release.

How to Upgrade​

If you are currently using accessibilityComponentType and accessibilityTraits, here are the steps you can take to upgrade to the new properties.

1. Using jscodeshift​

The most simple use cases can be replaced by running a jscodeshift script.

This script replaces the following instances:

accessibilityTraits=“trait”
accessibilityTraits={[“trait”]}

With

accessibilityRole= “trait”

This script also removes instances of AccessibilityComponentType (assuming everywhere you set AccessibilityComponentType, you would also set AccessibilityTraits).

2. Using a manual codemod​

For the cases that used AccessibilityTraits that don't have a corresponding value for AccessibilityRole, and the cases where multiple traits were passed into AccessibilityTraits, a manual codemod would have to be done.

In general,

accessibilityTraits= {[“button”, “selected”]}

would be manually replaced with

accessibilityRole=“button”
accessibilityStates={[“selected”]}

These properties are already being used in Facebook's codebase. The codemod for Facebook was surprisingly simple. The jscodeshift script fixed about half of our instances, and the other half was fixed manually. Overall, the entire process took less than a few hours.

Hopefully you will find the updated API useful! And please continue making apps accessible! #inclusion

The breaking changes dilemma, or, "when to release?"​

The Contributor's Guide explains the integration process that all changes to React Native go through. The project has is composed by many different tools, requiring coordination and constant support to keep everything working properly. Add to this the vibrant open source community that contributes back to the project, and you will get a sense of the mind-bending scale of it all.

With React Native's impressive adoption, breaking changes must be made with great care, and the process is not as smooth as we'd like. A decision was made to skip the April and May releases to allow the core team to integrate and test a new set of breaking changes. Dedicated community communication channels were used along the way to ensure that the June 2018 (0.56.0) release is as hassle-free as possible to adopt by those who patiently waited for the stable release.

Is 0.56.0 perfect? No, as every piece of software out there: but we reached a point where the tradeoff between "waiting for more stability" versus "testing led to successful results so we can push forward" that we feel ready to release it. Moreover, we are aware of a few issues that are not solved in the final 0.56.0 release. Most developers should have no issues upgrading to 0.56.0. For those that are blocked by the aforementioned issues, we hope to see you around in our discussions and we are looking forward to working with you on a solution to these issues.

You might consider 0.56.0 as a fundamental building block towards a more stable framework: it will take probably a week or two of widespread adoption before all the edge cases will be sanded off, but this will lead to an even better July 2018 (0.57.0) release.

We'd like to conclude this section by thanking all the 67 contributors who worked on a total of 818 commits (!) that will help make your apps even better 👏.

And now, without further ado...

The Big Changes​

Babel 7​

As you may know, the transpiler tool that allows us all to use the latest and greatest features of JavaScript, Babel, is moving to v7 soon. Since this new version brings along some important changes, we felt that now it would be a good time to upgrade, allowing Metro to leverage on its improvements.

If you find yourself in trouble with upgrading, please refer to the documentation section related to it.

Modernizing Android support​

On Android, much of the surrounding tooling has changed. We've updated to Gradle 3.5, Android SDK 26, Fresco to 1.9.0, and OkHttp to 3.10.0 and even the NDK API target to API 16. These changes should go without issue and result in faster builds. More importantly, it will help developers comply with the new Play Store requirements coming into effect next month.

Related to this, we'd like to particularly thank Dulmandakh for the many PRs submitted in order to make it possible 👏.

There are some more steps that need to be taken in this direction, and you can follow along with the future planning and discussion of updating the Android support in the dedicated issue (and a side one for the JSC).

New Node, Xcode, React, and Flow – oh my!​

Node 8 is now the standard for React Native. It was actually already being tested already, but we've put both feet forward as Node 6 entered maintenance mode. React was also updated to 16.4, which brings a ton of fixes with it.

We're dropping support for iOS 8, making iOS 9 the oldest iOS version that can be targeted. We do not foresee this being a problem, as any device that can run iOS 8, can be upgraded to iOS 9. This change allowed us to remove rarely-used code that implemented workarounds for older devices running iOS 8.

The continuous integration toolchain has been updated to use Xcode 9.4, ensuring that all iOS tests are run on the latest developer tools provided by Apple.

We have upgraded to Flow 0.75 to use the new error format that many devs appreciate. We've also created types for many more components. If you're not yet enforcing static typing in your project, please consider using Flow to identify problems as you code instead of at runtime.

And a lot of other things...​

For instance, YellowBox was replaced with a new implementation that makes debugging a lot better.

For the complete release notes, please reference the full changelog here. And remember to keep an eye on the upgrading guide to avoid issues moving to this new version.

A final note: starting this week, the React Native core team will resume holding monthly meetings. We'll make sure to keep everyone up-to-date with what's covered, and ensure to keep your feedback at hand for future meetings.

Happy coding everyone!

Lorenzo, Ryan, and the whole React Native core team

PS: as always, we'd like to remind everyone that React Native is still in 0.x versioning because of the many changes still undergoing - so remember when upgrading that yes, probably, something may still crash or be broken. Be helpful towards each other in the issues and when submitting PRs - and remember to follow the CoC enforced: there's always a human on the other side of the screen.

At Facebook, we're using React Native more than ever and for many important projects. One of our most popular products is Marketplace, one of the top-level tabs in our app which is used by 800 million people each month. Since its creation in 2015, all of Marketplace has been built with React Native, including over a hundred full-screen views throughout different parts of the app.

We're also using React Native for many new parts of the app. If you watched the F8 keynote last month, you'll recognize Blood Donations, Crisis Response, Privacy Shortcuts, and Wellness Checks – all recent features built with React Native. And projects outside the main Facebook app are using React Native too. The new Oculus Go VR headset includes a companion mobile app that is fully built with React Native, not to mention React VR powering many experiences in the headset itself.

Naturally, we also use many other technologies to build our apps. Litho and ComponentKit are two libraries we use extensively in our apps; both provide a React-like component API for building native screens. It's never been a goal for React Native to replace all other technologies – we are focused on making React Native itself better, but we love seeing other teams borrow ideas from React Native, like bringing instant reload to non-JavaScript code too.

Architecture​

When we started the React Native project in 2013, we designed it to have a single “bridge” between JavaScript and native that is asynchronous, serializable, and batched. Just as React DOM turns React state updates into imperative, mutative calls to DOM APIs like document.createElement(attrs) and .appendChild(), React Native was designed to return a single JSON message that lists mutations to perform, like [["createView", attrs], ["manageChildren", ...]]. We designed the entire system to never rely on getting a synchronous response back and to ensure everything in that list could be fully serialized to JSON and back. We did this for the flexibility it gave us: on top of this architecture, we were able to build tools like Chrome debugging, which runs all the JavaScript code asynchronously over a WebSocket connection.

Over the last 5 years, we found that these initial principles have made building some features harder. An asynchronous bridge means you can't integrate JavaScript logic directly with many native APIs expecting synchronous answers. A batched bridge that queues native calls means it's harder to have React Native apps call into functions that are implemented natively. And a serializable bridge means unnecessary copying instead of directly sharing memory between the two worlds. For apps that are entirely built in React Native, these restrictions are usually bearable. But for apps with complex integration between React Native and existing app code, they are frustrating.

We're working on a large-scale rearchitecture of React Native to make the framework more flexible and integrate better with native infrastructure in hybrid JavaScript/native apps. With this project, we'll apply what we've learned over the last 5 years and incrementally bring our architecture to a more modern one. We're rewriting many of React Native's internals, but most of the changes are under the hood: existing React Native apps will continue to work with few or no changes.

To make React Native more lightweight and fit better into existing native apps, this rearchitecture has three major internal changes. First, we are changing the threading model. Instead of each UI update needing to perform work on three different threads, it will be possible to call synchronously into JavaScript on any thread for high-priority updates while still keeping low-priority work off the main thread to maintain responsiveness. Second, we are incorporating async rendering capabilities into React Native to allow multiple rendering priorities and to simplify asynchronous data handling. Finally, we are simplifying our bridge to make it faster and more lightweight; direct calls between native and JavaScript are more efficient and will make it easier to build debugging tools like cross-language stack traces.

Once these changes are completed, closer integrations will be possible. Today, it's not possible to incorporate native navigation and gesture handling or native components like UICollectionView and RecyclerView without complex hacks. After our changes to the threading model, building features like this will be straightforward.

We'll release more details about this work later this year as it approaches completion.

Community​

Alongside the community inside Facebook, we're happy to have a thriving population of React Native users and collaborators outside Facebook. We'd like to support the React Native community more, both by serving React Native users better and by making the project easier to contribute to.

Just as our architecture changes will help React Native interoperate more cleanly with other native infrastructure, React Native should be slimmer on the JavaScript side to fit better with the JavaScript ecosystem, which includes making the VM and bundler swappable. We know the pace of breaking changes can be hard to keep up with, so we'd like to find ways to have fewer major releases. Finally, we know that some teams are looking for more thorough documentation in topics like startup optimization, where our expertise hasn't yet been written down. Expect to see some of these changes over the coming year.

If you're using React Native, you're part of our community; keep letting us know how we can make React Native better for you.

React Native is just one tool in a mobile developer's toolbox, but it's one that we strongly believe in – and we're making it better every day, with over 2500 commits in the last year from 500+ contributors.

This post uses Microsoft's TypeScript-React-Native-Starter repo as a guide.

Update: Since this blog post was written, things have gotten even easier. You can replace all the set up described in this blog post by running just one command:

npx react-native init MyAwesomeProject --template react-native-template-typescript

However, there are some limitations to Babel's TypeScript support, which the blog post above goes into in detail. The steps outlined in this post still work, and Artsy is still using react-native-typescript-transformer in production, but the fastest way to get up and running with React Native and TypeScript is using the above command. You can always switch later if you have to.

In any case, have fun! The original blog post continues below.

Prerequisites​

Because you might be developing on one of several different platforms, targeting several different types of devices, basic setup can be involved. You should first ensure that you can run a plain React Native app without TypeScript. Follow the instructions on the React Native website to get started. When you've managed to deploy to a device or emulator, you'll be ready to start a TypeScript React Native app.

You will also need Node.js, npm, and Yarn.

Initializing​

Once you've tried scaffolding out an ordinary React Native project, you'll be ready to start adding TypeScript. Let's go ahead and do that.

react-native init MyAwesomeProject
cd MyAwesomeProject

Adding TypeScript​

The next step is to add TypeScript to your project. The following commands will:

• add TypeScript to your project
• add React Native TypeScript Transformer to your project
• initialize an empty TypeScript config file, which we'll configure next
• add an empty React Native TypeScript Transformer config file, which we'll configure next
• adds typings for React and React Native

Okay, let's go ahead and run these.

yarn add --dev typescript
yarn add --dev react-native-typescript-transformer
yarn tsc --init --pretty --jsx react
touch rn-cli.config.js
yarn add --dev @types/react @types/react-native

The tsconfig.json file contains all the settings for the TypeScript compiler. The defaults created by the command above are mostly fine, but open the file and uncomment the following line:

{
  /* Search the config file for the following line and uncomment it. */
  // "allowSyntheticDefaultImports": true,  /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */
}

The rn-cli.config.js contains the settings for the React Native TypeScript Transformer. Open it and add the following:

module.exports = {
  getTransformModulePath() {
    return require.resolve('react-native-typescript-transformer');
  },
  getSourceExts() {
    return ['ts', 'tsx'];
  },
};

Migrating to TypeScript​

Rename the generated App.js and __tests_/App.js files to App.tsx. index.js needs to use the .js extension. All new files should use the .tsx extension (or .ts if the file doesn't contain any JSX).

If you tried to run the app now, you'd get an error like object prototype may only be an object or null. This is caused by a failure to import the default export from React as well as a named export on the same line. Open App.tsx and modify the import at the top of the file:

-import React, { Component } from 'react';
+import React from 'react'
+import { Component } from 'react';

Some of this has to do with differences in how Babel and TypeScript interoperate with CommonJS modules. In the future, the two will stabilize on the same behaviour.

At this point, you should be able to run the React Native app.

Adding TypeScript Testing Infrastructure​

React Native ships with Jest, so for testing a React Native app with TypeScript, we'll want to add ts-jest to our devDependencies.

yarn add --dev ts-jest

Then, we'll open up our package.json and replace the jest field with the following:

{
  "jest": {
    "preset": "react-native",
    "moduleFileExtensions": [
      "ts",
      "tsx",
      "js"
    ],
    "transform": {
      "^.+\\.(js)$": "<rootDir>/node_modules/babel-jest",
      "\\.(ts|tsx)$": "<rootDir>/node_modules/ts-jest/preprocessor.js"
    },
    "testRegex": "(/__tests__/.*|\\.(test|spec))\\.(ts|tsx|js)$",
    "testPathIgnorePatterns": [
      "\\.snap$",
      "<rootDir>/node_modules/"
    ],
    "cacheDirectory": ".jest/cache"
  }
}

This will configure Jest to run .ts and .tsx files with ts-jest.

Installing Dependency Type Declarations​

To get the best experience in TypeScript, we want the type-checker to understand the shape and API of our dependencies. Some libraries will publish their packages with .d.ts files (type declaration/type definition files), which can describe the shape of the underlying JavaScript. For other libraries, we'll need to explicitly install the appropriate package in the @types/ npm scope.

For example, here we'll need types for Jest, React, and React Native, and React Test Renderer.

yarn add --dev @types/jest @types/react @types/react-native @types/react-test-renderer

We saved these declaration file packages to our dev dependencies because this is a React Native app that only uses these dependencies during development and not during runtime. If we were publishing a library to NPM, we might have to add some of these type dependencies as regular dependencies.

You can read more here about getting .d.ts files.

Ignoring More Files​

For your source control, you'll want to start ignoring the .jest folder. If you're using git, we can just add entries to our .gitignore file.

# Jest
#
.jest/

As a checkpoint, consider committing your files into version control.

git init
git add .gitignore # import to do this first, to ignore our files
git add .
git commit -am "Initial commit."

Adding a Component​

Let's add a component to our app. Let's go ahead and create a Hello.tsx component. It's a pedagogical component, not something that you'd actually write in an app, but something nontrivial that shows off how to use TypeScript in React Native.

Create a components directory and add the following example.

// components/Hello.tsx
import React from 'react';
import {Button, StyleSheet, Text, View} from 'react-native';

export interface Props {
  name: string;
  enthusiasmLevel?: number;
}

interface State {
  enthusiasmLevel: number;
}

export class Hello extends React.Component<Props, State> {
  constructor(props: Props) {
    super(props);

    if ((props.enthusiasmLevel || 0) <= 0) {
      throw new Error(
        'You could be a little more enthusiastic. :D',
      );
    }

    this.state = {
      enthusiasmLevel: props.enthusiasmLevel || 1,
    };
  }

  onIncrement = () =>
    this.setState({
      enthusiasmLevel: this.state.enthusiasmLevel + 1,
    });
  onDecrement = () =>
    this.setState({
      enthusiasmLevel: this.state.enthusiasmLevel - 1,
    });
  getExclamationMarks = (numChars: number) =>
    Array(numChars + 1).join('!');

  render() {
    return (
      <View style={styles.root}>
        <Text style={styles.greeting}>
          Hello{' '}
          {this.props.name +
            this.getExclamationMarks(this.state.enthusiasmLevel)}
        </Text>

        <View style={styles.buttons}>
          <View style={styles.button}>
            <Button
              title="-"
              onPress={this.onDecrement}
              accessibilityLabel="decrement"
              color="red"
            />
          </View>

          <View style={styles.button}>
            <Button
              title="+"
              onPress={this.onIncrement}
              accessibilityLabel="increment"
              color="blue"
            />
          </View>
        </View>
      </View>
    );
  }
}

// styles
const styles = StyleSheet.create({
  root: {
    alignItems: 'center',
    alignSelf: 'center',
  },
  buttons: {
    flexDirection: 'row',
    minHeight: 70,
    alignItems: 'stretch',
    alignSelf: 'center',
    borderWidth: 5,
  },
  button: {
    flex: 1,
    paddingVertical: 0,
  },
  greeting: {
    color: '#999',
    fontWeight: 'bold',
  },
});

Whoa! That's a lot, but let's break it down:

• Instead of rendering HTML elements like div, span, h1, etc., we're rendering components like View and Button. These are native components that work across different platforms.
• Styling is specified using the StyleSheet.create function that React Native gives us. React's stylesheets allow us to control our layout using Flexbox, and style using other constructs similar to those in CSS.

Adding a Component Test​

Now that we've got a component, let's try testing it.

We already have Jest installed as a test runner. We're going to write snapshot tests for our components, let's add the required add-on for snapshot tests:

yarn add --dev react-addons-test-utils

Now let's create a __tests__ folder in the components directory and add a test for Hello.tsx:

// components/__tests__/Hello.tsx
import React from 'react';
import renderer from 'react-test-renderer';

import {Hello} from '../Hello';

it('renders correctly with defaults', () => {
  const button = renderer
    .create(<Hello name="World" enthusiasmLevel={1} />)
    .toJSON();
  expect(button).toMatchSnapshot();
});

The first time the test is run, it will create a snapshot of the rendered component and store it in the components/__tests__/__snapshots__/Hello.tsx.snap file. When you modify your component, you'll need to update the snapshots and review the update for inadvertent changes. You can read more about testing React Native components here.

Next Steps​

Check out the official React tutorial and state-management library Redux. These resources can be helpful when writing React Native apps. Additionally, you may want to look at ReactXP, a component library written entirely in TypeScript that supports both React on the web as well as React Native.

Have fun in a more type-safe React Native development environment!

You can check out the app at https://www.build.com/app.

Features​

Our app is full featured and includes everything that you’d expect from an e-commerce app: product listings, search and sorting, the ability to configure complex products, favorites, etc. We accept standard credit card payment methods as well as PayPal, and Apple Pay for our iOS users.

A few standout features you might not expect include:

1. 3D models available for around 40 products with 90 finishes
2. Augmented Reality (AR) to allow the user to see how lights and faucets will look in their home at 98% size accuracy. The Build.com React Native App is featured in the Apple App Store for AR Shopping! AR is now available for Android and iOS!
3. Collaborative project management features that allow people to put together shopping lists for the different phases of their project and collaborate around selection

We’re working on many new and exciting features that will continue to improve our app experience including the next phase of Immersive Shopping with AR.

Our Development Workflow​

Build.com allows each dev to choose the tools that best suit them.

• IDEs include Atom, IntelliJ, VS Code, Sublime, Eclipse, etc.
• For Unit testing, developers are responsible for creating Jest unit tests for any new components and we’re working to increase the coverage of older parts of the app using jest-coverage-ratchet.
• We use Jenkins to build out our beta and release candidates. This process works well for us but still requires significant work to create the release notes and other artifacts.
• Integration Testing include a shared pool of testers that work across desktop, mobile and web. Our automation engineer is building out our suite of automated integration tests using Java and Appium.
• Other parts of the workflow include a detailed eslint configuration, custom rules that enforce properties needed for testing, and pre-push hooks that block offending changes.

Libraries Used in the App​

The Build.com app relies on a number of common open source libraries including: Redux, Moment, Numeral, Enzyme and a bunch of React Native bridge modules. We also use a number of forked open source libraries; forked either because they were abandoned or because we needed custom features. A quick count shows around 115 JavaScript and native dependencies. We would like to explore tools that remove unused libraries.

We're in the process of adding static typing via TypeScript and looking into optional chaining. These features could help us with solving a couple classes of bugs that we still see:

• Data that is the wrong type
• Data that is undefined because an object didn’t contain what we expected

Open Source Contributions​

Since we rely so heavily on open source, our team is committed to contributing back to the community. Build.com allows the team to open source libraries that we've built and encourages us contribute back to the libraries that we use.

We’ve released and maintained a number of React Native libraries:

• react-native-polyfill
• react-native-simple-store
• react-native-contact-picker

We have also contributed to a long list of libraries including: React and React Native, react-native-schemes-manager, react-native-swipeable, react-native-gallery, react-native-view-transformer, react-native-navigation.

Our Journey​

We’ve seen a lot of growth in React Native and the ecosystem in the past couple years. Early on, it seemed that every version of React Native would fix some bugs but introduce several more. For example, Remote JS Debugging was broken on Android for several months. Thankfully, things became much more stable in 2017.

Navigation Libraries​

One of our big recurring challenges has been with navigation libraries. For a long time, we were using Expo’s ex-nav library. It worked well for us but it was eventually deprecated. However, we were in heavy feature development at the time so taking time to change out a navigation library wasn’t feasible. That meant we had to fork the library and patch it to support React 16 and the iPhone X. Eventually, we were able to migrate to react-native-navigation and hopefully that will see continued support.

Bridge Modules​

Another big challenge has been with bridge modules. When we first started, a lot of critical bridges were missing. One of my teammates wrote react-native-contact-picker because we needed access to the Android contact picker in our app. We’ve also seen a lot of bridges that were broken by changes within React Native. For example, there was a breaking change within React Native v40 and when we upgraded our app, I had to submit PRs to fix 3 or 4 libraries that had not yet been updated.

Looking Forward​

As React Native continues to grow, our wishlist to our community include:

• Stabilize and improve the navigation libraries
• Maintain support for libraries in the React Native ecosystem
• Improve the experience for adding native libraries and bridge modules to a project

Companies and individuals in the React Native community have been great about volunteering their time and effort to improve the tools that we all use. If you haven’t gotten involved in open source, I hope you’ll take a look at improving the code or documentation for some of the libraries that you use. There are a lot of articles to help you get started and it may be a lot easier than you think!

Three years ago, a GitHub issue was opened to support input accessory view from React Native.

In the ensuing years, there have been countless '+1s', various workarounds, and zero concrete changes to RN on this issue - until today. Starting with iOS, we're exposing an API for accessing the native input accessory view and we are excited to share how we built it.

Background​

What exactly is an input accessory view? Reading Apple's developer documentation, we learn that it's a custom view which can be anchored to the top of the system keyboard whenever a receiver becomes the first responder. Anything that inherits from UIResponder can redeclare the .inputAccessoryView property as read-write, and manage a custom view here. The responder infrastructure mounts the view, and keeps it in sync with the system keyboard. Gestures which dismiss the keyboard, like a drag or tap, are applied to the input accessory view at the framework level. This allows us to build content with interactive keyboard dismissal, an integral feature in top-tier messaging apps like iMessage and WhatsApp.

There are two common use cases for anchoring a view to the top of the keyboard. The first is creating a keyboard toolbar, like the Facebook composer background picker.

In this scenario, the keyboard is focused on a text input field, and the input accessory view is used to provide additional keyboard functionality. This functionality is contextual to the type of input field. In a mapping application it could be address suggestions, or in a text editor, it could be rich text formatting tools.

The Objective-C UIResponder who owns the <InputAccessoryView> in this scenario should be clear. The <TextInput> has become first responder, and under the hood this becomes an instance of UITextView or UITextField.

The second common scenario is sticky text inputs:

Here, the text input is actually part of the input accessory view itself. This is commonly used in messaging applications, where a message can be composed while scrolling through a thread of previous messages.

Who owns the <InputAccessoryView> in this example? Can it be the UITextView or UITextField again? The text input is inside the input accessory view, this sounds like a circular dependency. Solving this issue alone is another blog post in itself. Spoilers: the owner is a generic UIView subclass who we manually tell to becomeFirstResponder.

API Design​

We now know what an <InputAccessoryView> is, and how we want to use it. The next step is designing an API that makes sense for both use cases, and works well with existing React Native components like <TextInput>.

For keyboard toolbars, there are a few things we want to consider:

1. We want to be able to hoist any generic React Native view hierarchy into the <InputAccessoryView>.
2. We want this generic and detached view hierarchy to accept touches and be able to manipulate application state.
3. We want to link an <InputAccessoryView> to a particular <TextInput>.
4. We want to be able to share an <InputAccessoryView> across multiple text inputs, without duplicating any code.

We can achieve #1 using a concept similar to React portals. In this design, we portal React Native views to a UIView hierarchy managed by the responder infrastructure. Since React Native views render as UIViews, this is actually quite straightforward - we can just override:

- (void)insertReactSubview:(UIView *)subview atIndex:(NSInteger)atIndex

and pipe all the subviews to a new UIView hierarchy. For #2, we set up a new RCTTouchHandler for the <InputAccessoryView>. State updates are achieved by using regular event callbacks. For #3 and #4, we use the nativeID field to locate the accessory view UIView hierarchy in native code during the creation of a <TextInput> component. This function uses the .inputAccessoryView property of the underlying native text input. Doing this effectively links <InputAccessoryView> to <TextInput> in their ObjC implementations.

Supporting sticky text inputs (scenario 2) adds a few more constraints. For this design, the input accessory view has a text input as a child, so linking via nativeID is not an option. Instead, we set the .inputAccessoryView of a generic off-screen UIView to our native <InputAccessoryView> hierarchy. By manually telling this generic UIView to become first responder, the hierarchy is mounted by responder infrastructure. This concept is explained thoroughly in the aforementioned blog post.

Pitfalls​

Of course not everything was smooth sailing while building this API. Here are a few pitfalls we encountered, along with how we fixed them.

An initial idea for building this API involved listening to NSNotificationCenter for UIKeyboardWill(Show/Hide/ChangeFrame) events. This pattern is used in some open-sourced libraries, and internally in some parts of the Facebook app. Unfortunately, UIKeyboardDidChangeFrame events were not being called in time to update the <InputAccessoryView> frame on swipes. Also, changes in keyboard height are not captured by these events. This creates a class of bugs that manifest like this:

On iPhone X, text and emoji keyboard are different heights. Most applications using keyboard events to manipulate text input frames had to fix the above bug. Our solution was to commit to using the .inputAccessoryView property, which meant that the responder infrastructure handles frame updates like this.

Another tricky bug we encountered was avoiding the home pill on iPhone X. You may be thinking, “Apple developed safeAreaLayoutGuide for this very reason, this is trivial!”. We were just as naive. The first issue is that the native <InputAccessoryView> implementation has no window to anchor to until the moment it is about to appear. That's alright, we can override -(BOOL)becomeFirstResponder and enforce layout constraints there. Adhering to these constraints bumps the accessory view up, but another bug arises:

The input accessory view successfully avoids the home pill, but now content behind the unsafe area is visible. The solution lies in this radar. I wrapped the native <InputAccessoryView> hierarchy in a container which doesn't conform to the safeAreaLayoutGuide constraints. The native container covers the content in the unsafe area, while the <InputAccessoryView> stays within the safe area boundaries.

Example Usage​

Here's an example which builds a keyboard toolbar button to reset <TextInput> state.

class TextInputAccessoryViewExample extends React.Component<
  {},
  *,
> {
  constructor(props) {
    super(props);
    this.state = {text: 'Placeholder Text'};
  }

  render() {
    const inputAccessoryViewID = 'inputAccessoryView1';
    return (
      <View>
        <TextInput
          style={styles.default}
          inputAccessoryViewID={inputAccessoryViewID}
          onChangeText={text => this.setState({text})}
          value={this.state.text}
        />
        <InputAccessoryView nativeID={inputAccessoryViewID}>
          <View style={{backgroundColor: 'white'}}>
            <Button
              onPress={() =>
                this.setState({text: 'Placeholder Text'})
              }
              title="Reset Text"
            />
          </View>
        </InputAccessoryView>
      </View>
    );
  }
}

Another example for Sticky Text Inputs can be found in the repository.

When will I be able to use this?​

The full commit for this feature implementation is here. <InputAccessoryView> will be available in the upcoming v0.55.0 release.

Happy keyboarding :)

This blog post talks about some interesting things for React and React Native developers:

• AWS Amplify, a declarative library for JavaScript applications using cloud services
• AWS AppSync, a fully managed GraphQL service with offline and real-time features

AWS Amplify​

React Native applications are very easy to bootstrap using tools like Create React Native App and Expo. However, connecting them to the cloud can be challenging to navigate when you try to match a use case to infrastructure services. For example, your React Native app might need to upload photos. Should these be protected per user? That probably means you need some sort of registration or sign-in process. Do you want your own user directory or are you using a social media provider? Maybe your app also needs to call an API with custom business logic after users log in.

To help JavaScript developers with these problems, we released a library named AWS Amplify. The design is broken into "categories" of tasks, instead of AWS-specific implementations. For example, if you wanted users to register, log in, and then upload private photos, you would simply pull in Auth and Storage categories to your application:

import { Auth } from 'aws-amplify';

Auth.signIn(username, password)
    .then(user => console.log(user))
    .catch(err => console.log(err));

Auth.confirmSignIn(user, code)
    .then(data => console.log(data))
    .catch(err => console.log(err));

In the code above, you can see an example of some of the common tasks that Amplify helps you with, such as using multi-factor authentication (MFA) codes with either email or SMS. The supported categories today are:

• Auth: Provides credential automation. Out-of-the-box implementation uses AWS credentials for signing, and OIDC JWT tokens from Amazon Cognito. Common functionality, such as MFA features, is supported.
• Analytics: With a single line of code, get tracking for authenticated or unauthenticated users in Amazon Pinpoint. Extend this for custom metrics or attributes, as you prefer.
• API: Provides interaction with RESTful APIs in a secure manner, leveraging AWS Signature Version 4. The API module is great on serverless infrastructures with Amazon API Gateway.
• Storage: Simplified commands to upload, download, and list content in Amazon S3. You can also easily group data into public or private content on a per-user basis.
• Caching: An LRU cache interface across web apps and React Native that uses implementation-specific persistence.
• i18n and Logging: Provides internationalization and localization capabilities, as well as debugging and logging capabilities.

One of the nice things about Amplify is that it encodes "best practices" in the design for your specific programming environment. For example, one thing we found working with customers and React Native developers is that shortcuts taken during development to get things working quickly would make it through to production stacks. These can compromise either scalability or security, and force infrastructure rearchitecture and code refactoring.

One example of how we help developers avoid this is the Serverless Reference Architectures with AWS Lambda. These show you best practices around using Amazon API Gateway and AWS Lambda together when building your backend. This pattern is encoded into the API category of Amplify. You can use this pattern to interact with several different REST endpoints, and pass headers all the way through to your Lambda function for custom business logic. We’ve also released an AWS Mobile CLI for bootstrapping new or existing React Native projects with these features. To get started, just install via npm, and follow the configuration prompts:

npm install --global awsmobile-cli
awsmobile configure

Another example of encoded best practices that is specific to the mobile ecosystem is password security. The default Auth category implementation leverages Amazon Cognito user pools for user registration and sign-in. This service implements Secure Remote Password protocol as a way of protecting users during authentication attempts. If you're inclined to read through the mathematics of the protocol, you'll notice that you must use a large prime number when calculating the password verifier over a primitive root to generate a Group. In React Native environments, JIT is disabled. This makes BigInteger calculations for security operations such as this less performant. To account for this, we've released native bridges in Android and iOS that you can link inside your project:

npm install --save aws-amplify-react-native
react-native link amazon-cognito-identity-js

We're also excited to see that the Expo team has included this in their latest SDK so that you can use Amplify without ejecting.

Finally, specific to React Native (and React) development, Amplify contains higher order components (HOCs) for easily wrapping functionality, such as for sign-up and sign-in to your app:

import Amplify, { withAuthenticator } from 'aws-amplify-react-native';
import aws_exports from './aws-exports';

Amplify.configure(aws_exports);

class App extends React.Component {
...
}

export default withAuthenticator(App);