Bringing the New React Native Architecture to the OSS Community - Fall Edition

Awesome. So hi everyone. Thank you very much for joining me today. We're going to talk about the new React Native architecture and how we bring it to the open source community. As I believe a lot of you here might be React and not React Native developer, I hope you have heard about React 18. So to make it simple for you, the new architecture is how we're going to bring React 18 to mobile and to native.

A little story about myself. I'm actually an Android engineer working on the React Native team. You can find me online as Kurtinico on Twitter and on GitHub. And so the new architecture of React Native has been in the media for quite some time. If you actually go on line and search for React Native new architecture, you can find quite some content, I would say. And let's look through some of the videos that you will be seeing. The first one. It's from ReactConf 2018.

So well we have been talking so long about it. Like last year, my colleague Joshua gave a talk about it at React Native EU and it was all about the new architecture within meta. But now the point is, okay. So we did our rollout internally. How do we bring it out? How do we let the open source community use it as well? So if we look at a timeline of the new architecture, again, it was started as a six-month project in 2018. But it turns out that the biggest product that we have at meta that uses React Native, which is the Facebook app, is quite complicated. And trust me, engineers managed to use every possible edge case and every possible API of React Native to squeeze every performance out of this framework. So it took us, at the end of the day, nearly three years to do the full rollout of the new architecture on the Facebook app. But then from there, as I said, we looked at ourselves and we asked, OK, how do we roll this out in the open source? And so this talk is going to be about this, exactly. Like, how do we let people outside of meta benefit from React 18 and the new architecture on Native?

So to do, again, one step back and really understand why we are bringing the new architecture. As I said before, we want to bring all the benefits of React 18 to Native. But it's not only that. If you've been doing React Native, you probably know that there is this component which is sort of crucial in the React Native architecture, which is called the Bridge. It's essentially a component where it allows the JavaScript layer to communicate with the native layer and everything is passed through this bridge as JSON. And as you can imagine, it's a huge bottleneck. So, first we wanted to get rid of it.

As we wrote a lot of the internals of our architecture, we actually took a stance and wrote them once. Like, we used to have an Android renderer and an iOS renderer, which were, like, not exactly aligned. So we wrote a lot of internals in C++ and this allowed us to share some platform-specific optimizations between the two platforms.

On top of that, using the bridge meant that we could not really benefit from type safety. That's why the new architecture has a new component called the codegen, which brings type safety inside our API. And finally, you should think of the new architecture as the foundational stone for a lot of features that will be built on top of React 18 in these new APIs and will be delivered also to native. So, we need to make sure people are using those APIs.

So, what are the core concepts of the new architecture? We call them pillars. And we have several of them. First, we have the new renderer. And this is what actually uses React 18. And this new renderer is often referenced as fabric. Then we have the new native module system, which allows you to interact with the native platform and call APIs for Android and iOS. And we call this mechanism turbo modules. Then, as I said before, we wanted to bring type safety in our formula. That's why we introduced a new component called the Cogen. And the last pillar is bridge-less mode. So, once everything is in place, you have all of your components compatible with fabric and everything compatible with turbo modules and so on, you can fully turn off the bridge.

So how this will look like on Android. We are gonna generate some Java classes. So we'll have like an abstract class with the constructor and a method that respects the signature.

Here you define an interface and you say that you have a function which answers the ultimate question and you register this module. And again, the point is this function and this signature. The Cogen is able to understand that you are declaring a public API that you will use on your JavaScript word. And important information here is that there is an input which is a string and an output which is a number. From this information we can generate a lot of the boilerplate code that you don't have to write.

The thing is that web developers that work with React Native don't really like to write android and iOS code so we're trying to make this like as simple as possible. So how this will look like on Android. We are gonna generate some Java classes. So we'll have like an abstract class with the constructor and a method that respects the signature. So in this case this will be an abstract method that accepts a JavaString in input and returns a double. So we do all the type, we resolve the types to the platform specific types that every platform accepts. So on iOS, for example, you're going to have Objective-C protocol that accepts NSString and returns an NSNumber. Obviously at some point you need to write the business logic, like someone should answer the ultimate question, we can't answer that for you, but yeah, we're trying to simplify like a lot of boilerplate code that is not needed to be written anymore.

Okay, so yeah, like this new architecture required us to do a lot of changes across the board as you can imagine because now there is a code gen to run and there is yeah, a lot of moving parts. So, we took a stance at our build tools, so a lot of changes are actually coming on our integration with the underlying platform, and here there is a little bit of a challenge, because at Meta internally we use a build tool, which is called Buck, which is also open source, and the new architecture for us internally works on top of this, which is great, but we can't expect people outside of Meta to use Buck because it's, I mean it's open source, but we want to use the build tools which are specific to the platform you run on.

So on Android you will run on Gradle, and we took a lot of time to sort of make sure that everything integrates well. There will be some C++ code, so there will be also CMake files that are handled by Gradle. Little disclaimer, a lot of people told me I don't want to see C++ code, so we sort of encapsulated everything, web developers will not have to see CMake or C++ code at all, but it's under the hood and can be used for performance-specific applications. We wrote our Gradle plugin and effectively in React Native 71, this removes a lot of the legacy code and a lot of the build failures users were experiencing when creating your Android app, this logic has been completely rewritten. The TLDR here is that within your architecture, we're actually cleaning up a lot of the legacy code and legacy build infrastructure which built up on our open source code during the years.

On iOS, similarly we do have cocoa pods. And again, we took the stand here to clean up things a bit. We wrote a lot of the logic, now we have a full suite of Ruby scripts which are easier to use, they're smaller and they're fully tested. So hopefully you will see less build failures in the future.

Okay. So, another component that we actually, it's not necessarily part of the new architecture but we spend a lot of time on it and we envisioned the new architecture with these things bundled together is our JavaScript engine called Hermes. So, in the documentation for the new architecture you will actually find it recommended. And we can provide better support. Like if your app is crashing and you have Hermes we can know more what's going on. So, we invite users to use this engine and raise any issues you might have.

From React Native 69 we actually did a change which is called bundled Hermes. So, every version of React Native now comes with a specific version of this JavaScript engine which we know being fully compatible with the version of React Native. In the past we had scenarios where the engine was built at a given time and React Native was built at another time and they were not really compatible with each other. So, now you have an engine which is fully compatible with your version of React Native every time and you can just use it. From React Native 70 which we released a couple of months ago Hermes is actually the default engine. So, all the new projects will have Hermes enabled by default and if you don't want it because you might have a valid reason you will need to disable it.

A couple of updates also that we did on the modern languages side of things, like a lot of people ask us to use different programming languages when they use React Native. And here I have a lot of updates actually. TypeScript. When we released the first version of the New Architecture docs the most up-voted comment was I don't want to use flow, which I can totally understand. Our first version of the docs were like essentially our internal wiki polished and open sourced. And internally at Meta we use flow, but outside that's not the case. So we had to rebuild a lot of code and support.

Now TypeScript is actually fully supported by Cogent. And I'll tell you more, actually in 71, React Native 71, which is supposed to be released in the near future, matters of weeks at this point, TypeScript will actually be the default language. So the new projects will all be created with TypeScript. We are shipping types together with React Native. And we sort of took a closer look at our ecosystem and we thought like, we want to support TypeScript more. Next one on Android Kotlin. So it's currently fully supported. Actually, you can use Kotlin all over the places in React Native, I think the talk before will actually tell you a little bit, a lot more about it, so make sure you stay tuned. Our website is also fully migrated and bilingual. So all the examples on React Native .DEV are both in Java and Kotlin. And you can fully use the one you want and the template as we did for TypeScript. We might also update the template to use Kotlin. We haven't done this yet, but this is set to open sometime in the future. And last one, Zwift. Well, a lot of IS engineers are asking us to use Zwift, and yeah, this is a little bit more complicated because of how Zwift and C++ interoperate. I hope to have answers for this in the future. We're keeping a closer look at it and hopefully we'll know more.

So timeline. So what is happening and when? I mentioned some things like some versions of React Native, but let me recap them. So we started early this year, like the rollout of the new architecture started actually this year with React Native 68. That's the first version of React Native which supports those new APIs. Then in React Native 69 we actually added React 18 support. These are a little bit confusing, but effectively the way our React and React Native interact is that React Native decides which version of React to use.

And the first version of React Native that supports 18 is 69. So you need to be in 69 at least, you can't just change it. And we ship bundled arms, which I talked about before on 70, a lot of stuff and a lot of improvements actually on the experience related to the new architecture.

I don't have time to deep dive on all of them, but some of those points have actually been highly requested by the community. So we released new architecture on 68, and people came to us and told us, this is awesome, but it doesn't work for me because A, B, C and D. And we heard what people were telling us, and we developed a lot of improvements on build time, a lot of developer experience improvements, and so on. That made into 70. And into 71, we simplified the template a lot. As I said before, we removed all the C++ code. Essentially, now there is no C++ code at all, unless you really want to see it because you might have, I don't know, your crypto library, and you want to do your crazy stuff with C++, then you can opt-in and have C++ code that you are responsible of maintaining.

And then what's next? Well, today, Infinity and beyond because, as I said, we want to hear what works and what doesn't work for you. We want to hear from the community, like, yeah, this is valuable for me or this is not valuable. So please try those new APIs. They are still considered experimental. We are not enabling them by default. We will be doing that at some point, but in this stage, we are still collecting feedback and hearing from library authors, app authors, what is not working for them. I briefly talked about React 18 and React Native. Let me reiterate. Just to clarify the interactions between the two frameworks. If you are on React Native 67 or 68, you are effectively running React 17. Like, the version of React is 17. And some of those new APIs like star transition will not work. To fully use React 18 and all those concurrent APIs, you need to be at least on React Native 69. And you can't... You just can't change the React version. Like, React Native decides for you. And here the catch is that on 69 and 70, to use those new APIs you need to be on the new architecture. Like, you need to enable the new architecture to use concurrent React. If you try to use those APIs but you're not on the new architecture, they will just not work. They will be empty implementations and so on.

So, it's crucial that if you have a React Native app and you want to stay up to date with how the ecosystem is evolving and how our framework is evolving, you take a look at those... Yeah. At those new APIs. And what does it mean take a look at those APIs? We created a lot of docs. And we are still iterating on it and it's actually all about the docs. Because those APIs, which we released in 68, were actually available there for so long. Like, I think we added the fabric in React Native 64 or 65. But they were just not documented. I remember listening to this podcast, the React Native show, where folks were talking about like, yeah, some library are trying to use it, but don't know how they need to reverse engineer the framework code, which is not great. So that's why now we have an official doc. So you will find the new section on the website called the new architecture, where everything is explained why we did certain changes, how to create a new library, how to create a new app, and so on. And also, a dedicated section on migration. How do I go from a library or an app, which is non architecture compatible to to have the full support for architecture. On top of this, we now have a new section called architecture, which contains design docs on our our internals work and how the render works and so on. Like people, especially like if, for example, reanimated, which is a popular library, wanted to know how we work internally and what are the principles to follow and so on. So we took a stance and also wrote those docs the new up template, like whatever happens when you do and picks react native in it. My awesome app has been updated to let you try in your architecture easily. So what does this mean? It means that on iOS, instead of calling pod install, after you set up your project, you will call our city in Newark enabled one pod install. And this will reconfigure your project to let you try the new architecture. On Android instead, there is a file called Gradle dot properties, and they're Newark enabled from false to true. And you can just react native run Android, and you will be running the those those new APIs. Effectively, you will see on metro message that tells you like, Hey, you're running your app with fabric set to true, and so on. So you are effectively running the new architecture.

Super quick on a couple of other things that we also did, because I see I'm out of time. But a couple of a couple of content more. First, we start the working group. It's called the new architecture working group. And this is similar to the react 18 working group we started a couple of years ago. And it's a collaboration space where you can ask questions, share your libraries, give updates on how your library is migrating to the new architecture and connect with other people which are also looking into those API's. It's if you open the working group, it looks like read only. But actually you can apply on the working group using the link below. And I'm going to review your application and send you an invite.

We also have samples, like stuff that effectively runs. So we have an app sample repo which contains multiple branches. And every branch explains to you how to migrate to one app from a given version of React Native, and so on. And every migration is done step by step. So you would see all the commits on how we enable the various stuff. We also have a library sample which contains examples on how to create a turbo module or native turbo module or fabric component which is backward compatible. So you can create something that works both in the old and in the new architecture.

And with this, I really hope that in the future, when I search React Native new architecture at some point, I will hear your stories like you will write about it and tell me like, hey, it was a complete mess because your folks missed here, here, and there, or talks were great or whatever. We really want to hear your migration story. We are iterating on this. We know some APIs are not as great and shiny as you like. And so, we did update some of them. So, that's why the old architecture is still experimental. And it's crucial now that people try this and tell us like what works and what doesn't work. Yeah. And I want to recall that all of our tools are actually open source. We are fully committed to this ecosystem. We spent a lot of time talking with partners, with library maintainers. And we just want to make those tools as great as possible and as valuable for everyone. And thank you very much for listening. Thank you very much, Nicola.

It was like you enlightened us about the new architecture. And yeah, we do have some time for questions. Yeah. It's we have some questions and I'll start straight away. When is a good time to switch for existing apps to the new architecture or what's, in your opinion, the timeline for switching to the new architecture or what dependencies? Yeah. So this is quite a crucial question. I would say, so when we started, beginning of this year, we had a lot of libraries, like a lot of popular libraries, which had no support for Fabric or TurboModules, which made immigration really hard, especially on Fabric. TurboModules are really backward compatible in a sense that you can just enable them. And if you have libraries which are migrated, or libraries which are not migrated, they will work well each other. On the UI side, instead, it's way harder. And we're actually taking a lot of effort on this side to let migrated and non-migrated libraries work well together. Hopefully, there will be more on this topic in the future. But as of now, my recommendation is to go through your list of dependencies, and see most of them, like a lot of them are actually migrated. For example, Reanimated, React Native screens, they're all migrated, and they have a version which is Fabric compatible. But you might sometimes use a library which is unmaintained. Well, that's unfortunate. I would say it's probably also an opportunity to take a stance at which libraries you're depending on, and depending on libraries which are not maintained, it's generally a security risk. So maybe it's also the opportunity for apps to take a look at what they're depending on and cleaning up some of those or potentially reviving some of those libraries, forking them and updating them.

I totally agree with you. I saw so many great libraries migrating to the new architecture, like reanimated, React Native SVG, gesture handlers, and you also named the screens. There is a lot of traction also from the community, but I think that as a junior developer or someone that has no understanding of C++ or Kotlin, or the new architecture itself, it's really hard to just go and update something, right? It is, and that's also why we keep on considering the new architecture as experimental.

I would say, if you were to ask me, is it production ready? I would tell you, well, the biggest React Native app, it's running on it, so well, it is production ready. Is it easy to use? We are iterating on it. There are some rough edges, for example, on 70, build time on Android was like, people told me, I need to wait half an hour to build. On 71, we used build time so much, like literally like now it's a matter of seconds. And those changes require feedback loop from your end and us also having time to fix them. All right.

And I think we have a question which got answered during your talk. Do you need to migrate all the libraries to the new architecture? It is backwards compatible. And I think that you mentioned about backwards compatibility. But if you can add more. Yeah, let me reiterate. So the backward compatibility story is as I said, a little bit more complicated on the two components, on the two pillars, native modules. So whatever is not UI is backward compatible. You can use once you turn on the new architecture, you can use turbo modules or legacy native modules, as we call them on the UI. Instead, if you enable fabric, like if you enable the new architecture and you have a component which is not compatible with fabric, you will see like a purple box that tells you like a here. I should have rendered something, but this is not fabric compatible. So I can't render it. This gives you immediate feedback if something is going on or not. But we are also working with folks at Microsoft on a tool called AlignDepth or Depth Check. You might have heard it's part of this collection of tools called RnxKit, which is a set of tools that Microsoft is building. And they are like, we are collaborating and iterating on providing more information on which libraries are effectively compatible with new architecture and not. On the React Native libraries directory, there is a label that tells you like, hey, this is compatible or not. But yeah, I mean, once this whole thing will be stable, trust me, there will be an easy way to know which libraries are compatible and which not.

Yeah, that was a great answer. And I also saw Lorenzo tweeting, yesterday I think, about the line depths and the RnX kit. It's like getting stronger and stronger, I would say, to support this new architecture. I think I have one more question, just quickly.

In terms of performance, did it worth all the work you have done? So for us, yes. We were able to develop a feature like pre-rendering or like, do stuff that the previous architecture was not possible. Like, would not allow us to do.

Now people come to us and say like, yeah, enable the new architecture and expect, like, you know, spikes of gains here and there. That's not the case. Like, the architecture is a, as I said, is a foundational stone for tools that you have to build on top of. Like, if you were doing something which was the bridge, then doing that with the new architecture, doing that synchronously going from JavaScript directed to C plus plus, will give you performance gains. But that depends on your use case. It's not that there is no immediate performance gain out of it.

And yeah, it really depends on your use case, on your libraries, and what you're doing. And we will see more and more libraries that will use those new APIs, and you will have to migrate to benefit from from those new libraries. Great. Yeah. Thank you very much. Thanks a lot, Nicola.