Bringing the New React Native Architecture to the OSS Community

Rate this content

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 endeavour, 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.

26 min
21 Oct, 2022


Sign in or register to post your comment.

AI Generated Video Summary

The React Native community has been focusing on the new architecture, which aims to improve performance by rewriting internals using C++. The new architecture brings features like view flattening, CodeGen, and bridgeless mode. It also includes updates to build tools and JavaScript engine, such as Hermes. React Native 0.71 will include TypeScript types bundled in the NPM package, and Kotlin is fully supported on Android. The new architecture offers a transition from the legacy renderer and concurrent features, and there are resources available for migration and community support.

1. Introduction to React Native's New Architecture

Short description:

The hot topic in the React Native Ecosystem is the new architecture. Today, I'll talk about bringing the new architecture to the open source community and the challenges we faced. The new architecture is all about the bridge, aiming to get rid of the bottleneck. We rewrote our internals using C++, allowing us to write features and optimizations once and benefit every platform that uses React Native.

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.

2. React Native's New Architecture

Short description:

View flattening is now available on both Android and iOS thanks to the new architecture written in C++. The CodeGen component eliminates string references and generates code based on your API representation. The new architecture serves as the foundation for future capabilities, including the fabric renderer, turbo modules, and bridgeless mode. The code gen simplifies writing platform-specific code by generating boilerplate. Additionally, there are other considerations, such as build tools, within the new architecture.

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.

3. iOS Build System and Meta Considerations

Short description:

On iOS, we create an Objective-C protocol that understands the types and provides platform-specific types. The new architecture goes beyond core components and includes considerations for build tools. Meta's internal use of Buck led us to extend our build system to accommodate the open-source space.

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.

4. Build Tools and JavaScript Engine Updates

Short description:

On Android, we introduced CMake files for building C++ code and made changes to the Gradle pipeline. We also focused on Cocoapods integration on iOS and improved our JavaScript engine with Hermes. Hermes is recommended for the new architecture and starting from React Native 0.70, it's the default engine. We also have updates on programming languages, including TypeScript on the web.

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.

5. Updates and Future Releases

Short description:

When we released the first version of the new architecture documentation, we received feedback about not wanting to write specs in Flow. To address this, we added support for TypeScript spec files. React Native 0.71 will include TypeScript types bundled in the NPM package. On Android, Kotlin is fully supported, allowing developers to write apps without Java. The website has been rewritten to be bilingual, with examples now available in Java and Kotlin. The situation for Swift on iOS is more complicated due to interoperability with C++. We released React Native 68 with support for the new architecture and received feedback that led to the development of new features, including React 18 support in React Native 69.

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.

6. React 18, Versions 70-72, and Community Feedback

Short description:

I'm going to talk about React 18 and React Native versions in the next slide. 70 was a milestone release for the new architecture, introducing dermis as default and support for auto linking on Android. In version 71, the new app template will be simplified, making the developer experience better. Version 72 will address issues raised by the community and implement changes based on feedback.

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.

7. React 18 and React Native Support

Short description:

If you are on React Native 67 or 68, you are effectively on React 17. To be on React 18, you need to be on 69 or the next feature. The new architecture offers concurrent features and a transition from the legacy renderer. Now is a great time to migrate, as we are focused on the migration story and listening to the community. Check out the official docs on the website, including the new architecture guide and the guide on migrating to the new architecture.

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 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.

8. New Architecture Overview and Migration

Short description:

We have an architecture overview and deep dives on how Fabric and Hermes integration work. To start with the new architecture, just change one line in the pod install on iOS and on Android. Metro will confirm the new architecture is enabled. Join the new architecture working group on GitHub for support and access to samples that demonstrate step-by-step migration of apps, components, and modules.

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 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.

9. Library Migration and Future Discussion

Short description:

The new architecture's success depends on library compatibility. Library maintainers should migrate their components and modules. We want to hear about your migration experiences and any blockers you encounter. Join the discussion room with industry experts to discuss the future of React Native in your 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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
React Finland 2021React Finland 2021
36 min
The Eternal Sunshine of the Zero Build Pipeline
For many years, we have migrated all our devtools to Node.js for the sake of simplicity: a common language (JS/TS), a large ecosystem (NPM), and a powerful engine. In the meantime, we moved a lot of computation tasks to the client-side thanks to PWA and JavaScript Hegemony.
So we made Webapps for years, developing with awesome reactive frameworks and bundling a lot of dependencies. We progressively moved from our simplicity to complex apps toolchains. We've become the new Java-like ecosystem. It sucks.
It's 2021, we've got a lot of new technologies to sustain our Users eXperience. It's time to have a break and rethink our tools rather than going faster and faster in the same direction. It's time to redesign the Developer eXperience. It's time for a bundle-free dev environment. It's time to embrace a new frontend building philosophy, still with our lovely JavaScript.
Introducing Snowpack, Vite, Astro, and other Bare Modules tools concepts!

React Finland 2021React Finland 2021
27 min
Opensource Documentation—Tales from React and React Native
Documentation is often your community's first point of contact with your project and their daily companion at work. So why is documentation the last thing that gets done, and how can we do it better? This talk shares how important documentation is for React and React Native and how you can invest in or contribute to making your favourite project's docs to build a thriving community

React Advanced Conference 2023React Advanced Conference 2023
29 min
Raising the Bar: Our Journey Making React Native a Preferred Choice
At Microsoft, we're committed to providing our teams with the best tools and technologies to build high-quality mobile applications. React Native has long been a preferred choice for its high performance and great user experience, but getting stakeholders on board can be a challenge. In this talk, we will share our journey of making React Native a preferred choice for stakeholders who prioritize ease of integration and developer experience. We'll discuss the specific strategies we used to achieve our goal and the results we achieved.

Workshops on related topic

React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and
used by React Native itself
as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
- iOS/Android: MacOS Catalina or newer
- Android only: Linux
Install before the workshop
React Advanced Conference 2022React Advanced Conference 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.
You will know:
- Quick presentation about what FlashList, why we built, etc.
- Migrating from FlatList to FlashList
- Teaching how to write a performant list
- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)
- Using the Flipper plugins (flame graph, our lists profiler, UI
JS FPS profiler, etc.)
- Optimizing performance of FlashList by using more advanced props like `getType`
- 5-6 sample tasks where we’ll uncover and fix issues together
- Q
A with Shopify team
React Summit Remote Edition 2021React Summit Remote Edition 2021
60 min
How to Build an Interactive “Wheel of Fortune” Animation with React Native
- Intro - Cleo
our mission
- What we want to build, how it fits into our product
purpose, run through designs
- Getting started with environment set up
“hello world”
- Intro to React Native Animation
- Step 1: Spinning the wheel on a button press
- Step 2: Dragging the wheel to give it velocity
- Step 3: Adding friction to the wheel to slow it down
- Step 4 (stretch): Adding haptics for an immersive feel

React Summit 2022React Summit 2022
50 min
High-performance Next.js
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
React Advanced Conference 2023React Advanced Conference 2023
159 min
Effective Detox Testing
So you’ve gotten Detox set up to test your React Native application. Good work! But you aren’t done yet: there are still a lot of questions you need to answer. How many tests do you write? When and where do you run them? How do you ensure there is test data available? What do you do about parts of your app that use mobile APIs that are difficult to automate? You could sink a lot of effort into these things—is the payoff worth it?
In this three-hour workshop we’ll address these questions by discussing how to integrate Detox into your development workflow. You’ll walk away with the skills and information you need to make Detox testing a natural and productive part of day-to-day development.
Table of contents:
- Deciding what to test with Detox vs React Native Testing Library vs manual testing
- Setting up a fake API layer for testing
- Getting Detox running on CI on GitHub Actions for free
- Deciding how much of your app to test with Detox: a sliding scale
- Fitting Detox into you local development workflow
- Familiarity with building applications with React Native
- Basic experience with Detox
- Machine setup: a working React Native CLI development environment including either Xcode or Android Studio