At the end of 2021, we successfully rolled out the New React Native Architecture in the Facebook app. Now, it’s time to empower every React Native developer on the globe to use the New React Native Architecture, both the new Fabric renderer and the new TurboModule system. But migrating an entire ecosystem to a New Architecture is no easy task. To support the whole community in this endeavor, we lined up a set of tools and materials that will help both app and library developers to join us in this journey. In the talk, we will present how the New React Native Architecture looks in the OSS space. We will discuss the impact this will have on developing React Native projects. Lastly, we will cover what we learned from the React Native New Architecture migration at Meta, and how you can tackle your migration in your organization.
Bringing the New React Native Architecture to the OSS Community - Fall Edition
AI Generated Video Summary
1. Introduction to React Native Architecture
We're going to talk about the new React Native architecture and how we bring it to the open source community. The new architecture is how we're going to bring React 18 to mobile and to native. The new architecture of React Native has been in the media for quite some time. We did our rollout internally. How do we bring it out? How do we let the open source community use it as well? 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? We want to bring all the benefits of React 18 to Native. But it's not only that. We wanted to get rid of the Bridge component, which is a huge bottleneck in the React Native architecture.
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?
2. Core Concepts of the New Architecture
We wrote the internals of our architecture once, allowing us to share optimizations between Android and iOS. The new architecture introduces the codegen component for type safety and serves as a foundation for future features. The core concepts, or pillars, include the new renderer (fabric), the native module system (turbo modules), the Cogen for type safety, and bridge-less mode. On Android, Java classes will be generated.
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.
3. Architecture, Build Tools, and Hermes
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.
4. Bundled Hermes and Default Engine
5. Updates on Modern Languages and Timeline
A couple of updates on the modern languages side. TypeScript is now fully supported by Cogent and will be the default language in React Native 71. Kotlin is fully supported on Android. The React Native .DEV website is fully migrated and bilingual, supporting both Java and Kotlin. The use of Zwift and C++ interoperability is being explored. The new architecture rollout began with React Native 68, and React 18 support was added in React Native 69.
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.
6. React Native Versions and New Architecture
The first version of React Native that supports 18 is 69. We ship bundled arms, with a lot of improvements on the experience related to the new architecture. We released new architecture on 68, with many improvements on build time and developer experience. In React Native 71, we simplified the template and removed all the C++ code. We want to hear from the community and collect feedback on the new APIs. To fully use React 18 and concurrent APIs, you need to be on React Native 69 and enable the new architecture.
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.
7. Exploring New APIs and Documentation
To stay up to date with the evolving React Native ecosystem and framework, it's crucial to explore the new APIs and documentation. The official documentation includes explanations of the changes, guidelines for creating libraries and apps, migration support, and detailed design docs on the architecture. The new architecture simplifies the setup process for iOS and Android, allowing developers to easily try the new APIs by following specific instructions. Running the app with fabric set to true confirms the usage of the new architecture.
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.
8. Working Group, Samples, and Open Source Tools
We started the new architecture working group, which is a collaboration space for asking questions, sharing libraries, and discussing library migration. We also provide samples for app and library migration, as well as backward compatibility examples. We value feedback and want to hear migration stories to improve the APIs. The old architecture is still experimental, and we encourage people to try it and provide feedback. Our tools are open source, and we are committed to making them valuable for everyone.
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.
9. Switching to New Architecture and Dependencies
When is a good time to switch for existing apps to the new architecture? The timeline for switching to the new architecture and dependencies are crucial considerations. While TurboModules are backward compatible and can be easily enabled, migrating UI libraries can be more challenging. It is recommended to review the list of dependencies and ensure that the majority are migrated. Unmaintained libraries pose a security risk and present an opportunity to evaluate and potentially update or revive them.
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.
10. Migrating Libraries and Backwards Compatibility
Many libraries have migrated to the new architecture, indicating traction from the community. While the new architecture is considered experimental, it is production ready and being iterated upon. Backwards compatibility is available for non-UI components, but compatibility with fabric requires additional considerations. Collaboration with Microsoft on tools like AlignDepth and RnxKit aims to provide information on library compatibility. The RnX kit is gaining strength to support the new architecture.
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.
11. Performance and Migration to New Architecture
For us, the new architecture has been worth it in terms of performance. It allows us to develop features like pre-rendering that were not possible before. However, enabling the new architecture does not guarantee immediate performance gains. It depends on your use case and libraries. Migrating to the new architecture will be necessary to benefit from new libraries and APIs.
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.
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.