Ben: Hello, and welcome to PodRocket. Today, I'm here with Brent Vatne from Expo. How are you doing Brent? Brent Vatne: I'm doing pretty well. How are you? Ben: Doing pretty well. We have our first sunny day in a long time in Boston. It's been super rainy for July. So finally, happy to be able to go outside and enjoy the weather. Brent Vatne: Nice. Ben: Where are you? Brent Vatne: We've had a bit of the opposite problem here in Vancouver. While answering your question. Ben: I was going to ask. Yeah. Brent Vatne: I just thought you were about to ask. Yeah, in Vancouver, Canada, on the West Coast. We had a heatwave a couple of weeks ago got up to about 42 degrees Celsius around here, which I don't know what that is in Fahrenheit, but it's a big number. Ben: Hot. Brent Vatne: Very uncomfortable. Yeah. But it's nice here now. So yeah. Ben: So as I'm sure you know, I've had Charlie Cheever on PodRocket before. He was one of our early guests, maybe, I don't know, some number of months ago. And before we dive in to talking more about Expo, curious to learn a bit about your background and how did you end up working on Expo? Brent Vatne: So at the time when Expo came about, so this is about six years ago, six and a half years ago, it roughly coincides with the release of React Native, the first public official release of it. At the time I was working at an agency, and we were doing a lot of full stack stuff and just exploring the mobile space at the time as well. And we were using React a lot on the web. We were really big fans of it, and really wanted something that was just a nice way for us to use React or the same paradigm to build mobile apps as well. And it just so happened that while we were doing a lot of investigation into this React Native released. Brent Vatne: So I just dove right in and started prototyping an app for a client using React Native. And naturally I think you were around similar at the beginning of React Native history. And there were a lot of empty spaces to fill. So I started getting involved in writing a bunch of community libraries and helping out with React Native itself, helping out with the release process and sending pull requests and so on. So through that I met James Ide, who's one of the founders. He was also very involved in React Native upstream work and started contracting with them and eventually joined the company. Ben: And what in particular excites you about Expo? Brent Vatne: I think something really exciting about Expo is we're focused on the end to end experience of building cross-platform apps. So we're not just saying, "Here's the framework for plugging it into your app" Then say, "Now you can go ahead and share some fraction of the code between platforms." We're trying to take that from actually initializing your app to you use the CLI in development to app sign in and credentials, getting all of that set up, and enabling things like push notifications all with one coherent set of APIs and tools that allow you to take something, and ship it and iterate on it quickly, using just this one tool chain. So bringing all that together is something, I think other tools aren't necessarily doing in the same way. It's more focused on a specific part of this. And we're more about trying to vertically integrate a lot of these things. Ben: And I remember when I spoke to Charlie there, I asked him a question, in 2021, is React Native and Expo the right choice if you're starting a new mobile app, for basically any mobile app or are there still cases where you believe like it does make sense to use native iOS and native Android, separate apps? And how should developers think about making the choice on a greenfield project? Brent Vatne: Yeah, it's a really good question. Greenfield projects are definitely a worthy distinction here. I think that if you're talking about taking an existing app that you're building, and adding more features and developers to it, I think that's a little bit less unclear what should be done in that case. But I would say in the context of a greenfield app, React Native has really come a very long way. And unless your organization is already heavily staffed with native engineers, you probably have some people working on a website somewhere, maybe using React already or a similar tool. Brent Vatne: It's, I think a very easy choice for a lot of organizations to say, "Let's just, for this initial prototype at least, get our React engineers to figure out how to translate their skills to React Native and start building this first iteration of the app." And definitely for smaller organizations, that's a factor as well. You don't necessarily always have the ability to say, "We want to build an app. So let's hire an iOS engineer, an Android engineer, or multiple of each and get this spun up." So yeah, I would say it's a pretty good choice in most cases these days. You might not use it for things like games, of course. You'd probably use something like Unity instead. Ben: So to jump into the weeds a bit, curious to hear about what's new in Expo since I talked to Charlie, I think Expo SDK 42 was the most... recently came out. So maybe we could go through some of the new and exciting features. Brent Vatne: Sure. So Expo SDK 42. And just for people who are listening who maybe aren't familiar SDK releases with Expo happen every three. So we have four each year and it's just our way of packaging up a set of changes that we work on over that time period, and releasing it in one coherent set of libraries that all work together at that point in time. A snapshot of a development at that point in the process. So usually that's tied to a specific version of React Native as well and a number of other things. So this SDK release, we had some pretty interesting features. There's been people requesting first party integration with Stripe for a while. So Stripe being, obviously a very popular way to handle payments these days. We worked a bit with the Stripe team on that and have really good integration now with this latest release. So that's pretty exciting for a lot of developers. Ben: What does first party Stripe support mean? How is that different than just using a Stripe JavaScript client? Brent Vatne: Right. So Stripe has actually built a React Native specific library for interacting with the native capabilities of Stripe. So this gives you some UI elements that are shipped by Stripe themselves. And I think everyone is familiar with the quality of UIs that Stripe is capable of producing. And just dealing with things like credit card input fields, you don't want to be writing that on your own necessarily. So stuff like that is pretty nice to have. Yeah. So I think that's an important thing there. So the first party support here means we have worked with them along with this library specifically built for React Native and said, "Okay, how do we make this work inside of the context of Expo? How do we make everything have a really nice story for integrating here." Since there are some slight differences, depending on how you're building your app with Expo or without Expo in a React Native environment. Ben: Yeah. I guess it begs an interesting question to dig into, what are the... Since Stripe had already built a React Native integration, do other integrations for React Native work out of the box with Expo, or what are the cases when you would need to adapt to the integration to function well within the Expo environment? Brent Vatne: Yeah. That's a great question. So that also ties back into some of the stuff that we've released with SDK 42. SDK 42 and 41 were the first releases where we supported a new build system called EAS Build. So previously we used another build system that was a lot less flexible. So basically what we did was we would produce some pre-built app that included all of the libraries in the Expo SDK and say, "Okay, we're going to run a build for this now against your JavaScript app." So we take this pre-built app, we take your JavaScript, your assets and some configuration, and we just mash those all together. So it wasn't actually doing a build of your app, including any custom native code that you might be including. So it was just this preset SDK idea. And you can think of that more like shipping an electron app, maybe without using any additional native APIs, or shipping even an app in a web browser. You get what you get in a web browser. Brent Vatne: There are now maybe some exceptions around what you can do in terms of native extensions with web assembly and stuff. Generally, the access that you have to system capabilities is limited by what's made available through a web browser. And similarly in the Expo environment, traditionally, there has been a limitation around what is made available through the Expo SDK in terms of native device capabilities. So accessing the camera, and notifications and so on were also handled through some built-in set of libraries. So what has changed recently is that this new build system supports installing any React Native library in your Expo app. So that's part of why the timing for this with Stripe worked out how it did, was essentially what needs to be done to make that work in this context, is you have this React Native library that includes a bunch of code that is basically a number of APIs that you can call into. Brent Vatne: So you could call, let's just say send payments or something like that. That's arbitrary, a name for a method. And this is something you can access from JavaScript that's defined in Objective-C, Swift, Java, Kotlin. But in addition to that, there's often some configuration that you need to do on the projects. So maybe you need to add a bit of code to the app delegate. Maybe you need to add something, main activity application and so on. Or possibly add some permissions, maybe to your Android manifests, or to info.plist or that sort of thing. There's just a number of different changes that you need to make that are beyond just installing a library into your project. So what needed to be done for Stripe in this case was to say, "Okay, we need to write this plugin, that for Expo projects, when you install this, it will go ahead and automatically configure all of these other aspects of the library inside of your project." Ben: This is a bit of a tangent, but I'm curious, does the ability to include and build into your app more arbitrary native modules affect the ability to run the app in Expo Go, or am I miss... Brent Vatne: Yeah. You're totally right. So Expo Go is the web browser aspect of React Native. It's this thing where you open this app, you write some JavaScript code on your computer, and you're able to just load that JavaScript code inside of this preset native run time. So naturally if you change the contract for what the JavaScript code can call into by introducing some native code that hasn't actually been linked inside of the binary that's running that code, you're going to end up with a bad time, probably your app crashing and so on. So if you depend on some of this code in your JavaScript loaded inside of Expo Go with the fixed runtime, that's not going to work. So another thing that we released with SDK 42 is this idea of a custom development client. So there's this library called expo-dev-client that you can install in any React Native project. Brent Vatne: And what it does, essentially is create that same browser like experience for your app, but against whatever custom runtime you have inside of your app. So in this case, let's say we wanted to install a popular library like react-native-fast-image. We would go ahead and install that. Install expo-dev-client, because we know now we can't use this library inside of Expo Go, and then we would just do a build using EAS Build saying, "Give me a new custom development client build using the current run time to find in the projects dependencies." Ben: So continuing on new features in SDK 42, we talked about first-party Stripe support, talked about the new build system. Anything else noteworthy? Brent Vatne: Yeah. I think something that supports the new build system, we have this visual studio code extension called Expo tools for VS Code. So when you're working on a Expo project on your machine, and if you don't have the iOS and Android projects locally. So you're just working and saying, "I want to just work in the JavaScript world and have you handle all of the... You being Expo, all of the iOS and Android aspects of this for me." One limitation of that is the feedback loop is potentially very slow on determining, I'm going to add this library to my application. What are the actual implications on what this changes inside of some of these configuration files? So if you want to see, "I've added this library. Now, what is my list of permissions that are being used on Android?" Because different libraries will bring in different permission requirements. Brent Vatne: So this extension is very useful for just being able to preview, what does my Android manifest look like in this case? And then tooling can be built on top of that potentially as well to make it a little bit less, maybe inside baseball, for people who aren't so familiar with, even how Android Manifest works. Just like, "Hey, just give me the list of permissions." So that's... Yeah. I think that's a quite nice addition. And then I would say the other notable feature is support for Hermes. So Hermes the JavaScript engine written specifically around performance for React Native applications like Facebook. It's something that has really matured a lot over the last couple of years and now moved on to iOS as well. So we thought it's time for us to add support for this in Expo now. So we've added support on the Android side and we'll likely be doing that for iOS in SDK 43. Ben: This is maybe a naive question, but I had thought that when you have a React Native app that runs on iOS, the JavaScript runs in a WebKit browser and then talks over a bridge to the native. But it sounds like with Hermes, it's a completely different JavaScript environment. So is that... Maybe I'm just wrong about the architecture, but I'm curious, maybe you can dig in there a bit more. Brent Vatne: Yeah. So in iOS, it actually doesn't do that. It calls into JavaScriptCore directly. So iOS has APIs that allow you to use the same JavaScript engine that WebKit uses, that Safari uses, by just calling into that totally independently. So where it allows you to swap out that implementation with this other engine instead. Ben: Got it. So apple doesn't have some sort of like policy that you have to run JavaScript in their JavaScriptCore, you're allowed to include your own JavaScript interpreter with an application? Brent Vatne: It's always tricky to understand exactly what Apple's policies are. There aren't any policies as of today that explicitly forbid this sort of thing. They're pretty open in terms of what interpreter you use. There a lot of apps that use Lua, for example, and then ship a Lua interpreter inside of the app itself. So it's a pretty similar idea to that. Ben: I'm curious, changing gears a bit, what is Expo managed workflow? You wrote... While I post about that, curious to learn a bit more there. Brent Vatne: Sure. So Expo managed workflow is what I was talking about a little bit earlier in terms of saying, "I, as a developer working on my project, I want to know about just the JavaScript code. I only want to own the JavaScript code. So in my .getRepo, I don't have an Xcode project. I don't have anything related to Cradle necessarily. All there is, is my React project. So Expo allows you to do this through this concept of having clients like Expo Go or custom development clients. So rather than the traditional way of using React Native with building your app in Xcode, launching it against the local development server and going from there, instead you open up the Expo Go app in your simulator or on your phone. And start up a JS server with a Metro Bundler, and then just load that from your phone directly. So the managed workflow is, it's a way of building your app without having to think about or own any of the native code in the project. Ben: When you look across all the developers and all the companies using Expo, what percentage of React Native apps today have no customization to native code and could exist as a managed workflow, or do the majority of developers still end up having to tweak something native. And then at that point, you have to jump into the Xcode project. Brent Vatne: I wish I had an answer in terms of numbers for this. It's very hard knowing even how many React Native apps are out there. I would say that probably a greater percentage than you would expect are capable of being built in this way. Often I see things posted on Reddit, or on GitHub or wherever, where it's examples of someone building an app with React Native and they didn't use Expo for it necessarily. And I go and look at it, and it's just libraries that are in the Expo SDK. And stuff that you could quite easily just build with using Expo and probably had an easier time with it. Yeah, it's hard to give an exact answer to that. But ultimately what we found was a lot of users getting to some point when they were building their application, where they were forced with some compromise. They had to think about, "Am I going to continue in the managed workflow where I can not customize the native code, and use a pure JavaScript implementation of this feature that I want to add." Brent Vatne: And maybe that's, for example, using some analytics API where they offer a native library, but you have to shoehorn the web JS implementation into your React Native app instead of using the native implementation, which isn't always an ideal thing to do. There's a number of benefits that come with using the native libraries for a lot of these tools, like synchronizing data in the background and so on. So these things come up, and ultimately that ended up being a limitation that drove us to build EAS build and this build system in the first place. Brent Vatne: So I think that if we're talking about the previous state of the Expo managed workflow, where you have this pre-built static runtime, I think there were a lot of limitations to that, and you would hit a ceiling at some point that would force your hand in terms of saying, "Okay, I'm going to now generate the native code for the project since there's a command to do that in Expo, and then just carry on outside of this managed workflow. Where now I no longer use Expo Go for development, I just compile my app in Xcode and continue building my app." Brent Vatne: So this new model now is, you can add any library that you want. You can use config plugins, they're called, which was what I was referring to before. The part where it doesn't just add this API, but it goes and configures your project to maybe add some code or do these additional steps that are usually manual. So you can use these to customize any aspect of your project that you would like, and ultimately really raise the ceiling on what's possible for writing, essentially a pure JavaScript that from your perspective as a developer. Brent Vatne: So another interesting thing that's actually very related to this podcast itself and the company behind the podcast is the LogRocket React Native integration, which I understand is in development still, not quite shipped. But we've been working at Expo with the LogRocket team a little bit to ensure that when it does ship, it works out of the box with Expo apps. So definitely excited for that since you guys do some great work on the web side, and I think there's a lot of benefit to be had from bringing this into native as well. Ben: Yeah. I'm also super excited, and mobile support overall and especially React Native support for quite a while, has just been by far the number one requested general area of product expansion from our customer base. And yeah, anecdotally, I would say a large percentage of our customers that have mobile apps are using React Native. And a large percentage of the ones using React Native are using Expo. So definitely a good fit there and will hopefully be a big plus for our customers. Brent Vatne: Yeah, absolutely. I think I've heard from a number of those customers requesting LogRocket integration specifically. So yeah, it should be a lot of fun when that ships. Ben: Yeah. I actually don't know the exact timeline for shipping, but maybe we can put in the episode notes, we can put maybe an ETA, a very rough ETA of when that will ship. We can't commit to anything here. But I don't want to get in trouble by saying a date that's going to launch it. I'm wrong. Brent Vatne: Understood. Ben: But looking a bit more to the future, what are you most excited about on the Expo roadmap, and maybe more broadly what are some of the themes in the Expo roadmap? What do you think about what you're going to ship over the next year or so? Brent Vatne: Yeah. So a core principle at Expo is we want to help developers build apps and iterate on them as quickly as possible. Iteration speed, I think is just so important to building applications these days. And we're working on a next generation of our update service as well for this. We haven't discussed this prior in this podcast yet, but to give a brief summary of it, there is this idea in React Native apps that you can do over the air updates. So what that allows you to do bundle up your JavaScript and any assets that are depended on by the JavaScript like images, or videos, or fonts or so on. And be able to update those at any point in time, by just sending it over the air through an update bundle. So our current pass over that is pretty good. It works for a lot of cases, but it has some limitations that don't work too well in a world where there are much more flexible runtimes. Brent Vatne: So the runtime in the former state of this managed workflow was always relatively fixed. We always had the same set of APIs available. You move forward to something where now between any different builds of your app, you potentially have a completely different runtime. There's a lot of different considerations that you need to factor in there. So we want to help people to be able to confidently update their apps over the air in this world where still you're moving quickly and iterating on your run time. I think the expo-dev-client package is also really exciting for the future. The use case we've mainly discussed here is you're building a managed workflow app, you want to add a new library. So you install expo-dev-client, you do a build event and then you have that library. Brent Vatne: But I think there's another really compelling use case, which is for people who aren't using the managed workflow at all, but maybe they have their organization structured or want to structure their organization in a way where they have an infrastructure team, a mobile infrastructure team, that builds out their own runtime, their own platform for their app developers to build on top of. And this is something that we've seen seen in a number of larger organizations that use React Native. There's a really good article from the team at Wix. And they have a team of infrastructure folks who work on the Wix engine, which is the same idea of saying, "Let's build this thing that the application developers can then just load up and not have to deal with any of these other native tools that maybe they're not so familiar with, and might occasionally run to blocking errors that are just hard to avoid in day-to-day development as tools shift. But just lock it down to this fixed runtime that people then work against. Brent Vatne: I think a common theme in developer tools spaces is that you take some concept that large organizations, or some set of tooling that large organizations have, and they have the scale and time to build this. You take that and you bring it to other organizations that just don't have internal capacity to be able to create this sort of tooling. So I think expo-dev-client is going to be a really nice way to take this concept that we think is very compelling. And we've heard from a lot of organizations in the React Native space that they would like to approach structuring their organizations this way, take it to a lot of other folks as well. So pretty excited about that. Ben: So would that almost be a way to customize Expo Go and add in some more native functionality, or some busy native functionality that's specific to your use case, and then you offer a broader set of APIs to build off of them, like what you get into basic Expo Go? Brent Vatne: Yeah, essentially. So let's say you're, I don't know, what's an... Let's just make up... Let's say LogRocket has an app that you ship, a consumer app for managing your log rocket accounts and viewing all of your information about various logs and so on. So let's say you ship this app and you are building it internally using React Native, using just a regular React Native project with iOS and Android projects, checking the source control. You had some customization there, had some custom native code that you've written. But maybe what you have is a team of app developers who work on the website and they know React really well. And they also work on the app, but they mainly just work on the JavaScript code in the app. So you could have some team of engineers who say, "We're going to build out the runtime for this app." So any of the custom native code, any of that sort of thing. Brent Vatne: And then just anytime they want to release a new version of that, give it to the developers and say, "Here's your new runtime to work against?" And if the app developers decide they need some new capability that's not available yet, then they can ask the infrastructure team to add it, or they can work on that on their own. But it creates this clear boundary between working on the application native runtime and the application itself. Ben: Got it. And looking at React Native itself, I haven't followed a ton on the actual progress about the React Native team has been shipping, but anything exciting recently that's changed in React Native, and anything in the near term future roadmap that people should be excited about? Brent Vatne: Yeah. I think React Native within Facebook, they've continued adopting it in a variety of products and screens inside existing products. Most recently, I would say an interesting development has been, they announced that they're using the new architecture called Fabric for every screen inside of the Facebook app. So the main Facebook app, and there's something like over a thousand screens inside of that app that are built with React Native, which is a surprising number of screens. But I think React Native is just quite widely used inside of the app. And as well, the app is absolutely massive. So there's a lot of features in there. It's like an operating system on its own. So Fabric is a really interesting project that's been in development now for several years, I think since maybe 2017 or 2018. And it's a full-on rewrite of the architecture of React Native to get rid of the asynchronous bridge, and be able to call directly into JavaScript from native and the other way around. Brent Vatne: And really make it more of a browser style architecture as well, in the sense where you call into a native API in your browser and you get a reference to some object that, maybe isn't necessarily a JavaScript object, but might be an object in C that you're then interacting with. And this is a little bit different from how React Native has worked historically, where you send messages, asynchronously over a bridge. So anything, you're holding a reference to something that's usually like, "This is a JavaScript object." That will then generate a message to send over... A message queue to the native side, where there's these parallel worlds existing at the same time. And there's a lot more to this architecture that's really interesting. It might make it easier to adopt React Native inside of existing native applications. That's been, traditionally a little bit difficult to do. So that could change the calculus that we were discussing earlier around whether it makes sense for organizations to adopt React Native if you already have a native team and already have a reasonably sized app at your organization Ben: Out of curiosity, what was the original reason why React Native went with the bridge architecture? Brent Vatne: I'm not sure I can speak to the exact motivations of the team, but I can try and extrapolate or guess based off of what I've seen, and some conversations I've had with people. I think the idea was that it's essentially decoupling from a performance side. We don't want necessarily native to wait on JavaScript to execute a lot of the time. We want to free up the main thread to do whatever work needs to be done on the main thread, like processing input, doing potentially certain types of animations and so on. And just allow JavaScript to execute on its own. Just an entirely separate thread in a non-blocking way. Brent Vatne: I think a big change that has happened there is that React is moving towards concurrent mode. So support for this would potentially allow for the main thread to call into JavaScript a little bit more safely than it currently can. Where you might risk now, say if we were to synchronously call into JavaScript from native, and then we were to trigger some large subtree reconciliation, this could take in the order of several frames or more in which you're blocking the main thread as well. So this maybe is less of a problem in a world where React concurrent mode exists. Yeah. I'm not entirely sure on the full motivation behind it, but I think that is probably one of the factors. Ben: So Brent, this has been awesome, chatting. For anyone out there who's interested in Expo, or React Native or working on these tools, it sounds like you guys are hiring, right? Brent Vatne: Yeah, definitely. We're looking for iOS and or Android experts specifically at the moment to work on the Expo platform side. So that's the Expo SDK itself, Expo Go and development client. So definitely reach out to us. You can check out the career section on Expo.dev and hope to see your application. Ben: Well, thanks so much. I really enjoyed chatting today. Brent Vatne: Yeah. Thank you. Brian: Thanks for listening to PodRocket. Find us at PodRocketpod on Twitter, or you could always email me even though that's not a popular option. It's brian@logrocket...