What Happens When You Build Your App

Hi everyone, I'm super excited to be talking to you at React Advanced London. I'm Charlotte, I'm a React Native Tech Lead at BAM, and today we'll dive deep inside your application. We will study the inside of your app and what happens when you build it. And then we will see how we can use this information to be more efficient on a daily basis. But let me tell you a short story before.

One day I was working at my desk and one big red error appeared on my screen. The kind of error that I didn't understand and I didn't know how to solve. This day I did what I used to do every time back then to fix it. I killed everything. My app, my simulator, maybe even my metro server. And after that second step, I relaunched everything from scratch, brand new. I ran Yang install, Pod install. I rebuilt my whole app. I didn't understand what was happening inside my simulator. So I wasn't able to identify what piece of the puzzle was failing. So I started everything again. And it worked. But it was wasting a lot of time. And this day, one of my colleagues passed by and saw me killing everything without any pity. And she advised me to try to understand what was happening inside this black box. So that's what I did. And that's what we are going to do today.

One quick reminder before we start. For the ones of you who are working on the web, what you need to know about React Native is that instead of using HTML elements like divs and spans, we are going to use React Native core components, like buttons and text. And from those components, React Native is going to ask the native to create the associated Android and iOS native components. Okay. Let's start. This is a view of a React Native application in our development environment. There are two parts in this schema, a JavaScript part and a native part. On the JavaScript side, we have some code.

We have JS, JSX, but also TypeScript code. This code will be transferred into JavaScript by Babel. The JSX will be transferred into JS and the JS will be transferred into an older JS without any of the new features old machines can't understand. Then we have Mitro. Mitro is a JavaScript bundler, the mobile equivalent of Webpack. It will bundle the JavaScript into a single file that's called the bundle. And React Native will only deal with this single file. If you make some changes in your JavaScript code, Mitro will aggregate those changes to the bundle and refresh your application on the fly. That's about it for the JS.

Now, let's take a look at the Native part. On the Native side, we have some Native code, either Swift and Objective-C on iOS, and Java and Kotlin on Android. If you open your app in your IDE, you will see an Android and an iOS folder. And in this iOS directory, you've got everything you need to create an iOS application. If you are building one in Swift, you would, in fact, be working within this directory.

Now, this Native code needs to be compiled, and this compilation process is going to produce an executable, an application, IPA on iOS, APK on Android. These are native applications that we will be able to install on our phone. Those two applications, the bundle and the IPA, will allow us to build our React Native application. Let's take a closer look at them. This is the inside of a React Native application. It's actually built from the IPA that was executed. A React Native application, it's really just a native application that will instantiate a JavaScript engine which will compile and execute the JavaScript bundle. The JavaScript world will be able to communicate with the native world. This goes a little bit like this. Imagine that we have this simple component rendering a button with a special title. First, the JavaScript will render his button on the screen. To do this, he will be giving instructions to the native to render the equivalent native component. So he goes, please native, could you render this button for me? And the native goes, of course. Oh, here you go. The user just pressed it. Maybe you should trigger this on press callback of yours.

And the JavaScript does it. In our case, it changes the button title. So the JavaScript goes, hey, native, could you change this button title for me? And the native does it. And this is how, as a user, I can now see my new button title on the screen.

Now, the communication between the JavaScript and the native is currently being handled through a bridge. The bridge is a queue where the JavaScript and the native exchange JSON messages, like please change this button title. But this will change with the new architecture that you may have heard about. We won't dive into this subject, but the main ideas of this talk will still stand within your architecture. And if you want to know more about what will change, there will be several talks about this subject at React Advanced.

So I'd advise you to listen to one of Nicola Corti's or Gunther Bord's talks. Let's get back to our React Native application. We've got our app. But maybe, one day or another, we'd like to have some users and to send it over to some stores. We said earlier that our JavaScript development environment produced the JavaScript bundle. But once we deploy to the stores, we don't have our development environment anymore. We don't need Metro to aggregate any JavaScript change with writes. In release mode, the JavaScript bundle is produced once and for all at build time. And so is the native application. We deployed that to the stores. So great. We've got our React Native application.

Before we continue, I had one quick question for you. How do you start your app in the morning? Do you by any chance happen to always run React Native Runner OS? I hope not. No, wait. Actually, I do. Otherwise, I'd have nothing to teach you. Anyway, that's what I used to do. But it wasn't the most efficient way to start my day. For the ones of you who are working on the web, React Native Runner OS is the command we use to create and run our app. It's a very practical command.

It launches a simulator. It builds and installs our app, and we're ready to go. The problem is that this command takes quite some time, about five minutes each time. But what's taking so long? Let's take a look at what happens when we build our app, shall we? We'll be finding here the same elements as in the first schemas, but in a more chronological view. Also, I'm talking a lot about iOS right now. But Android's pretty much the same. And for this part, keep in mind that I'm talking about the legacy architecture, not the new one, but the conclusions will remain the same. Let's get started.

This is a view of our React Native Run iOS command. When we run React Native Run iOS, two things are happening in parallel. On the one hand, we are going to run a metro server. This metro server is going to aggregate all of the JavaScript code into the bundle, transpile it with Babel, and deliver this bundle. But for now, it's a server. It's branched to a port and it's waiting for instructions to come over.

On another hand, we are going to open our simulators and launch it. And we are going to take care of our native code. As we said earlier, the native code has to be compiled. And this compilation process is going to produce an application, an executable, an IPA that we are going to install on our simulator. Once it is installed, we are going to launch it.

And now two more things are happening in parallel. On the one hand, we are going to load the native modules. The native modules expose native classes to the JavaScript. Those are classes. They need to be instantiated at some point. On another hand, we are going to start the JavaScript engine which is going to make a request to Mitra to get the bundle. And at this point, if you look in your network inspector, you are going to see this request made to your own local host. You will also see on the Mitra server this progress bar. Once the JavaScript engine gets the bundle, it is going to execute it. We will traverse the JavaScript component tree giving orders to the native to create the native views every time a UI component is encountered. And that's it. Your application is live. Congratulations.

Now that we've got this, let's take a look at a few development gestures from the daily live and see how we can execute them efficiently in our mobile world. The first thing you do when you develop is well, you develop. So you make a change, a JavaScript change. This different recipe in here is the one of Mitra. Mitra has a listener system that's called Watchman that will listen to the changes you make inside the code. And when you add some JavaScript, it will aggregate it to the bundle and trigger reloads. So to see our changing our app, thanks to the hot reload, we really just need to save our code.

Now another kind of change, a trickier one that you may do in the code is a native change. This new native code you added has to be compiled and included in our app. It corresponds to this step in our tree. What we need to realize here is that this compilation process will produce a whole new app and install it on our phone. It will completely override the previous application we had installed. So to see our new native change, we have to rebuild our app, either by running React Native run iOS or by building it with Xcode.

Okay, what else do we do frequently? Oh, libraries! Say that your app is running, you are happily coding and you need to install a new JavaScript dependency. What you need to do here is just run YARN install. You see, Mitro watches our source code but it also watches our node modules. So you run YARN install and Mitro will aggregate this change to the bundle. But we don't only depend on JavaScript dependencies. We rely on some native dependencies as well. So if you added a new native dependency by running prod install, which is the command we use to add some native iOS dependency, the iOS equivalent of YARN install. If you added this new library, this new native library, this is some new native code that has to be compiled as well. So it corresponds to this step in R3. So you have to run react native run iOS to build your app again.

Now the main gesture that I wanted to check with you today is this one, how you start your app on a daily basis. Because like I said, I used to run React native run iOS every day to launch my app, but it really wasn't necessary. You see, when you run this command, you go through all of those steps, including the native code compilation, which really takes the biggest amount of time here. But unless you added a new native library during the night, you don't need to do this. Your app is already installed somewhere on a simulator in your computer. What you need to start your app is really three things. A Mitra server, the device you used the day before, and the application installed on that device.

So the process I would recommend to start your app is this one. First, you run, you start a Mitra server by running react native start. Then you launch your simulator. You can do it in command line or using spotlight by selecting your simulator application. And then you have to click on your app on your simulator to launch it. And that's it. It saves so much time already.

One small disclaimer, though. Even though I strongly advise you not to run React Native on iOS every day to launch your app, I still advise you to run it from time to time. You see, if you're working on a project where you don't hide libraries every so often anymore, the risk is that the one day you need to build your app, it doesn't work anymore. And you don't want to spend three hours debugging this process when you have a new version to deliver to the stores.

Let's move on to the last gesture, testing your app on a different simulator. That's something that I have to do every day. I usually work on a specific simulator, but I have to test my code in different situations, with a smaller screen or without a notch, for example. Until I learned about all of this, I used to run React Native Run iOS every day to do it. But it isn't necessary. You may start to see why now. You don't need to compile your native code again. Your native code is not specific to a particular iPhone. All you need to do is to take the executable you already built and install it on another simulator. On Android, you can do this by running ADP install. On iOS, you can do this in Xcode by selecting Run Without Building.

You may have noticed that none of those steps include killing me through your simulator. That's something that I used to do every time I encountered one of those big red errors that I didn't know how to get rid of. But now that we know what's inside this black box, maybe we can try together to understand those errors and see how we can fixed them without killing anything. We basically encounter two main errors related to the Balances problem. The first one happens in the Javascript, while the other one happens in the native world. Let's take a look at the first one. It tells us that our library could not be found within the project. So, it means that we are using a library that we haven't installed.

So, we just need to install it by running yarm install and here we go again. This error can also happen in another situation. Imagine that while your app is running, you pull your main branch and someone else added a library. Before you get the chance to run yarm install, you're using a library that you haven't installed yet. So, JavaScript's saying I don't know this thing you're trying to use. So, you just run yarm install.

But what's instant? Think about this. This library may also have a native part. In this case, you have to install it as well by running part install and to compile it. So, you have to rebuild your app by running reg native run iOS.

Let's move on to the second error. It tells us that it can't find our library element in the UI manager. The UI manager handles UI operations, like creating native views. When the JavaScript asks for a native element to be created, the UI manager handles that request and transfers it to the native part. And in this error, the UI manager is saying that it doesn't know the native element. So it means our library has not been installed properly. And it's specifically the native part that's missing. We're sure that the JavaScript part was installed. Otherwise, we would have had an error sooner in the JavaScript side. The error we looked at just before actually. In our case, this error happens afterwards when the JavaScript asks the native to render the components. To fix this, we just need to install the native part by running part install and then React Native run IOS.

So I hope that the next time you encounter the red screen of death, you'll understand what's going on behind the hood. And you'll know how to handle it. That's it for me. Thank you so much for listening. It was my first talk and I was really glad to give it. Also, please don't kill your simulator.