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 improvements 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 I 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. And we just thought, like, yeah, in six months we're going to make it. And we're going to update the internals. And we're going to 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 that 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 the new 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, like, 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. So we wanted to get rid of having string references all over the places. And this is possible thanks to a component called the code gen 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 moved over to this new arc because you would 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 the 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 has one method, 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 string in 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. So on Android, this looks like this, it's basically a Java abstract class where we take care of like all the boilerplate like constructors and so on, and we generate an abstract method called answer the ultimate question. We understand the types and we provide you platform specific types like string and double in this case. This is abstract because, well, we can't magically write your business logic, but we can help you write all the skeleton around it. On iOS, the story is really similar. We're going to create objective C protocol that again understands the types and provides you platform specific types like NSString and NSNumber. So as we rolled out the new architecture, we realized that it's not just about those core components, there are a lot of other corollary and things that we have to look into. One of it being the build tools. And yeah, 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 will 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 Gradle file, which was legacy and historical. And this is essentially the component that is responsible for 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, you know, CocoaPods and Gradle stuff. Otherwise, people can't build. This is one of the first failure points 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 your architecture. We took a 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, and it's currently recommended for the new architecture. So if you read the documentation, it will 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 that for every version of react Native, we are preparing a version of Hermes that is known to be fully compatible with it. Starting from react Native 0.70, Hermes is also the default engine for react Native. So when you create a new project, you're going to have Hermes enabled by default. If you don't want to use it, you will have to turn it off. The reason why I mention this is because, again, this is another it's effectively not necessary for the new architecture, but it's highly recommended because it's where we are taking a closer look at our debugging experience and where we have, like, 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 the other people are asking us to use their favorite programming language with react Native. And here we have updates on every layer. On web, well, typescript, like, 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. So, 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 effectively write your app in Kotlin, like, 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, well, the situation is a little bit more complicated. People will love to use Zwift, and well, we're looking into it. The problem here is the interoperability support between Zwift 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 has 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 bots converted into features that we developed and we released 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 bundled Hermes, so better support for Hermes 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 Hermes 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 added full support for CMake and the unified code gen config. So to briefly talk about this last point, before 70, you will add to specify the code gen 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++ files 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 thought, like, probably we don't really 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, to the infinity and beyond here, I will 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 promised 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 TLDR 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 going to 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 18 comes with a lot of new concurrent features, like new hooks, like start transition, use transition and so on. And if you want to benefit from those concurrent features, you need to be on the new architecture. If you are on the old architecture, you are effectively using a legacy render 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 is 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 well, 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 on 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, like, okay, let's write some official docs. And you're going to find in the react Native.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. So 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 to you how fabric works internally or how the Hermes build 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, like, a one liner when you create a new app. So what 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. And then once you run iOS, you are effectively running an 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 root set to true. That means that everything is enabled. You're going to experience the new renderer, 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. Yeah, as long as you don't have external dependencies which are not migrated to the new architecture. And Lorenzo is going to really talk about it, because that's really, like, 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 a 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 your 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. 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, like, 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 that library maintainers start looking into the new 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 altogether. 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. We really want to hear what works for you and what didn't work. Like, you know, 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, the new architecture. So make sure you join, you pass through, and we're going to chat about some of the things I mentioned today. And with this, I want to recall that all of our tools are open source and we are so excited to receive so many contributions and I want to thank you very much for listening.