Bringing the New React Native Architecture to the OSS Community

Hi everyone. Thank you very much for being on stage. As you heard before, well the hot topic in the React Native Ecosystem is the new architecture. So today, I have the pleasure to talk about bringing the new architecture to the open source community. And well you might have seen this talk already earlier in the year but a lot of things have changed and my team, the React team, has been developing a lot of new features and new improvements to let you enjoy the new architecture.

So today, we're going to focus on some of those as well. And well, a couple of words about myself, as mentioned, I'm an Android engineer on the React Native team, you can find me online as Kurtinico on Twitter and on GitHub. So let's get started because we have so much to cover.

And if you were to search React Native new architecture on Google or on YouTube today, you will find quite a lot of content and actually want to focus on some of it. Like specifically on YouTube, you will find those videos. And if you look at the dates, they're quite indicative on how much time we spent on building the new architecture. We started talking about it in 2018, but it's only until 2021 that we effectively fully rolled out the new architecture internally. And well, this is a testament to really how complicated this new architecture is.

And yeah, I want to stress again on the timeline here. We started in 2018 in Q2, and this started initially as a six-month project. Like literally we do planning every half at Meta and Facebook by then. And we just thought like, yeah, in six months, we're gonna make it and we're gonna update the internals and we're gonna benefit from it and everyone would be happy. That was not quite true because specifically inside the Facebook app, React Native is used extensively on thousands of surfaces and product engineers have been squeezing any possible performance gain from React Native, from the old architecture already. So trying to change the engine while the plane was flying quite fast turned out to be really challenging.

So it took us nearly three years and then we said, okay, so we are done. Amazing. How do we let the open source community now use it? And, well, here is basically more or less where I jumped in on the team and I realized this is like a really amazing and quite intricate challenge. So today we're going to focus on what are those challenges in details, what is in your architecture and what we're doing to let the open source community use it. So, if Gant hasn't convinced you already on why you want to look into the new architecture, let me reiterate.

So the new architecture is all about the bridge. Our goal is trying to get rid of this bottleneck. On top of that, we actually took a stance and did some pretty strong architectural changes, which will impact every React Native developer. First, we rewrote our internals using a cross-platform programming language, in this case, being C++. That's also the reason why a lot of developers came to us and told us, why do I see C++ code in my project? I'm not sure I want to see that. But the good thing of this is that now we can write features and optimizations just once in our shared render, and make sure that every platform that uses React Native are benefiting from it.

So, again, for example, view flattening previously was an optimization that was developed only on Android. And you had no view flattening on iOS. So now you can benefit from it because we wrote it in C++ and it's shared across all the platforms.

We also wanted to introduce type safety in our architecture. We wanted to get rid of having string references all over the places and this is possible thanks to a component called the CodeGen, which now generates code for you starting from a representation of your API that you provide to React Native.

And finally, you should think of the new architecture as the foundational stone for a lot of new capabilities that we'll be releasing in the future. Some of those haven't been released yet, some of those are in main, we haven't talked about it and so on, but there will be a lot of new features built on top of this new architecture. So, it's crucial that we have all the users move over to this new ARC because you will not benefit from new improvements from now on.

So, what is effectively the new architecture? We call it like the new architecture is like an umbrella term that helps us to reference a set of pillars, which are first our new renderer, which is codenamed fabric. You will find it all over the places in the web and in our documentation. Then we also rewrote a native module system and we codenamed this the turbo module. Then we introduced a component to provide type safety in our formula, which is called the code gen. And then when everything is in place, when you have all of your components that are fabric compatible and all of your modules, which are turbo modules compatible, you can effectively get rid of the bridge, and we call this the bridgeless mode.

So going into deep dive into all of those pillars will take me quite a lot of time, but I want just to give you a glimpse of the type safety I was mentioning before. So let me focus a bit on the code gen. So the idea behind the code gen is that we let you write like a spec file, like a representation of how your API should look like. So in this case, you're going to provide a spec file, which, as we thought, answer the ultimate question, and you're going to register it. And the code gen will work specifically here on this function, and will understand that this is something that expects a stringing input and returns a number in output. From this information, the code gen generates Android and iOS code. So we're going to like create a lot of boilerplate that, historically, developers would like to write.

As we rolled out the new architecture, we realized that it's not just about those core components. There are a lot of other corollaries and things that we have to look into, one of it being the build tools. Meta things are a little bit different internally than how they are in the open-source space. Specifically, inside Meta, we build everything with Buck.

On iOS, the story is really similar. We're going to create an Objective-C protocol that, again, understands the types and provides your platform-specific types, like NSString and NSNumber. As we rolled out the new architecture, we realized that it's not just about those core components. There are a lot of other corollaries and things that we have to look into, one of it being the build tools. Meta things are a little bit different internally than how they are in the open-source space. Specifically, inside Meta, we build everything with Buck. But we can't expect that people in the open-source use Buck for building everything. That's why we had to take a stance at our build system and extend them.

So, on Android, we worked a lot on Gradle, and yeah, you would see a lot of changes in our Gradle pipeline. Specifically, we introduced CMake files. Those are needed to let you build C++ code. There is also a lot of Java and Kotlin code, as always. And this is built by the React Native Gradle plugin, which is our new build integration point for Android. And this is set to replace the React Gradle file, which was like legacy and historical. And this is the essentially the component that is responsible of invoking the code gen, let you opt into the new architecture, and so on.

On iOS, similarly we worked a lot on our Cocoapods integration. So we wrote a lot of Ruby scripts, we wrote a lot of legacy build infrastructure here. Also the reason why I'm mentioning this, you might say like, yeah, obviously you have Cocoapods and Gradle stuff, but otherwise people can build. This is one of the first failure point of React Native. Like, when you, like, one of the biggest concern we received is like, I upgrade. Nothing builds anymore. Well, there were a lot of legacy code that within architecture we took stance we wrote, we wrote a lot of tests for it. So hopefully things will get better over time. We also looked at our JavaScript engine. And, yeah, we did a lot of work with the Hermes team. Hermes is our in-house JavaScript engine. It's currently recommended for the new architecture. So if you read the documentation, it would be, like, pointed out as one of the components that you need to use. Starting from React Native 0.69, we did a lot of changes inside React Native and we developed what is called the bundled Hermes. It means for every version of React Native we are preparing a version of Hermes that is fully compatible with it. Starting from React Native 0.70, it's also the default engine. If you don't want to use it, you will have to turn it off. The reason I mention this is because, again, this is another it's effectively not necessary for the architecture but it's highly recommended because it's where we are taking a closer look at our debugging experience and where we have a dedicated team that can help us understand what's going on if you have a crash with Hermes turned on. If you don't have Hermes, it's going to be hard for us to prioritize that and it will be harder to get the bug solved. Also some updates on programming languages. Because this is quite an odd topic and, again, a lot of developers are asking us to use their favorite programming language with React Native. And here we have updates on every layer. On web, well, TypeScript.

This was the when we released the first version of the new architecture documentation, the number one comment was, I don't want to write my spec in Flow. Thanks. And I totally understand that. That's why we spent time writing a version of the code that understands TypeScript spec files. So today you can write spec files in TypeScript and everything works.

On this point, also, React Native 0.71 is going to have TypeScript types bundled inside NPM package, hopefully making the life of React Native developers easier.

On the platform layer on Android, we have Kotlin. And here, I'm personally a really big fan of it. Happy to chat about it afterwards if you want to know more about it. But, it's fully supported in React Native already so you can write your app in Kotlin. And you don't need to have Java anymore. We also rewrote the whole website to be bilingual. This was like a community driven effort and we received a lot of pull requests to essentially convert our snippets from Java only to be Java and Kotlin. So now you will find examples in both languages. And in the future you might expect the template to actually be converted to Kotlin. There are a number of benefits of having a single JVM language in your pipeline so we're going to look into that in the future.

While for iOS, the situation is a little bit more complicated. People would love to use Swift and while we're looking into it. The problem here is the interoperability support between Swift and C++. There are updates here but we have nothing to share at this stage yet.

So now I talked a lot about updates and things that are coming. I actually want to make my point a little bit more concrete talking about timeline like when things happened. So let's look at the versions of React Native we released and we are going to release in the future. Earlier this year we released React Native 68. This is the first version of React Native that adds support for the new architecture. Theoretically the new architecture was already there since I believe React Native 64 although it was really hard to use so 68 is the first version that adds one-liner that lets you enable or disable the new architecture. From there we received tons of feedback and people told us this is great but and those but converted into features that we developed and we release in the following versions. So in React Native 69 we released a couple of critical things. First one React 18 support. So 69 is the first version of React Native that supports React 18.

I'm going to talk about React 18 and React Native versions in the next slide but also another feature is bundle dermis. So the like better support firms within React Native.

Then 70. 70 was quite a milestone release for the new architecture because again, tons of features which were really critical. First, dermis as default. Then we added support for auto linking on Android for native libraries. So before 70, you would have to manually link your new architecture libraries which was quite a pain. We had the full support for CMake and the unified code and config. So to briefly talk about this last point, before 70, you will add to specify the code and configuration for Android and for iOS in two different files making things really fragmented. So we heard the community and we thought like, well, this is poor developer experience, so let's fix it. And that went out in 70.

But then what's next? So we have 71. 71 is going to be released really soon. I don't know when but in the near future. And, well, we already have some things lined up. First, the new app template is going to be extremely simplified in 71. One feedback that we received again was like when I create a new project, I see seven C++ file and I don't know what they do. Do I need to have them here? Do I need to know what they do? And so on. And we felt like probably we don't need to expose the C++ file to our users. We can try to make better and encapsulate them. This is one of the changes beyond many that we're shipping in 71. So, again, on 71 we are doubling down on our new architecture experience and making things easier for our developers. And there are a lot of other changes which you will find described in the release notes for 71.

And then 72. Well, with the infinity and beyond here I would say because a lot of those changes have been implemented because people stopped us at conferences and meetups and told us, hey, I tried the new architecture but it doesn't work for me because, or I can't migrate my library because this and that. So, please, take the opportunity. Today we are five or six from the React team, the React native team here today. So, please, stop us. Tell us like, hey, this is not working, it's complete crap, because, or this is awesome because. So, please use us as much as you can.

So, I promise I will talk briefly about React 18 and React Native support. And here it is. This nice table. So, if you are on React Native 67 or 68, you are effectively on React 17. So, the ARC here is that you can't just go in your package.JSON and change your React version, do yarn install and pretend that that will work. That's not how React and React Native interact each other. React Native effectively rebundles the render from React to a version that we decide when we cut the branch of React Native. So, we decide which version of React you're gonna use. That's how the magic happens. So, if you want to be on 18, you actually need to be on 69 or next feature.

And here is the catch. React team comes with a lot of new concurrent features like new hooks, like start transition, use transition and so on. If you want to benefit from those concurrent feature, you need to be on the new architecture. If you are on the old architecture, you are effectively using a legacy renderer of React. We are offering these two render mode to let people slowly transition to the new architecture. But if you were to ask me when is a good time to migrate to the new architecture, you already know the answer. It's now. So, start looking into it. Because we are putting a lot of effort on the migration story and listening to the community. Now is a great time to do migrations. Later, it's going to be harder and painful.

So, now let's walk through some of the material that we prepared to let you start with the new architecture and understand what to do. And let me stress on how we believe the docs are important here. It's really all about the docs. I remember listening to this episode of the React Native Show and folks were mentioning how some libraries were already leveraging some of the new architecture capabilities by reverse engineering our code, which is really not great. So, that's why we thought, OK. Let's write some official docs. And you're going to find in the reactnative.dev website a new guide on the left called the new architecture, which gives you an introduction on those pillars, what they do, why we did them, and so on. And also, there is another guide just below called migrating to the new architecture, which explains to both app developers and library developers how to migrate their component and modules to the new architecture. We also spent some time writing architectural docs.

This has been another highly requested docs that we haven't had the time in the past to write. If you jump on the architecture tab on top, you will find the architecture overview. And here we have deep dives and pages that explains you how Fabric works internally or how the Hermes integration works, and so on.

We updated the new app template to let you start it with the new project. So we believe that the entry point for the new architecture should be just a one-liner when you create a new app. So how would it look like? Well, you're going to create your app with React Native in it, and then on iOS, the entry point is on the pod install. So normally you would just pod install your project, and you will be fine, while within your architecture, you're going to run again, pod install, but with this new arc enabled variable set to true. Then once you run iOS, you are effectively running on iOS app within your architecture, and you can start playing around and so on. On Android, similar story. We do have a file called Gradle.properties with one line called new arc enabled. Just change it from false to true, and you run Android, and you are done. And once you run it, effectively, Metro will tell you on console that your application is running with Fabric set to true and concurrent roots set to true. That means that everything is enabled, you're going to experience the new render, everything, magic, amazing stuff, and so on. And also make sure you watch Lorenzo's talk just after mine, because now I'm telling you, like, yeah, this is awesome. Just change one line and start, everything works. And as long as you don't have external dependencies which are not migrated to the new architecture. And Lorenzo's going to really talk about it because that's one crucial point.

To help people migrate those libraries, actually, one initiative that we started is the new architecture working group. This is built on top of the experience that we built as part of the React 18 working group and is essentially discussion-only GitHub repo that you can join. And there are several sections. Again, some about docs, some about libraries. So if you're a library author, you can join, you can ask for support. We have some libraries in the past migrate that they got stuck and so on. The working group might look like read-only, but if you apply using the link in the readme, we're going to check the application, I'll let you through. We're just, like, doing some spam prevention with this form. And then we also wrote some samples. So, specifically, we have the app sample repository which is basically an application, like it's actually a collection of branches where on every branch we show how to migrate one app from one version of React Native to another step by step. So you will effectively see every commit with an informative commit message and instructions on why we did that step and so on. And we are doing this for different React Native versions to show you how these set of steps actually shrinks as we make this migration story easier. We also have a library sample repo that follows a similar approach but it explains how to migrate a component or a module to the new architecture.

Finally, again, at this point, the real deal with the new architecture are libraries. Like if you depend on a library which exposes a component or a module which is not compatible with the new architecture you're going to have a hard time. So that's why it's crucial the library maintainers start looking into the architecture and migrate them.

We already have a set of libraries that have been migrated. We are getting more and more reports of libraries being updated to the new architecture. But again, if you haven't migrated your app or specifically your library, please let us know what is blocking you and yeah, let's try to make this better all together.

And with this, I really hope that in one year from now, six months from now, or whenever, when I'm going to search React Native in your architecture on Google, I will find your migration story. Like, we really want to hear what works for you and what didn't work. Like, we are trying to do our best, like, hearing from the community, again, what are the blockers and so on. But it's crucial that you tell us what works and what really didn't work. Specifically, for this, we are going to have a discussion room today with some of the folks from Meta, from Infinite Red, from Microsoft, and so on, to talk about the future of React Native in your architecture. Make sure you join, you pass through, and we're going to chat about some of the things I mentioned today.