Bringing the New React Native Architecture to the OSS community

Hi everyone, and thank you very much for joining me in this session. Today, we're going to talk about bringing the new React Native architecture to the open source community.

Mandatory slide about myself. My name is Nicola Corti and I work as an Android engineer in the React Native team at Meta. You can find me online as cortinico either on Twitter or on GitHub.

As we have so much to cover, let's jump straight into the content. So if you were to search today React Native new architecture on Google or on YouTube, you will find actually quite a lot of content. I want to focus a little bit on YouTube because there are several videos that are actually really valuable. And as you can see, from the dates, we actually started talking about React Native new architecture in 2018 at React Conf. So much time has passed. The last talk is from 2021 React Native EU from my colleague Joshua Gross. I actually want to invite you to watch the talk if you haven't yet.

Joshua in his talk was talking about the timeline of the new architecture and how long it took us to do the rollout of this technology, which essentially is a major rewrite of the React Native internals within the Facebook app. It took us essentially three years. And so I want to start from this timeline, from what Joshua said in that talk. And where do we go from there? So he mentioned that, again, we started in 2018 in Q2. And initially, this project was supposed to last roughly six months. But the reality is that React Native is used so extensively inside the Facebook app, and a lot of teams try to squeeze as many milliseconds of performance from every screen that rolling out such a big change was quite a challenge. That's why it took us so long.

And in 2021, we finished to fully roll out the new architecture, specifically the new render fabric on all the surfaces of the Facebook app. And then, well, what's next? What's next is that we looked at the open source community and we actually wanted to allow everyone out there to benefit from this new major rewrite of the internals of React Native. So what comes next is actually rolling out the new architecture outside of meta and empower everyone to use what we developed so far. And that's where we are now. So end of 2021 and beginning of 2022, we started creating content and material to empower people outside of meta to use the new architecture. So today I'm going to present a lot of material and content that we developed so far and that will help you embrace the new architecture of React Native.

But first, I want to reiterate a little bit on the why because I get asked over and over, why should I migrate to the new architecture? And if you still haven't got it, the why is all about the bridge. The new architecture is essentially a substantial rewrite on a lot of components of the internals of React Native that allows us first to get rid of the bridge. The bridge was a component that was making possible the communication between the JavaScript layer and the underlying native layers. With a new architecture, this component is essentially gone. And with that comes a lot of improvements in terms of performance and generally like is a restructure of the internals of the framework. As we wrote a lot of the internals, we actually took a stand to re-implement a lot of the rendering pipelines and internal components of React Native using a shared language.

So we decided to use C++ to, again, have a single implementation of the renderer that allows us essentially to reduce a lot of discrepancies between different platforms. Historically, there used to be different renders for Android and for iOS, so things will behave a little bit different on the two platforms. Thanks to the new architecture, we are essentially having a single implementation of our internals and we can ensure that whatever we develop is consistent within the two platforms. Similarly, we can also re-share a lot of the optimizations we develop for one single platform across all of them. This is possible thanks to having a single implementation of the of the renderer and internals. We also took a stance at the developer experience and we try to implement a lot of best practices and blend them inside the core component of the React Native new architecture. Specifically, we develop a component called the Cogent that allows us to bring type safety inside our code base. And finally, the new architecture is, as I said, about performance, but also about a lot of new capabilities that we are building on top of those new foundation. So it's sort of like we took a stance, we wrote a lot of internals thinking about what new capabilities this allows us to develop in the in the coming years. So whenever we refer to the new architecture, we refer to a lot of components that we often call pillars. So the new architecture of React Native is actually composed by several pillars.

We have Fabric, the new renderer. We have a new native module system, which we call the Turbo Module. We have a component which allows to generate code, which is the Cogent, and we also have the Bridgeless Mode.

So once all the pieces are together, we have the capability to essentially remove the bridge component, as I said before, this is called Bridgeless Mode. I want to zoom in a bit on the Cogent and give you a glimpse of what we envision is the developer experience on the new architecture.

So, as I mentioned before, type safety, and the whole idea behind the Cogent is, let's say the developer is writing a TypeScript file which defines the API of a native module. In this case, they will define a spec like an interface with a declaration of all the capabilities of this module. For example, this module is able to answer the ultimate question and takes in input a string and returns a number, and the user will then just register this to a module.

The Cogent works at this level. It focuses on this function and the input type and the return type. And from that it generates a lot of boilerplate code that in the past, developers will have to write manually for both Android and iOS. So let's take a look at that. On Android, we're going to generate an abstract class with constructor and a specific abstract method that adheres to the signature of the spec that we saw before. So we are going to have a function that takes an input, a string and returns a double. It's an abstract function, so it's up to you to implement it and provide the correct business logic. Similarly, on iOS, we are going to have an Objective-C protocol that takes in input on NSString and returns an NSNumber. So we do all the heavy lifting of all the typing from JavaScript layer to the underlying layer, and we generate code for you. So you just have to implement the business logic.

I also want to talk a little bit about the build tools, because as we worked on the developer experience and we introduced the CodeGen, we had to do a lot of changes on how things are built. Specifically, there's also a lot of C++ code that we need to build now, which previously we would have not need to. So there are some changes that you might see, and I want to clarify a little bit of topics.

As you probably know, the build world within Meta and outside is a bit different, because internally we use Buck to build a lot of our code, while externally we can't expect users to. We install Buck and use it for building everything. So we need to adapt to the platform standards. Specifically on Android, we have Gradle. So what we did, we did a lot of work around the C++ code. Users will find references to CMake files or Android.mk files, which will allow them to build their native code. So we don't have just Java and Kotlin code anymore, but we also have some C++ code to build. For Java and Kotlin instead, we spent a lot of time building the React Native Gradle plugin. This is a set of build logic and tools that allows to build essentially React Native application.

And this is going to replace in the long run, the good old React.Gradle file that we all included. On iOS, we follow the similar approach. So we have CocoaPods, and we developed custom logic in Ruby that allows us to call the code gen and integrate within your build logic.

I also want to spend a couple of seconds talking about Hermes, our in-house JavaScript engine. So if you read the documentation for the new architecture, you will find that Hermes is currently recommended. So we highly suggest you to use it, because it's the way how we can support you better. We are moving towards having Hermes as the default engine for React Native. And starting from React Native 69, every version of React Native will come with a so-called bundled Hermes version. It means that for every version of React Native, we are creating a version of Hermes that we know is compatible with that specific version of React Native. This brings a lot of improvements in terms of stability for the engine and essentially gives you an engine that is ready for you to use bundled together with React Native.

I also want to spend a couple of seconds on modern languages, because we get a lot of questions on this side. On the TypeScript side of things, whenever we release, when we release the first iteration of the new architecture documentation, we add a lot of comments from users that were unhappy that the initial iteration of our tooling supported only flow. We obviously want to make sure that React Native is used and supported within the broad ecosystem of web and mobile developers. So we spent time adding support for TypeScript. So I'm happy to announce that the code gen for the new architecture now fully supports also TypeScript. So you can write your spec in either flow or TypeScript and the code gen will just generate code for Android and iOS starting from those.

Going on Android, we have Kotlin. So on the Kotlin side of things, Kotlin is luckily fully supported in React Native. You can write your module and components in Kotlin. We are also doing a lot of effort in updating our website to be bilingual. So if you open this issue, React Native website 3018, you will find what's the current status of the immigration of the website in being bilingual. So you will find docs for Java and Kotlin on several pages already. And you can expect the new app template to be updated to be fully Kotlin in the future. We just haven't done it yet because we want to focus on the new architecture for now. Or you can expect this change to come in the near future.

On iOS instead, we have Swift. A lot of users asking us how they can do to write their component and modules with Swift. Well, that's a little bit more complicated. We're actually looking into it, but due to interoperability between Swift and C++, things are a bit complicated. So expect some news in the future. But sadly, I don't have anything to share at this point in time. So now I talked a lot about new architecture. I also want to clarify a little bit what's the timeline and what are the versions that we released to give you an idea of what we released so far and what's coming next. React Native 68 is the first version that fully supports the new architecture. Theoretically, the new architecture was already released some versions ago, but we haven't provided an easy way to use it. So 68 is the first version that has a one-liner that you can enable to just try the new architecture and start writing Fabric Components and Turbo modules. React Native 69 is the first version that adds supports for React 18. If you followed the development on the React side of things, React 18 is a major release of React, contains a lot of new features, and I'm going to talk about the implications within React and React Native in the next slide. As I mentioned, 69 also contains bundled Ermos alongside a lot of improvements on the new architecture side of things. Then we have 70, which is the next versions that we're going to cut.

It will contain several other features that will help users on the new architecture, specifically Android auto-linking support, which was auto-linking support for new architecture was already there for iOS but was missing on Android. So we had to do some adaptation, and this will land in 70.

There will be also CMake support, end-to-end, so users can write their C++ code with CMake. There will be also support for Unified Code Gen config. We received a lot of feedback that the way how the Code Gen was configured was different between Android and iOS, so we took a stance and fixed this.

And well 71, I like to say to the infinity and beyond. React Native is developed at Meta, but is also a project where the community is placed first. So we really hear what's the feedback from our users and we try to integrate it as much as possible. Some of the features that will be going out in 70 are actually there because we received feedback from users which they really needed those features. So if you feel that there is something that is not working for you, please let us know, tell us what is not working, tell us how we can improve the new architecture experience. We are so looking forward to that.

As I said, I want to spend some seconds on the interactions between React Native and React 18. And here I have a table for you to explain. So if you are on React Native 67 or React Native 68, you're essentially on React 17. Even if you go in your package.json and you change your version of React, you are still consuming React 17. The reason is because the versioning of the two frameworks is tightly coupled. You can't just bump one or another, things would not work correctly. React Native is having a bundled version of React, the React render inside. So we'll discard the version that you pass in the package.json.

If you want to use React 18, you then need to upgrade to React Native 69, but here there is a catch. React 18 ships with a lot of concurrent features and new APIs such as star transition. Those APIs rely on the React Native new architecture. So if you are on 69 and you enable the new architecture, you can use those APIs and benefit from those concurrent features. If you are on 69 but you're still on the old architecture, you're still using a legacy version of React. Even if it's React 18, you will not benefit from those APIs. So I hope you understand how critical it is for users also to update to the new architecture because you will not benefit from those new improvements and API that we worked on in the last years.

Okay, so I spoke a lot about frameworks, updates, and so on. Now, I also mentioned about the new architecture documentation and material, but I haven't presented that yet. So I want to spend this last minute talking about which docs we have available for you. And I want to stress how docs are important because when I was listening to this episode of the React Native show, I remember they asked the audience, what are you still looking forward in 2022? And one of the comments was the new architecture. But a lot of other frameworks have been using some pieces of the new architecture. But what is missing is the docs. And that's actually true. The new architecture was there, and it could have been used in some form since previous versions of React Native. But without proper docs, the community will never understand how to use it properly. And it will be too hard for them to use. So let's look at what we have so far. First, we have the official docs. So inside the guides section of React Native, there is a new section called the new architecture that contains instructions on how to enable the new architecture. From the perspective of a library author and from the perspective of an app author. We are going to expand this documentation in the coming weeks and months.

So please stay tuned as we have more to share. I also want to mention that we have a new section on the website called architecture. This section contains a lot of deep dives. And documentation about the internal soft react native. We have been asked for this kind of docs a lot in the past. We spent time polishing our documentation around internals and sharing diagrams and explaining how things work internally. Little disclaimer, this deep dives are not for everyone. If you're using react native for the first time, you probably don't want to know the internals of the frameworks. But if you want to contribute or if you want to develop a more advanced component, you might need those information. I hope you will find it useful.

So now let's talk about the new app template. The new app template is what you see whenever you do react native in it. My awesome app. And we wanted this to be the primary entry point to the new architecture. That's why we worked on this part so much. And so for iOS, we extended it at pod install time. So normally you would run pod install, but now you can run it with this environment variable, NewArchEnabled set to one, and that will configure your project to actually use the new architecture. You can just run with run iOS and you will be effectively running an Android app, an iOS app on the new architecture. For Android, similarly, we have a file called Gradle properties and a property there called NewArchEnabled, you can just change it from false to true, and that will enable the new architecture for you. Again, you can run it with run Android and you will be running an Android application on the new architecture. If you want to be 100% sure that you're on the new architecture, you can check on Metro that you're running an app with fabric true and initial props concurrent root set to true. That means that you are using fabric, turbo modules, the new architecture and react team with concurring capabilities and everything you need.