Brian: PodRocket is sponsored by LogRocket, a front-end monitoring and product analytics solution, which is to say, it's not really sponsored by anyone. It's sponsored by us, LogRocket, and we're giving it away for free. The podcast is free, the product is not free. There's a free trial, we could split hairs about whether or not that's free to you, but anyway, that's it. There are no more ads. If you're interested, and you want us to know that you came from the podcast, please go to logrocket.com/podrocket. If you don't care, logrocket.com works just fine. Thanks. In this episode, Ben interviews Charlie Cheever, CEO, and co-founder of Expo. They talked about the difficulties of building a cross-platform app, and what Expo is doing to make that easier for devs. They also get into the state of React Native, and a fair bit of other stuff. Let's get started. Ben: Hey Charlie, how are you today? Charlie Cheever: Good. Thanks for having me, Ben. Ben: Yeah, it's great to have you on, and for folks out there, Charlie and I were chatting before the show. We've talked a couple of times over the years, back before I worked on LogRocket, I worked on a project called App hub, which was like one of the early developer tools in the React Native space for updating React Native apps in production, and Charlie was really helpful back then as we were getting started. But today, Expo has grown into a pretty incredible platform for React Native developers. And so Charlie, maybe you could give a quick introduction to what your team is building, and how it helps developers build apps. Charlie Cheever: Yeah. So I think James and I, a couple of years ago, became really interested in this problem of, it's really hard to build a mobile application because you're faced with these two problems of, I got to build iOS, and I got to build Android, and so do I need two teams to even build something, especially if you're building something where you need a lot of people on it, or you need to let all kinds of customers be on it, which lots of things need that these days. And so we started looking at pushing the limits of HTML5, and seeing what you could do with that. And I think we uncovered the same conclusions that many other people have, that you just can't get much further than people have already, unless you're working on the Safari team, or the Chrome team, or ideally both or something. Charlie Cheever: And so we started playing around with pushing around native views, like using JavaScript to control native iOS views, and that felt immediately really good. So we started building a system around that, and then React Native came out. And so we said, "Hey, there's a hundred other things we want to do. So let's just take React Native and build the rest of this experience." And so one way to look at it is, both James and I came from this web world, and we were used to being able to build things really, really quickly, because web development has gotten quite good over the years in terms of enabling people to build very usable software very quickly. And so one of the goals we have for Expo is that it should be easier to make an Expo app than it is to make a website. Charlie Cheever: I think we're not quite there yet, but we want to first get to at least as easy, and then go even past that. What you can build with Expo is you can write one code base in JavaScript or TypeScript, and then we give you this native-feeling iOS app, native Android app. And then we also, about a year ago, introduced Expo Web, which lets you basically get a website as well. And so any platform where your users or customers are, we want to let you write this one code base that works everywhere. And of course, you can customize to the individual platforms so that it feels right on each one, but the bulk of the work can all just be shared. So you can sort of think of it as like Unity for applications. Ben: So I'm curious to learn more, specifically some of those tools around React Native, like what are some of the difficulties that developers traditionally had when building a cross-platform app, and what are some of the specific tools that your team is building to streamline those parts of the process? Charlie Cheever: There's kind of two parts of that. One is the set of tools we run on our computer and some libraries that we include for things that ... The biggest piece of that is we have a standard library for React Native. So we give you access to camera, push notifications, log in with Google, Facebook, stuff like that, recording audio, recording video, making the phone vibrate, using the accelerometer or the gyroscope, every piece of hardware on the phone pretty much, and every kind of common task you might want to do, like embedding a map, or things you might want to show that are typically native. And that covers probably 80% of the things people want to do in their apps, and a lot of people can just use that standard library to write almost everything they need for most apps. Charlie Cheever: We also built a set of tools around that, the most important of which is maybe this thing called the Expo Go client, which is an app you can get from the app store. That kind of lets you build an Expo app the way that you might build a website, where you can think of the Expo Go client sort of the way that you might use a web browser for development, where you kind of just point it at a URL, and then you can connect to that URL, and see it live as things change. So that means you can start getting started doing development without having to plug in your phone to your computer, without having to download Xcode anatomy, and download Android Studio without having to make those up to date. We even built a text editor in the browser, sort of like a js fill or CodePen. Charlie Cheever: So actually, without even downloading anything to your computer, you can just start getting started experimenting with stuff. So that's really popular with students, [inaudible 00:05:07]. So one half of we offer is this suite of open source free tools that you run your computer,, on your phone to do development stuff, and it makes the process of doing React Native development a lot easier. The other half of what we do is we basically run a set of services in the cloud that compliment those tools. And this kind of came out of the early days, we just had this free open-source product, and we were just trying to get people to use it. And we started to get people to use it, and they would say, "Hey, this is awesome, like I found Xcode such an annoying thing to deal with. I didn't like doing these builds. I struggled to figure out what a provisioning profile was, my certificates." Charlie Cheever: All these other things are super annoying. All of a sudden, I'm using Expo, and I'm just focusing on writing the code. That's relevant to my specific application, and Expo is magically taking care of the rest of stuff. And I have an app that I'm really happy with now, what do I do next? Like I want to put it in the app store, and then we would sort of say, "Oh, okay, here's a document that's two pages long and has 11 steps. And so download Xcode and enter Android studio, do this, get these credentials in place, blah, blah, blah. And then at the end of this process, you'll be able to submit to the app store."it And that didn't feel great because for our users, it felt like, "Oh, you've shielded me from all this complexity all the way through this marathon. And then 10 feet from the finish line, you're telling me to deal with all of this stuff that you've shielded me from the entire time, and I'm totally unprepared for it, and don't want to deal with it." Charlie Cheever: And so like a lot of the [inaudible 00:06:36]. And so we sort of said, "Hey, that's totally reasonable." I mean, they didn't literally say that to us, but from watching them, that was what we took away. And so we just realized what we needed to do was just kind of help people with that part of the problem too. So we built a cloud build service. And so you can basically, if you need a binary, either to put in test flight, or submit to the app store, or the Google play store, or even just an APK that you can send around to testers or something like that, you can basically run one command from the command line, or activate some other way. Charlie Cheever: All your code will get sent to Expo servers, and we'll do a build in the cloud for you, and we'll send it back. So that was kind of the first major service that we built. And then we also, around the same time, realized people were having a lot of trouble setting up push notifications. It was one of those things that's like, not hard at all, and anybody can do it, but even if you're the smartest person in the world, it would often take you a day of reading stack overflow things, or trying stuff, and then rebuilding, reloading or whatever, and kind of banging your head against the wall for somewhere between two hours and 12 hours, and then finally making a breakthrough. And conceptually, it's not that hard. It's like, I just want to send push notifications to this app that I'm developing. Charlie Cheever: And we realized, this is something that we can just make a lot easier for people. And also, it's something that people would have to set up twice in pretty different ways for iOS, and then Android. And so we just set up a push notification service that we could set up in 30 seconds, or five minutes at the most. And you didn't have to worry about whether a particular user was on Android or iOS. You just send a push notification to us, and we'll route it to the Apple or Google servers or whatever. And so that just made life a lot easier for people as well. And so a big focus of this year for us is making professional-grade versions of these services. So we just announced on our blog a few weeks ago, this new thing we're calling EAS, which stands for Expo Application Services, that are basically going to be like, if you're running a real app in production that is your livelihood, or something you care about, these are kind of built for best in the world type things. Charlie Cheever: We're having a new version of our build service that's much more powerful. It'll let you include any native code that you write or that you get from a third-party library. And then basically, anything you can build with React Native, you'll be able to build using this new EAS build service. It also includes a submission service that helps people submit to the app store, which is another thing that's not hard, but just kind of annoying. And so we can just sort of speed up your life. But then the other thing that's really a big deal is what we call our Expo Update Service. That's really similar to what you were working on at App Hub. And that basically lets people change the JavaScript or TypeScript of the app they've written, and then tell us about it, and then we'll use our CDN to push out a new version of the code to all the users. So you can kind of deploy your app the way you would a website. You could deploy a hundred times a day and make changes. Charlie Cheever: If you change the binary, you'd need to resubmit for review to Apple and Google and things like that. If you've made significant product changes, they would want you to do that, and you don't have to use this, et cetera, et cetera. But a lot of people really, really love this because it just enables them to have a great workflow. Ben: A lot of very interesting things, both they've already built, and stuff on the roadmap. I want to dig in a bit first to the concept of the standard library that you were talking about, that you've built for React Native, and maybe just briefly, for folks who are not familiar with the architecture of React Native, how it involves both writing JavaScript code, and then sometimes interacting with native code, and maybe more broadly, just how React Native works in terms of having JavaScript that you write, control, native modules, native views. Could you just give us a quick overview? Charlie Cheever: Yeah. I think that overview is pretty reasonable. And the one thing that React Native lets you do is write JavaScript to do a lot of stuff, or Typescript. But sometimes, if you want native functionality, you have to write a native module. And the core of React Native is pretty thin, sort of by design, and it's become more thin over time because the people who maintain React Native, it helps them just focus on that. But there's a lot of basic things that almost everybody wants to do that we felt like if we can make sure that people have a good experience, that'll be really, really helpful and useful to people, in the same way that you could take a language like Python or JavaScript or something like that, and if it only had the sort of the core essence of the language like variables and- Ben: While loops and for loops and stuff like that. Charlie Cheever: You could do some things, but then you'd find yourself, "Oh, I want to print out something to the command line," or something like that, and it's like, "Oh, there's no way to do that." And so you have to sort of install some native components. And so that's kind of a little bit how React Native feels. And so we felt like we need to provide the standard library, and pretty much everything in the Expo standard library, there were other ways to do it, or there are other ways if you were working on now, but the advantage of Expo is we make sure all these things work together and are kind of well-tested together, and they kind of use each other. So if you are doing video recording stuff, it lines up with the camera module pretty well. And if you capture an image, you want to save it to the file system, the file system access module is what we use. And so it's sort of familiar. Charlie Cheever: And when you're building a standard library, you often end up with a lot of intertwined dependencies. It actually kind of makes sense to bite it all off as one big chunk, rather than having separate siloed projects that don't evolve together necessarily. And one thing that is a challenge, I think there's a lot of cases where there would be a cool camera library, or something like that, that somebody wrote for a project that they did. And then they don't upgrade the version of React Native they used where they abandoned the project. So if you're searching on GitHub for these native modules, it can be a little bit of a minefield of finding a lot of things that aren't maintained, or outright incompatible with the version of React Native they're using, or you might want to use two modules that are native, and they might not be compatible with each other for one reason or another, and it's not easy to tell that in advance. A lot of things go away when you have this sort of monolithic complete set of stuff. Ben: With these modules like camera, or push, or file system, do you abstract away the differences between Android and iOS, and how those underlying APIs are implemented? Charlie Cheever: Our philosophy there is basically, I think a lot of the art of what we do, at least in this area of stuff, is basically figuring out a common API that feels right to a developer, and is elegant, and lets you express the behavior that you want in your head for the user succinctly and clearly, and have it work on both platforms. But then we also try to let you access the deep functionality, or the platform-specific functionality. So if there's something that's only available on iOS, or only available on Android or something like that, then we can let you take advantage of that without having Expo to be the lowest common denominator where you can only write so-so apps, because the only stuff that works for us everywhere. So just trying to give you the power of both, and balance those things, is very important to us. Ben: I imagine you talked to a ton of developers out there at big companies building React Native apps, like what do you see in terms of best practices when it comes to architecting, especially the view layer of their application? Are they able to share a lot of application code between iOS and Android and just have different view layers, or do you see a fork deeper down the stack in terms of how they're architecting their front ends? Charlie Cheever: Yeah. So if you look at the React Native website, I think that they have this slogan that comes from when they announced it, that says something like, "Learn once, write anywhere." And I think that even though Expo is built on React Native, I think there's a difference in philosophy where the way I think about things is, I don't want to learn once and write anywhere. I want to write it once, and have it work everywhere. I think sometimes people, when they hear that, they're like, "Oh, that doesn't work." That was the promise of Java in the 90s, and it just didn't work out. But that's the wrong thing to look at. I think the most successful software creation distribution platform for users of our lifetime is the web, and the web browser. And if I write a website, I don't write a similar website for people who have Macs, and one who have Windows computers, and then one of Linux machines.I write one website and it works everywhere. Charlie Cheever: And I think that that's extremely powerful, to not have to worry about that stuff. And so if you think about what devices are these days, I have an Android phone and an iPhone in front of me, and they're both about the same size, they both have black touch screens. And so when I'm in an application, I don't really want a different experience on Android, and a different experience on iPhone. I want the same app, and I think that like the idea that these apps should be different is mostly gone away at this point. Like if you look at seven, eight years ago, apps like Dropbox and Slack, if you download the Android app and put it side by side with the iPhone app, you would be like, "These are really different apps." Charlie Cheever: I tap here on the Android one, I tap here on the iPhone one, and now this flow is completely different, et cetera. And for a whole bunch of reasons, nobody really does that anymore. So if you look at anything modern, like Instagram, Snapchat, TikTok, they're all basically exactly the same app on both. And I actually would take that one step further, where I think almost everybody now does the same thing also with their mobile web product as well. Sp if you go to the Instagram mobile website, you probably have to look at it for 30 seconds before you could tell the difference between the mobile website and the native iOS app, or the native Android app, or something like that. And it makes sense. It's the same form factor. It's the same screen. It's the same touch input. Charlie Cheever: You don't really want a different product. There might be a few things that are a little bit different because maybe the way that routing works, or URLs are exposed, or some of the browser Chrome interacts, or whatever changes some of the details around the edge of your product, but mostly you want the same product. And so we want to make it so that you write one code base, and maybe you have a couple of if statements or specific things where you say, "Oh, customize this for Android or iOS for some design reason around the edge," but mostly 95+ percent of your stuff, and in a lot of cases, literally 100 percent of your code is just the same across everything. Ben: It's interesting, thinking about that, and if that is the future of, developers build one app, it's kind of the same on all platforms. I wonder with this, you were talking about Expo Go before, which is kind of like a web browser. Here is a shell on your phone where it can interpret arbitrary JavaScript, and display something to the user, and interact with native camera or other things much like a web browser. JavaScript does have APIs for interacting with some device stuff. Is there a future where developers can build fairly native feeling iOS and Android apps without necessarily having to get users to download them and install them on their device? If every person in the world had Expo on their phone, could- Charlie Cheever: Yeah, it's completely technically possible. There's just app store rules that make it hard to release something like that. But we've certainly thought about that, and we'd love to build that if we were allowed to. You'd have to do some work to make React Native a bit more backwards compatible, because one thing that is really powerful about the web is, I can take a modern version of Chrome, and open the Space Jam website from 1996, or whenever it came out, and it looks perfect. It works the same as if I had opened IE4 or whatever in 1996 and looked at this. I mean, maybe there's some tiny differences here or there, but things are almost completely backwards compatible with the web. And that is really, really great for letting you look at all these different things. Whereas the way Expo Go works, we jam the last three to six versions of React Native and our SDK and stuff all into one app, and do a bunch of clever engineering tricks to basically have six browsers in one mashed into the Expo Go client. Charlie Cheever: And one thing that sometimes you'll run into that we're coming up with ways to make better, is if you were to look at something that was made 18 months ago, or two years ago that hasn't been updated, you can't actually look at it with Expo without running an upgrade step. And that's a little bit annoying. We work pretty hard to make the upgrade process really easy, and I think we've done a pretty good job of that, but I would love to get more backwards compatibility into React Native, and I think that would be the most important piece of work that would be required to get there, but there's really no technical reason that it couldn't happen otherwise. And I think it almost inevitably will happen, like it's just too efficient and too cool and awesome for it not to. I think the question is whether it happens through something like somebody making a version of something like Expo Go that is able to get everywhere and load things and that's allowed, or whether it happens through web browsers themselves adding this functionality, and continuing to get better. Charlie Cheever: And like there's technical reason that couldn't happen either, but there's a lot of political legacy engineering. There's a lot of things would have to fall into place for that to happen. I'm pretty sure it will. Ben: Right. Yeah, I remember when React Native first came out years ago, Matt, who I worked on both LogRocket and App Hub with, we were kind of hypothesizing that potentially, Facebook was going to launch, imagine something like Expo Go in the Facebook app where third-party developers could build the next Farmville, or other Facebook apps that run in the Facebook app on their massive install base. But I guess they never did that quite like that. Charlie Cheever: I'm sure they've thought about it. If you look at, in China, like WeChat, I think it's called [crosstalk 00:19:39]. Ben: Yup, exactly. Charlie Cheever: I believe that uses HTML5 as its runner technology, but they basically have this, if you just sketch out what you're describing, it exists in China, but it doesn't exist in America, probably just because of the rules of the people running the mobile app stores. Ben: Right. I guess that's a good question. You are allowed to have a web view, like a true web view in an app, and a load and arbitrary webpage, or is that not categorically true? Charlie Cheever: Sometimes. When you look at app store rules, one, you shouldn't necessarily listen to me as an expert, because there are no experts except for the people who run these things, they change the rules a lot and they enforce them in different ways. And so it's just really hard to say anything definitively when you're not in charge. But I would say that Google seems to mostly be okay with most reasonable things, as long as you're not being categorically abusive, and Apple is much more restrictive, and they would give you reasons of why they are that way, but some are reasonable. But there's kind of two angles to that. One is a set of rules that are sort of like, "Here are these rules that are technical, and about engineering and stuff like that. And then here's another set of rules that are much softer and more human, and product and things like that." Charlie Cheever: And so a lot of times you'll read, "Oh, you can include a web view,, and that can read this or you can run dynamic code that is downloaded from a server, but it must be JavaScript that is executed on JavaScript core." And that was one version of the rules a while ago. The current ones, I think, let you download any dynamic code, as long as it doesn't do certain things. But I know a guy who wrote an app that was just using a lot of web technology, and it got rejected because your app seems to mostly be a way for users to play different HTML5 games in a way that looks too much like an app store. So in that case, the rejection wasn't about the technology, because you're allowed to use web views" in your app, but it was about, Oh, we don't want this kind of product in our app store." Charlie Cheever: And so I think there's kind of two different ways to look at these things. And over time, I think the way that enforcement has happened has shifted away from, "We don't want you to do this technically," to more things that are like, "We don't want you to do these things from a product perspective." And that's more of where the emphasis is these days, although both these sides of the coin still exist. Ben: So shifting gears a bit, I feel like over the years, and conscious of the fact that I'm kind of observing more from the sidelines in terms of React Native, since I've been mostly on the website the past few years, I feel like the popularity of React Native has kind of waxing and waning, it seems like gets a lot of popularity and then people, maybe aren't talking about it as much for a while. And I remember there was that article from Airbnb, which was now probably two years ago where they said we went early, we invested in React Native, and then we pulled back and went back to Native. What do you see as the state of React Native in 2021 and moving forward? Like, would you recommend any company on earth if you're building an app, you should just use React Native categorically, or are there times when a company should still decide to invest in separate native apps, and how should developers think about making that choice if they're starting a new app? Charlie Cheever: So I think React Native is getting there, and I think it's close. So I think that for most companies that are starting from scratch, using Expo and React Native is a very good choice, and one of the only reasonable choices. Flutter, I think is pretty reasonable for certain things. Obviously if you're building a game, Unity is a great choice, and there's other game things, that's kind of a different world. But thinking back to the Airbnb thing you were referencing, I'm not close to that situation at all, I don't know the details, but looking at it from afar, my guess is that the biggest reason that that whole thing didn't work out in the end was that it was kind of like this Brownfield app that they talk about, where they had an existing iOS app and an existing Android app and ongoing work from an iOS team and an Android team. And they were trying to put React Native in there and have both those things work together. And that's a much harder problem, I think, than a Greenfield app. Charlie Cheever: Here's one of the reasons why. I think a lot of it has to do with data. So if you think about building an application, if you're using React Native, you might use something like Redux, or you might use Recoil or some other things, and other frameworks have their own solutions for this kind of stuff. But at some point, you're coming up with some way to track state on the client. And you basically want there to be one source of truth for that, because otherwise, you deal with tons of complexity. And so one challenge of writing this Brownfield type app is that if you have a bunch of people doing work in Java or Kotlin and Swift, objective C or whatever, then you have another set of people doing work in TypeScript or JavaScript. Charlie Cheever: You are often going to end up with situations where you have two sources of truth, where there's one set of people using data structures that are in Swift world or Kotlin world, and then another set of people that are using data structures that are JavaScript objects. And you can access either one from the other side of the divide, but there's a pretty big cost to going over that bridge. And if you start doing it a bunch of times, you can run performance issues. And so then you start maybe setting up a cache of one kind of data over the other side. And it just becomes a big, gnarly mess. I think there are probably ways to handle that well, but at those best practices, I think are sort of still locked up in the secrets of companies that have dealt with this, and they haven't publicized it enough that they're well-known across the industry. Charlie Cheever: And I do think that this is something that has gotten better in React Native. One thing that I know the Facebook team had worked really hard on is this turbo modules thing, which among other things, means that you can go synchronously across the React Native bridge, instead of having everything be an asynchronous call that you don't have great predictability or control over the timing of, and things like that. And so that kind of problem I think is getting better. And I can't speak for them, but my understanding is, I think a focus of the React Native open source team and Facebook's work is making this work for all kinds of big apps and big companies and embedding it and things, which I think was a weakness of React Native before. Charlie Cheever: At Expo, our focus is really these new apps that start from a Greenfield, and you can just write everything in TypeScript or JavaScript, your source of truth is there. But then if you have one screen that does something really custom, or two screens or three screens, or a section of something, you can write native code for that, or pull in third-party new code. So a great example of this is Cameo, which is this pretty popular celebrity video shout-out platform, is an Expo app. Most of the app is written in JavaScript, but then they have some custom stuff around their video player and recorder and stuff like that, and they need to have some native code. And that part they've written native code for. But they don't need their whole team to be able to do that. They just need one or two people who focus on that to be able to that on that particular screen, and the rest of the stuff can be written in TypeScript and JavaScript, and it ends up working pretty great. Ben: And you mentioned that the tooling within Expo to basically push updates through application without going through the app store process was one of the more important developer tools that you've built. Is that something you can still do when you have an app like Cameo, for example, that has written custom native code, or how do developers get around those kinds of limitations? Charlie Cheever: That's the kind of thing that makes the problem of getting it right fairly complicated, and why it makes sense for us to do it, because we can focus on like getting it right in a really robust way that's well-tested, and then literally battle-tested across tens of thousands of apps that are in the app stores using it. Because if you were to write some kind of update thing yourself, you might miss an edge case, and end up with an incompatible JavaScript deployment with a mismatch with a binary code. And then the app is crashing all the time, and you can't pull an update until you do another push to the app store review process, and go through the app store update. And so part of what Expo updates handles is making sure that users only ever get a JavaScript version of code that is compatible with the binary that they have on their phone. Charlie Cheever: And so if there's a straggler who's not updating their app from the app store, they're eight months behind or something, they're not going to get the latest version of your JavaScript unless we have some reason to believe that it will work with that binary code. There's also a bunch of complexity around, what if somebody downloads my app and then doesn't have access to the internet the first time they open it? We actually had a company that was making logging stuff for truckers. And so they were really worried about this, where they thought, "Oh, what if this trucker down this app, and then they're a hundred miles into the desert, and they need to use the app, but they don't have access to the internet?" And so whenever you have an Expo app, when we run our build service, or you do a build locally, and make an artifact that you're going to submit to the app store, we take a snapshot of all your JavaScript and all your assets. Charlie Cheever: They're going to bundle this thing, your fonts, your icons, things like that. And those are included in the app binary bundle to get shipped so that will work immediately the first time it's opened. And then the mechanism that we default to as a policy is downloading in the background so that the next time you open the app, it has the new codes. Kind of like the way if you use Chrome on your computer or Spotify or your computer, if there's an update, it doesn't immediately happen. It's like the next time you open the app. And that works pretty well in mobile because apps are restarting all the time, because the operating system kills them all the time. But we also let you configure different policies, like if you wanted your app to work more like a website upon loading, it's always checking in for the latest version. Charlie Cheever: There are some people that would prefer that. And so you can configure that using Expo updates. And generally, there's a bunch of little sort of corner cases and edge cases in this problem, and we try to handle those all for you in a robust way that feels pretty seamless, and generally try to encourage people towards this workflow where every time they're making a get commit, and doing a get push to master or release, it's wired up to doing an update to all users, and that they're constantly pushing out their work to their users. Ben: Basically the way web developers tend to work, which is web developers take for granted the ability to update frequently on every commit, or however they want their workflow to be, and the idea of kind of abstracting away the platform difficulties for developers makes a lot of sense. Charlie Cheever: That's kind of a template for how we think about things. We want to make it as easy to build an Expo app as it is to build a website, and then go beyond that and make it easier. But we're trying to like use a lot of the same principles, a lot of the same techniques, a lot of the same stuff. So if you're coming over from web, it should be familiar because we just see so many good things about that. Ben: It's interesting, you mentioned earlier building web apps with Expo. I'm curious to learn a bit more about that. If I heard correctly, typically people think React Native, they think iOS and Android, but what does it look like to use Expo to build a true cross-platform app that also has a mobile web component? Charlie Cheever: Yeah, I think it's still evolving. We still mark our web support as in beta, but there are people that are using it in production with success. A couple of examples of the time I had, like the Stanford Daily newspaper has one code base. You often end up needing to do more custom stuff with web right now than you do with iOS or Android, partly because it's still like a beta platform for us. But partly also because there's stuff like a URL bar, and other things like that that are just a little bit different in the browser. And people often are loading stuff a different way. So the best way to use Expo web is probably with Next.js. And we're sort of trying to build Expo web to work well with it, because we see that people really, really like a lot of things that Next gives them in terms of like SSR, which is really important for SEO and first load performance for a lot of web apps, and a lot of ergonomic things as well. Charlie Cheever: A really cool story I heard the other day was a guy I know sent me a message that said, "Hey, I've been working on the website for this startup I'm now the CTO of. It's called Beat Gig, and it's kind of a way to book bands for your frat party or your birthday party. It's a pretty popular service, and they're making their tech stack a lot more modern, so like that." And so he basically said, "I built the whole website using Expo, and we weren't even thinking about our mobile apps yet because one thing at a time. But then I just spent one day, I spent a couple of hours, and I have a iOS app that's working great, and an Android app that's working great, because I was able to just take the same code base that I've already been working on, and ran out of the box. They're working with a couple of hours of tweaking. I want to get that down to like zero hours of tweaking so that things just work everywhere." Charlie Cheever: But this is the community. This guy, Fernando Rojo especially, is doing great work to fill in all these gaps so that that sort of magic can go down to basically being like, "Oh, I just took this one code base, and it just works perfectly on web, it works perfectly in Android, works perfectly on iOS." There's still more work to do, but great progress is being made. One reason I really believe in that future is, a lot of people don't know this, but twitter.com is actually built with React Native web, which is originally created by this guy, Nicholas Gallagher, who was working at Twitter at the time, and he works at Facebook now. But he basically really liked the React Native model, but his job wasn't to build the Twitter mobile app. Charlie Cheever: It was just to build the new mobile website that he was working on, and ended up working so well that they ended up adopting it for the main Twitter website. And so Twitter is obviously one of the most popular, successful websites in the world. So I would be definitely believe that this is a very powerful, good, reasonable technology to use to build any kind of website that you want, pretty much. The fact that that's being proven in production at massive scale really gives us confidence in that direction. We also just find, this is just what people want. I had lunch the other day, or a while ago now, because it was before COVID, with some people who were working on a meal kit startup kind of like Blue Apron, but for vegans. I think it's called Thistle. And they're basically saying, "Hey, we are a food company first. Like we're trying to get fresh vegan meals to people that are healthy." Charlie Cheever: And so food and logistics around food is kind of our top priority. And then we're sort of a tech company after that. So we're not, not a tech company, but like we only have two developers on our team. We might add a third soon, but we're probably not going to have 15 developers anytime soon. So we thought that we just wouldn't be able to have an app. We just thought, what we can do with a couple of developers is make a good website, make it work well on mobile, and then people everywhere will be able to access this. Even if some of them would rather access it through an app, at least we'll be able to give everybody something, and we'll be able to do it easily, because the web is pretty easy to build on. Charlie Cheever: So they built their website with React. And then one of them discovered Expo on a weekend, put together a prototype in a day or two and showed the CEO, and the CEO was just like, "Oh, this is awesome. I didn't realize this was possible. How hard would it be to roll forward with this and put it into production?" And so then they just said, "Hey, since this app is really just written in JavaScript and TypeScript, and we're already using React for our website, so it feels familiar, we can probably just stretch our tiny development team to support this iOS app and this Android app, without adding new developers, and sharing some code, but mostly just sharing techniques and design patterns and stuff." Charlie Cheever: That's an awesome story, but it would be even more awesome if they didn't have to deal with these two code bases because really, they want to have one product that's delivered everywhere. And so that kind of thing is what inspired us to like work on Expo web and treat this as one problem that's not just like, "Oh, I want to do iOS and Android, but it's really iOS, Android, and web." And eventually, I think desktop and stuff as well. Why not have a native Mac app and a native Windows app and a native Linux app that comes out of your Expo project? Ben: Yeah. And I guess on that note, what do you see over the next few years for, I guess we can start with Expo specifically, and I'm also curious for your thoughts on where you see React Native as a general platform going, but for your team's roadmap, what are you most excited about? Charlie Cheever: Yeah, for us, this new suite of services I think is really powerful, especially EAS Build will let you include any native code that you want to include in your project, but have us build it for you in the cloud. And there's so many things that we can build around that in terms of making a really pleasant, easy, simple workflow that also gives you all the power of anything you could do on your own computer. A criticism that people used to say about Expo, and still sometimes do, is like, "Oh, Expo's really great for starting out or doing a prototype or things like that." But if you're getting really serious, and you need to do complicated or custom stuff, then you probably want to write React Native yourself, and shouldn't use Expo. And we think we'll flip that around where it'll become, if you need to do complicated, tricky stuff, you really should use Expo because that will make it so much easier, no matter what you're doing. And I expect that like more and more things will be built with React Native. Charlie Cheever: We'll see what happens between React Native and Flutter. I think that React Native feels quite good to me. When I talk to students and things like that, like 10 years ago, students were really excited about taking iOS development courses in college and things like that. And now the students that I've talked to for the last couple of years, they're not really that excited about that. They're excited about machine learning, they're excited about building things, but they don't really want to take the time to learn all the details of memory management and type safety and stuff like that, they just want to build stuff. And so things like React and Expo are really, really exciting for them, because it just lets them do the stuff they want to do much more quickly. Charlie Cheever: Just looking at it from that perspective, I think we'll see this whole generation of people that are much more likely to build things with React Native because they're building things in React, and that's what they know, and so they'll find a way to make it work. A really big goal for me for Expo is the next generation of things that are kind of foundational and all around us. I wish Clubhouse was built with Expo, I want the next TikTok to be built with Expo, things like that. And I think there's no reason that that can't happen, except that there's work to be done to make it so easy, and get enough people educated, and make everything so powerful, that it just makes sense to do it that way. And I think we're really close, but there's just a couple more things that have to happen to get there. Ben: Well, Charlie, thank you so much for joining us today. It's been great, and it's exciting to hear how much React Native and how much Expo has progressed over the past few years. So thanks again for joining us. Charlie Cheever: Thanks so much for having me. Brian: Hey, it's Brian again. So it turns out that running a podcast is maybe harder than we thought. And so I kind of want to hear from you. I'm genuinely interested in your feedback. We have to think about new topics, new guests, we have to find them. And don't get me wrong, we can do it, but it's a lot easier if everyone else who's listening helps. So if you'd like to suggest the topic, or volunteer to be on PodRocket, we'd like to hear from you. So you can do that by going to podrocket.logrocket.com/contact-us. The hyphen is next to the delete key, if you're curious. If all of that is too long, you can just email me directly, brian@logrocket.com. That'd be great. Also, if you're feeling magnanimous, be sure to like and subscribe to PodRocket. Thank you.