It has never been easier for React developers to build native iOS and Android apps. In this talk, we'll see how quickly you can ship your app with Expo open source tools, Expo Application Services (EAS), and React Native. We'll also discuss some of the recent improvements we've made and what's coming up next.
Building a Mobile App with Expo, EAS, and React Native
AI Generated Video Summary
This talk provides an overview of building React Native apps with Expo and Xcode. It covers Expo managed projects, XO, Turtle, customizing runtime, Expo Development Client, and EAS. The talk also mentions the advantages of Expo Updates, the focus on a customizable runtime, and adding native libraries. Favorite React Native apps and libraries are recommended, and the future goals include enhancing performance and improving the development experience through EAS.
1. Introduction to React Native and Xcode
This talk provides a high-level overview of building React Native apps with Expo and EAS. React Native is a good choice for building Android, iOS, and web apps. Familiarity with native code and tools is necessary, and Xcode can help with that. We'll explore what Xcode can do, its abstractions, and how it solves limitations.
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.
2. Expo Managed Projects and XO
This is an overview of how an Expo managed project works. It involves opening the project on Android or iOS, downloading Xcode, and installing it as a web browser for React Native development. The run time, provided by Expo, includes APIs for notifications and haptics. The run time is similar to the ECMAScript standard library in web browsers and can be extended with native extensions. XO Managed projects allow changing the run time by sending pull requests to the XO repository. Other React Native apps require native modules and recompilation. XO install allows installing libraries without recompiling native code. XO Go and XO publish provide preview and sharing capabilities. Snack is a sandbox environment for editing and running code. XpoBuild Android or iOS packages the app into a standalone binary for submission to a store.
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.
3. Building Standalone Apps with Turtle
Turtle is a tool that helps build standalone apps for Expo. It uploads the app bundle, downloads the necessary files, configures the shell app, and signs the app with your credentials. Once complete, the app can be submitted to the stores. Updates can be made by downloading and swapping in new JavaScript. However, the Expo runtime may not meet all app requirements, leading to feature requests for custom libraries and native code.
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.
4. Customizing Runtime and Expo Development Client
Developers have different preferences when it comes to managing Native projects in React Native apps. Some choose to take control of their Native projects using expoeject, while others prefer Expo to continue managing their projects. To address this, Expo is working on making all tools work in any React Native project and making the Native runtime customizable in managed projects. This involves building new versions of tools like Turtle Build and Expo Go, as well as introducing EAS Build, a service that allows seamless and tailored building of React Native apps. Expo Development Client is being developed as an equivalent to Expo Go.
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.
5. Customizing the Runtime in Managed Expo Projects
The React Native library provides the same experience as Expo Go, but with a custom runtime. Developers can customize runtimes to add or remove libraries. Mistakes with over-the-air updates can be handled with tools provided by EAS Update. The Expo development client allows customization of the runtime in the development environment.
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.
6. Building Managed Apps with Expo and React Native
Run a debug build on EAS build and use internal distribution to share development client builds. Building managed apps with Expo and React Native will be easier in the future. EAS build reduces app size and has a free tier. Expo development client and EAS update are in closed data. React Native can be built with TypeScript using a development client and Expo SDK. These tools enable better workloads and separate runtime and application code.
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.
QnA
Q&A about Expo and React Native
You can follow along on Twitter and our blog for updates. Thank you for listening. Brent asked if you have shipped an app with React Native. Many of you have. Expo has limitations, but they are working on addressing them. Expo Updates is comparable to Code Push, with some differences. Expo Updates is integrated into Expo projects, making it more convenient.
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.
Advantages of Expo Updates with Managed Workflow
Expo Updates with Managed Workflow provides safe over-the-air updates without worrying about native code changes. Publishing a project and making changes is compatible with Expo Updates.
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.
Expo's Focus on Customizable Runtime and EAS
Expo is currently focused on making the runtime customizable and allowing developers to use existing BLE libraries or other third-party libraries. They aim to avoid re-implementing what other libraries have already done well. The future of Expo projects is likely to be with EAS and the development client.
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.
Adding Native Libraries and Favorite Apps
To add a library of native code, you need to eject in React Native. However, it's not the same as ejecting in Create React app. The process generates native projects that you can customize. In the future, you will be able to add libraries and build a new client that includes them. The availability of certain features may vary, with SDK 41 and development client updates expected in the coming months. As for favorite React Native apps, Coinbase and Readwise are highly recommended.
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.
React Native Apps and Libraries
This thing connects to Kindle highlights and other Twitter apps. Third Wave is a great coffee app. The new PlayStation app is also recommended. Favorite libraries include gesture handler, reanimated, and Expo GL. React navigation and safe area context are also highly regarded. React Native lacks the ability to create rich text editors directly in primitives.
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.
Enhancing Performance and Future Goals
Developers are looking forward to the release of fabric to enhance the performance of React Native apps. The long-term goal is to allow the inclusion of any native module and integrate various services seamlessly. Expo aims to improve the mobile and cross-platform development experience through EAS, offering a wide range of services.
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.
Comments