Building a Mobile App with Expo, EAS, and React Native

Hey, everyone. My name is Brent. I'm an Engineering Manager at Expo. This talk is a high-level overview of building React Native apps with Expo and EAS. We're not going to talk about how to handle gestures and animations, navigation, or even talk through a single line of React Native code. There are great resources for these topics that I'll link to at the end. This talk is more about process.

If you want to build an app for Android and iOS and use React on the web, React Native is probably a good choice. A lot of the same knowledge will apply to React Native. The component API is the same, you can keep using your favorite state management library, React dev tools and a bunch of other stuff. Another thing React Native has in common with React DOM is there's a small unopinionated core. A lot of the work that you need to do to build a web app exists outside of React DOM and greater extent with React Native. React Native doesn't aim to provide an abstraction over everything that you need to do to build an app.

What this means is that some familiarity with native code and tools will be needed. You'll have to learn a thing or two about Xcode and Cocoapods and Android Studio and Gradle. You'll need to be able to distinguish between a key store and a distribution certificate. Depending on what you're building, you might even need to get comfortable with writing native code. You can handle this in a few ways. You can grow the native skill set on your team of React developers. You can bring in native experts to manage the native side, and you can use Xcode tools. Xcode picks up where React Native leaves off and helps you stay productive in React. Xcode is a set of open-source projects and hosted services to help you handle the accidental complexity of cross-platform app development.

In the rest of this talk, we'll look at what Xcode can do, how its abstractions work, how these abstractions can sometimes fall short, and what we're doing to solve these limitations. So, I've said that Xcode picks up where React Native leaves off. Let me explain. Xcode makes it possible to write your app in just TypeScript or JavaScript and configure it in JSON. Notice the Android and iOS directories in the terminal on the left. To run this project, we'd open the Android and iOS project directories in Android Studio and Xcode, then compile and run the projects. But we don't have any native projects in the terminal on the right. It looks a lot more like a React DOM project.

This is what an Expo managed project looks like. You open it on Android or iOS, download an app from the App Store called Xcode, and install it. This is like a web browser for developing React native apps. It includes the run time with an extensive set of APIs built by the Expo team to add capabilities like notifications and haptics. And the React Native itself.

Let's think a minute to clarify what I mean by a run time. In a web browser, the run time includes the ECMAScript standard library along with standard web APIs. As a developer running a website, you can't change it without sending a pull request to the browser engine. The run time is controlled by the browser vendors. It includes all of the APIs that you can use from JavaScript. You might recognize these as the functions that stringify to native code in square brackets when you constantly log them. They expose access to the DOM, the network and other things like device location. In Node.js, you have the standard library from Node instead of the web APIs and you can extend the run time by building native extensions in languages like C++ or RAS.

In a web browser, the run time is provided by browser vendors. In XO Managed projects, the run time is provided by XO. You can change it by sending a pull request to the XO repository on GitHub. In other React Native apps, for anything beyond core APIs, you need to create or install native modules written in languages like Swift or Kotlin and recompile the app in order to use them with JavaScript. To install a library to an XO Managed project, run XO install. XO install takes a version of the that matches with the run time version used by the project. We call the run time version the XO SDK version. We can use the library from JavaScript without recompiling any native code. All of these can preview your work in progress in XO Go. To do this, add your colleague to your team on the XO website and publish your app with XO publish. Next, share the URL. You can set this up to run automatically on pull requests to get a preview workflow similar to what you can do on the web with services like Netlify and Vercel. You can also share code on Snack. It's a sandbox type of environment that lets you edit and run code directly in a web browser. When you're ready to ship your app, run XpoBuild Android or iOS. We call this build tool Turtle because it takes your app and packages it into a prebuilt shell app. The result is a standalone app, a binary that you can submit to a store.

It's called a standalone app because it stands on its own. It's no longer dependent on Xpogo to run. Here's how Turtle works. Build command uploads your app JavaScript bundle, manifest and assets, like images and fonts. Then Turtle spins up a new worker and downloads the files that you just uploaded. It also downloads our prebuilt shell app. It then configures the shell app based off of properties in the manifest like the name and icon. It copies the downloaded JavaScript and assets into the shell app resources. And lastly, it signs the app with your app signing credentials.

When this whole process is complete, we can go ahead and upload this standalone app to the stores. To submit your app, run EAS submit PHP, Android, or iOS. Well, sort of. You'll actually have to submit your app through the Google Play console the first time you do it on Android because it's not yet possible through any public APIs. If you accidentally release your app with a bug, you can fix it locally and then run Expo publish to update JavaScript over the air. You can safely update managed apps over the air because the code that you own is just JavaScript. So it's similar to updating a website. To update the app, we just download the new JavaScript and swap it in for the JavaScript bundle that's currently used in the shell. We usually do this when the app is restarted, but you can configure it differently if you want to.

At a high level, that's how we ship a managed app with Expo and React Native today. Each week there are millions of people using apps built by tens of thousands of developers this way. Thousands of apps are built with Turtle for deployment to app stores each day. Now that we've seen the golden path, we can take a look at where these abstractions start to fall short. We get a lot of feature requests from developers building Expo managed apps, but we can distil most of them down to one of three things. First, I want to use a library that is not built into the Expo SDK. For example, React Native web RPC. Second, I want to remove libraries that I'm not using. For example, to reduce the app size. And third, I want to include Native code that I'm going to write myself and that isn't in any existing library. These three requests all point to one problem. A one-size-fits-all Expo runtime doesn't actually fit all apps.

People need to be able to customize the runtime in the React Native Android and iOS apps. Currently, if you get to the point where you need to modify the runtime, even if just to remove some code or add a single Native module, you need to take control of your Native projects. You can do this with expoeject.

Expoeject is a command that instantiates and configures the iOS and Android Native projects on your machine. You now have a standard Native project, and not just the JavaScript files. So the name sounds very similar, but it's a bit different from createReactAppsEject because after running it, you're still using most expo tools. That said, not everything is supported yet.

Taking control of your Native projects is a very reasonable solution for many developers, and something that every expo tool should support. Other developers prefer to have Expo continue to manage their Native projects. They want to add and remove Native libraries, and let Expo take care of how that actually works. So, there are two parts to our solution to this problem. But you'll see soon that the first part is actually a prerequisite for the second. First, we need to make all Expo tools work in any React Native project, and then we can make the Native runtime customizable in managed projects.

If we can make the runtime customizable, then developers can add or remove any Native module in their managed projects. Most Expo tools already work outside of managed projects, for example, the Expo SDK packages like Notifications and Haptics. What we're missing is the Turtle Build service and Expo Go. These tools were built specifically around a fixed runtime, so we'll need to build new versions of these tools from scratch that can provide an equivalent experience.

Turtle can't support any arbitrary React Native app because it's purpose built to assemble shell apps. This is very different from compiling an app, so we built a new service from scratch called EAS Build. EAS stands for Expo Application Services. Running an Android or iOS build on some cloud server isn't exactly a novel idea, but we need to build it in order to provide a seamless and tailored experience, one that's deeply integrated with Expo services and React Native.

Here's how EAS Build works. You run EAS Build-P android or iOS, you create a shallow clone of your project's Git repo, compress it, and upload it. EAS Build configures a new VM, then it downloads your project archive. It installs JavaScript dependencies and native dependencies, then kicks off a native build. When the build completes, it signs the resulting binary with your app's own credentials. Like most things in this talk, there's a bit more to it than that, but those are the high-level steps. Using EAS Build we can now build and sign any React Native project.

The other missing piece is an equivalent to Expo Go. So we've been building something we call Expo Development Client.

It's the React Native library that gives you the same experience as Expo Go, but with your own custom runtime. It's minimally opinionated to support the broadest set of use cases. When you create a debug build of your app, you get the Development Client experience. When you create a release build, all of the Development Client code is stripped out. You can build the Development Client once and focus on the JavaScript side of your app, and then return to the Development Client when you want to write or install some new native code.

So, with solutions for Turtle and Expo Go, we can move on to Part Two, customizing the runtime in Managed Expo Projects. In Managed Expo Projects, there are two places where we need to be able to modify the runtime. In our local development environment, and in our standalone apps. Let's start with standalone apps. We need a cloud build service capable of building projects with arbitrary native code. This sounds like a job for EAS build. We can repurpose the eject command to generate and configure the native iOS and Android projects based on the JavaScript app. We'll call this new command prebuild. On EAS build, we just need to then run prebuild, and then build the resulting project like we would for any React Native app. There are no shell apps here. With this in place, developers can remove libraries that they're not using, because the prebuild command only links and configures libraries that are installed in the project. In simple cases, adding libraries will work fine too, because React Native automatically links them through Gradle and Cocoapods. But installing native module libraries often involves some additional configuration of data projects, prebuild only knows how to do this for XOSDK packages. We can solve this by giving developers hooks into the prebuild process, and publicly documenting the tools we use to configure XOSDK packages. We call these tools config plugins. Config plugins are functions that are executed during the prebuild process. They have access to utilities that make it easy to do the most common configuration tasks. And if those don't handle your use case, then you can directly access the project on the file system as an escape hatch. Developers can pass in options to config plugins like API keys and permission messages.

Now that developers can customize their runtimes to add and remove libraries, if you see them accidentally make some mistakes with over-the-air updates, you can end up in a situation where the JavaScript code for an update is incompatible with the runtime in the binary. We need to provide tools that make it easy to do the right thing in these scenarios. We won't go into that here but it's worth noting that this is a new problem that arises with custom runtimes, and we're working on solutions in a new service called EAS Update. To customize the runtime in our development environment we can use the Expo development client. Theoretically and this isn't actually implemented yet at the time that I'm saying this, there are two steps to create a custom development client build for a managed project. First, install the development client packages in our managed project.

Second, run a debug build of our project on EAS build. We can depend on the config plugins included in the development client packages to configure the client automatically during the pre-build phase.

So that's it. Now, it needs to be super easy to share your expo development client builds, so we built something we call internal distribution into EAS build. You can use it to share development client builds with your friends and colleagues. To do this, first, if you're distributing to iOS, add the device to an allow list, so it'll be included in the provisioning profile. This isn't needed for Android. Now, you can create a build. When the build completes, send the build URL to your colleague. They can install directly from that page.

In the future, once all this is ready, building managed apps with expo and react-native will look a lot more like this. You'll be able to install a native module library, then run a new development client build locally or on EAS build to add it to your development client runtime. Then you can just continue on building your app in TypeScript or JavaScript.

EAS build and config plugins are available now. If expo-sdk41 has been released by the time this talk airs, you can try EAS build with your SDK41 project and it should reduce your app size significantly by only including the native libraries that you're using. If you do, be careful when you're doing over-the-air updates.

It's worth noting that EAS build is a paid service and we plan to have a generous free tier, enough to support hobby developers, students, and small organizations that are just getting started. For now, EAS build is still in preview and it's gated behind a paid plan. We'll be rolling out general availability in the summer. Expo development client and EAS update are both in closed data. If you're interested in trying them out, then follow the link on the screen to fill out a survey. If you're watching this a while after the recorded date, we'll keep those pages up-to-date so you can find relevant information there too.

So why are we doing this? Well, Read Expo believes that a significant percentage of Android and iOS apps can be built with just TypeScript by using a development client with a custom runtime and leaning on the Expo SDK and React Native open source ecosystem. There are a lot of great libraries out there, and service providers are increasingly supporting React Native wrappers for their native packages. As React Native continues to mature, this will only get better and better. Even if you prefer to manage your native projects, these tools can enable better workloads for your team. They can help you to structure your process so that work on the runtime and application code are separate, similar to how building components with Storybook lets you split up your component system development from building features with those components. With that, you can get all the benefits that come along with having a stable runtime and a mechanism for loading apps into that runtime, like easy previews of pull requests on GitHub. We love the web, and we want React Native to be more like it, while still retaining what makes React Native great. And we think that the work that we've been doing is a big step in that direction.

You can follow along on Twitter, at expo and not brent, and we frequently post longer-form updates to our blog. Learn how to get started in actually writing some code in React Native, check out the Learn links on the right-hand side.

Thanks a lot for listening. Bye.

Thank you so much for that wonderful talk. I hope you enjoyed it as much as I did. Brent is amazing.

Now, before we go on, let's answer the question that Brent asked all of you. I hope you answered it in the Slido. So, Brent asked, what if you have ever shipped an app with React Native? And we can see that a good 30% of you, folks, have shipped an app with React Native. That's pretty impressive. And hopefully with some of the things that Brent talked about, you can even ship better apps with React Native coming up soon.

I am going to invite Brent to join us on the stage. Brent, how are you doing? I'm good. How are you? I'm good. Thank you. So, we've got quite a few questions coming in. Those of you, maybe if you still got a question, make sure you drop it in the Discord chat.

So, the first question, I'm just gonna jump straight into it. From BKG, are there any downsides to using Expo, things it can't handle that you would need, that would make you need to eject from? Yeah, I think I tried to cover that a little bit in the talk in terms of, you know, mentioning the tradeoffs that come with having a fixed runtime. And so, there's only so many things that we can really include inside of the the preset, so fixed SDK runtime. And you can have a look at the feature requests page that Expo has to see like some of the things that people run into. And, you know, there's some libraries in the React Native community that we don't include that a lot of people frequently would like to use, and so a big part of what we're working on is addressing those limitations so that you can modify the runtime and you don't have to face those sort of trade-offs in terms of like using the thing that you want to use while also getting the experience of having a lot of the complexity of managing your app kind of handled for you.

Cool. Someone's asking a comparison question, so they're asking how does Expo compare to App Center Code Push? Does anyone have any experience? Is there any differences? Anything similar? Yeah, so I think the closest comparable there is Expo Updates, which is the over-the-air update service that I think is comparable to Code Push. They're pretty similar. I think Code Push has some interesting features that Expo doesn't have yet, and the same sort of thing goes the other way. I think there are a couple things that arise just out of the fact that Expo Updates is integrated into Expo projects that make it maybe a little bit more convenient in some circumstances, but then in other circumstances, if you need to set them up from scratch, I think it's kind of a wash. But when you create a project with Expo CLI, you will get Expo Updates configured automatically for you, so you don't have to do anything at all. You just have to create an account with Expo and you'll be able to publish updates to your app with Expo Publish, and so it's all kind of set up.

So that's a really nice advantage that you get out of the box. And then there's another aspect of it where if you're using Expo Updates with this Managed Workflow that I mentioned a bit in the talk, where it's like we kind of manage the runtime for you, then you get really safe over-the-air updates because you don't have to be worried about the native code changing out under your feet in different circumstances and so like if you publish a project for SDK 40 and then you go and make some changes to it and you publish again, that will work. Whereas you have to be a little bit more concerned when the runtime can change and like have to be careful to ensure that the JavaScript that you're publishing is compatible.

Thank you. Hopefully that answers your question, Sarush, huh? We have another question and now I don't know, I will admit that I don't know what these acronyms mean, so if you do know what these acronyms mean can you tell us? Will Expo ever support BLE directly or should we only rely on EAS? It's hard to say, we're not really focused on like, I mean this question is specifically about BLE, like so that's Bluetooth low energy, but there are a lot of other potential APIs that people would say, oh well, like were you ever going to support this or this or this? And we could, like we kind of had a choice like, okay are we going to go off and and build all of these different API wrappers and support all of these and definitely in the future and stick to this concept of like a managed runtime that just then grows and grows and grows. And so that was one possible route we could have taken and the other one was allow people to customize the runtime. So we've opted so far for like in the past year, like let's focus on making the runtime customizable. And I think once we get that into a really good spot where people can use existing BLE libraries or or whatever else they want to use in that purchase libraries, maps libraries, etc. That like aren't included, then once that's sort of good, we can maybe circle back and be like, OK, well, which of these areas do you think we can actually have like a positive impact on? There's no need to re-implement something that another library has already done an excellent job of. And so if there's really great BLE library out there and it makes sense for us to contribute to that, then we would do that. If it's something where we think, OK, well, maybe we need to rewrite this to make it like what we think it should be, then then we do that. And so it's kind of on the table in terms of whether we integrate that or not. But most likely, I mean, the future of where development is going with expo projects is definitely with with EAS and things like the development client.

Yeah, well, then we've got another question just in from Rado. In order to add a library, I think it's a clarification question. In order to add a library of native code, you need to eject. Right. Yeah, so at the moment, that's the case. And so that was kind of what I discussed in the first half of the talk was like, this is the fixed runtime. And then if you want to change that way that you do that now, as you would eject and that would generate these native projects. And it's not quite the same as ejecting in Create React app where like you eject and now it doesn't do anything for you anymore and you take on everything. It's kind of like halfway in between that and like not ejecting. And so basically, it generates the native projects that like you would otherwise have managed for you. And you can then add what you want to that. And that's kind of where it is now. And so sort of where we're going is the second half of the talk was what you would be able to do is add the library, and then you'd be able to get, it's built to do a new build of the client for you that includes that library. And then you could continue on with development as you were doing before. And so that would allow you to kind of have that same managed workflow experience, but still customize the runtime and remove libraries.

So another thing is right towards the end of the talk, he said that there were some things which weren't, that may not have been available yet that might be available now, just out of curiosity, are they available now? So we did not release SDK 41 yet, but I will be doing that shortly after this. The stuff around like development client and so on, no, that's, that's more of like a June, July sort of timeline for that. And yeah, so that's a little bit further out. Last week to this week, it's going to, not much is going to change there. No worries. Maybe when someone's watching the recording, it would have been released by them.

So kind of question, you've been in the React Native space for a while. Just out of curiosity, what are your favorite React Native apps? Or maybe one that you've seen that you really liked? Um, well, I have to give a shout out to Coinbase because they're doing their IPO today. Uh, Coinbase Pro and, um, and some other stuff as well in React Native. And I think they did a good job with that. Um, I really liked this app called Readwise. You can go to readwise.io. Um, it's a great tool for, um, taking all of your sort of highlights from a bunch of different locations and, uh, actually reviewing them, not just like putting them into this file of like things that you're like, Hey, that's great. I want to remember this. So I'm just going to highlight it and then never think of it again.

This thing will connect to Kindle highlights and all your other Twitter, whatever, and, and kind of use some space repetition and reviewing. Um, I also like the app called Third Wave. Uh, it's only usable in Canada right now, but it's a really good coffee app. Uh, and just like some other big ones like the PlayStation app, the new PlayStation app is really great. Um, and, uh, I just downloaded that. I didn't react to native to the other end. And, and, and of, of those are some of your react native favorite apps, what about some of your favorite libraries?

Um, you don't have to definitely go with gesture handler and reanimated as two of my favorites. Um, Expo GL is another really great one. Um, it lets you use WebGL essentially, or something close to that inside of, um, react native apps. And so you can use three J S and things like that with it. And so, uh, oh, actually I forgot to mention another app I really like is shop from Shopify and they use expo GL, um, in, in their app, uh, and, uh, similar. Yeah. Really cool uses of it. Um, and of course, react navigation library that I'm very much involved in, uh, in that expo, uh, is, uh, I guess the, the kind of, uh, on the project for, for, for a number of years, along with people like Satya, uh, who's really been, uh, putting all the work into that recently and making a great project with a P five and P six, um, safe area. Context, um, is another really great one from the guy that made third wave a Janik. Uh, I'm not even going to try saying his, his French last name. Sorry, Janik, if you're watching this, uh, and that is really fantastic way. Like I think if you're just joining react native ecosystem now, um, it's easy to take for granted how easy it is to deal with safe areas on devices. Whether that's like the status bar or home indicator or not. Sure. Things like that. Like you just install a reactive safe area context and you have really nice, uh, like, um, idiomatic react API's for dealing with, with these things and it's fantastic. So, um, yeah, I'd say those are, those are my favorites.

Nice. We've got another question coming in from Ret Rado. It's another general question. Where is react native still lacking compared to native Android and iOS apps? Yeah. Um, that's a good question. I think there are a few areas that kind of stand out. Um, one that I really like to see is the ability to create like rich text editors directly in react native primitives.

Um, you kind of, I think people tend to bridge a rich text editor, um, or use a web view. Um, I think it'd be really cool if we had, we had just like more rich primitives for, um, for doing this kind of thing. We're able to build that and maybe, maybe with some of the improvements coming with fabric, that that could be possible. Um, I think lists are another one. Um, so, uh, you know, things like flatless and section lists, I think do a pretty good job, but, uh, it doesn't quite have the same, um, performance characteristics as, uh, as he built in let's use. And so on, on either platform. And so it would be, uh, really neat to when fabric again, is released to maybe see if like that will unblock, um, allowing us to use these same sort of view, recycling APIs, um, and get the same sort of performance characteristics.

Awesome. And the last question, and I know this question, actually, this question could be a whole nother talk. So I'm just going to ask you to kind of squeeze it into like the same minutes in this 30 seconds in this last question. Uh, what direction do you see Expo going in the next few years? What new features are in the long-term wish list for your beyond EAS? Well, yes, it's potentially a very huge, uh, thing. It could encompass a broad set of services and, um, ultimately like giving people this ability to include any native module that they want is something that in the short and medium term, like getting that down in a way that just works like amazingly for everybody is going to be something that is going to be a challenge and, uh, we're really looking forward to solving for people and think we'll have a great impact. Uh, but once we get that in place, um, there's a lot of integrations we can do with libraries and the ecosystem and different services, uh, to ensure that you can just kind of plug them in and they just work out of the box and whether that's, uh, tools like log rocket or, or, you know, whatever kind of payments tool you're using or, uh, Maps tool, those sorts of things, like it should be possible to just like plug those into your app and, uh, and, and get running. And so that's, that's kind of, uh, uh, where we're going there and really the scope for the services we can offer through EAS are, are potentially, um, like pretty unbounded in terms of, um, the, the, uh, areas of opportunity to improve the mobile development experience, um, and cross-platform development experience.

That's awesome. Thank you so much for hanging out with us, Sbrenn. I really, really appreciate it. And where can people find you if they want to chat to you later? Uh, Twitter is probably a good spot, uh, so not Brent on Twitter. And, uh, I guess GitHub, if you want to follow the activity on GitHub, Brent Batney on GitHub. Awesome. I love the username at not Brent. Thanks so much for hanging out with us. Bye. Thanks, bye. So, those of you who are still sticking around, make sure you go over to the slider and give Brent's talk a big five star out of five. You can also join Brent in his speaker room on this Spatial chat. The link to join is on the timeline. So, definitely check that out if you have more questions for him. I just want to remind people because I love prizes. I hope you love prizes. We have a raffle on Twitter. And the way you enter this raffle is by taking a picture of your setup and tweeting it using the hashtag React Summit. Hopefully I win. Maybe I should get something free as an emcee. But hopefully I win as well. I will see you right after a short break. And we've got some more amazing talks lined up.