EPISODE 1775

[INTRODUCTION]

[0:00:00] ANNOUNCER: Expo is a development framework that streamlines the process of building cross-platform mobile apps using React Native. It eliminates the need for a complex native code setup by providing pre-built APIs for common device features like the camera and GPS, making it easier to access hardware functionality. It also simplifies the deployment process with built-in tools for building and distributing apps. Charlie Cheever and James Ide are the co-founders of Expo. And they join the podcast to talk about the framework and the problems it solves. 

Kevin Ball, or Kball, is the vice president of engineering at Mento and an independent coach for engineers and engineering leaders. He co-founded and served as CTO for two companies. Founded the San Diego JavaScript Meetup and organizes the AI In Action Discussion Group through Latent Space. Check out the show notes to follow Kball on Twitter or LinkedIn. Or visit his website, kball.llc.

[INTERVIEW]

[0:01:08] KB: Hey, guys. Welcome to the show.

[0:01:10] CC: Hey, thanks for having us. 

[0:01:11] KB: Yeah. Excited to have you on this. Let's get started and maybe have each of you introduce briefly. And then we'll get into the meat of the show. Charlie, do you want to go first? 

[0:01:19] CC: Yeah. Sure. I'm Charlie Cheever. I grew up in Pittsburgh, Pennsylvania. Studied computer science in college. And then worked at Amazon and Facebook. And co-founded Quora. And then took some time off. And was so frustrated by how hard it seemed to build anything in mobile. And that was the only thing I was interested on that I convinced James to work with me on Expo eventually.

[0:01:40] KB: Nice. And James? 

[0:01:42] JI: Hi. I'm James Ide. Yeah, I've been working with Charlie for over a decade now on Expo. Similar feelings. It's just kind of like the holy grail for every company, if you look to your left, look to your right, to be able to have one engineering team to be able to build everywhere. I've always been into building software for other software engineers. And that's exactly Expo does so. It's been a great journey so far.

[0:02:02] KB: Yeah. Let's get into it. Do you want to share for our audience what is Expo at a high level? And then we can dive into progressive levels of detail. 

[0:02:11] CC: Sure. I think at the highest level, it just starts from this thought of basically what James is saying, where people have an idea of something they want to build. And how do we make it so that it's as easy, and as fast, and efficient as possible to build that at the highest level of quality that you actually want to achieve? 

And, specifically, the modern version of this problem involves attaching to a bunch of surfaces. Mainly iPhone, and Android, and web are the three that we're focused on. Because that's where every significant product that people build ends up needing to be on all those three platforms. And we try to balance. We really start from this one codebase philosophy. You have one engineering team working on one codebase. We also try to balance that with respecting each platform and its differences. And sort of making sure that it feels native to each platform and is native as much as we can possibly do it. Would you add anything to that, James? 

[0:03:06] JI: Yeah. Another way to think about it is we want to enable engineering teams to build apps that are truly native while having a universal codebase at the same time. When building for, say, an iPhone, we want to be able to use the iPhone's native user interface capabilities. It's a truly native iPhone app. And, similarly, on Android, we want to use Android's truly native user interfaces and build a native Android app. And on the web, DOM is the native UI toolkit. And we want to allow people to have pretty close direct access to the DOM. And React is a great way to achieve that. 

We want to have native apps will also have a universal codebase that one team can work on. And so, that way, say, a product manager or a designer doesn't need to go talk to the Android team, and the iPhone team, and the web team. They can just talk to the accounts team or the user profiles team and have one conversation. The product is very coherent. We'll still have native apps for each respective platform. 

[0:04:02] KB: For an old-timer like me, this sounds like what PhoneGap, which became Cordova, was trying to solve. Are you all kind of similar to that? Or how would you describe your relationship to that project? 

[0:04:12] CC: I think that a lot of what we wanted to do was born out of frustration with those, where there's so many great properties of the web as being this Universal way to render UI across many places. But when it came to phones, it just doesn't feel quite right and doesn't have a lot of the little details that make using our phones delightful in a lot of ways. 

I mean, you could see this where - I think a while ago now. But there was, I remember, a TechCrunch article where the headline was Mark Zuckerberg announces biggest mistake Facebook has ever made is building its mobile app with HTML 5. Ditching that and rewriting everything in native. And that was going be a little bit overblown. And I think there are times and places where HTML is a perfectly fine way to render stuff, especially as phones get faster. 

But there are lots of things where it just doesn't feel right or native to the platform in a mobile context if you're not using the operating system mobile widgets and you don't have a certain frame rate or level of performance, the gestures, the animations, the ways that you interact with it through touch. 

And I think the thing that we really believed that we had to push hard on to build was that we believe you could use technologies like JavaScript and things like that and achieve this. But that all of the layers of accumulated backwards compatible, standard space stuff that had built up in the browser over time, the implementations of mobile Safari and Chrome, as it was at the time and still to this day, they just weren't quite delivering the experiences people wanted. 

I mean, you can still see this where people just complain about not native apps. And, also, I remember just talking to a bunch of startups and them saying like, "Yeah, we tried building a version of our app in web. And it was great that we could move really, really fast. But, qualitatively, our users didn't really like it. Our stars in the app store and our feedback was worse. And, also, just quantitatively, we just saw people not using our stuff as much. And so, we had to go back to native. Or we need to when we have enough money to." Or things like that. We just wanted to solve that for ourselves as much as anything else.

When we started working on this, a big motivating factor was just everything I can think of that's interesting to build is not just a website. But it's going to involve an app, on iOS, an app on Android. Because that's how people use technology. If you think about how often - but just like how - probably, if you look at your own behavior, obviously, there was just this - when the Blackberry came out, and then especially when the iPhone came out, and et cetera, there are these jumps. But still, there's been this like 15-year long journey towards like us using our phones and tablets for almost everything. And it's still crazy to me that there's still 10 times as many web developers as mobile developers when our usage is now tilted probably like 70% to mobile as human beings. 

A big part of what we're trying to do is just sort of correct that imbalance of this is how people show us they want to use software. But still, as developers, our natural inclination when we start a project is a lot of times to just be like, "Oh, a website is so quick and easy and it can get going really fast. And there's all these tools and whatnot." And how can we make the tooling in mobile match that? 

[0:07:17] KB: Yeah. That makes sense. Okay. More emphasis on native technologies. If I understood correctly, digging into, because I'm not an Expo user. But I was digging into what you guys have. It looks like you're building largely on top of React Native on sort of the development experience. 

[0:07:34] JI: Yeah. I would say Expo kind of sits adjacent to React Native. It complements it. React Native has a couple of pieces. Specifically, one way to think about it is it's a rendering engine that allows developers to kind of register native code exposed to JavaScript, and also provides a lot of facilities really specific to React in order to get the benefits of the reconciliation architecture of React. And then Expo complements it being like a framework that kind of provides a lot the developer experience that you'd want when using the React Native technologies.

[0:08:03] KB: If someone were coming from the web world, would it be fair to say you're kind of like the Next.js equivalent in terms of a meta-framework around the sort of rendering library? 

[0:08:13] CC: Yeah, it's a pretty good analogy. People use that a lot. It's not absolutely one-to-one match up perfect. But in broad strokes, I think that makes a lot of sense for getting your head around it. It's a good way to explain it.

[0:08:23] KB: Because I like to geek out on this stuff, let's go into the places it doesn't match up. How are the nuances different? 

[0:08:30] CC: One thing that jumps out is just that one thing that has been built out over time on the web is just that a lot of the sort of widgets and things that you need are kind of available already. Whereas one of the big efforts that we put in is building what we call the Expo sort of SDK or standard library where we built something - like over 90 APIs that just are standard across iOS, Android, and, in most cases, web. And just kind of are well-tested, battle-tested work across all these things. And, importantly, work with each other. 

And so, you can kind of just trust that these are well-maintained. And the APIs are going to feel similar and look similar. And they'll all sort of work in concert with each other. And it doesn't mean you can't go use your own thing if you want to do - a big part of what we want to do is always let people have escape hatches. Do custom stuff. Do whatever crazy thing they need to do for their use case. But it just gives you this starting point of - sometimes people talk about us as like batteries included and whatnot. And just makes it like so much - your zero to getting a product together that works can be way faster when you're not getting hung up on that. What am I going to do about the camera? What if I want to have haptics? What if I want to have vibration? What if I want to play a video? What if I want - there's so many things like that that just every individual developer was sort of having to work out those details on their own in a lot of cases and then across multiple platforms. And just having that I think is probably the biggest difference. Where I think the web on its own evolved a lot of that. And so, Next.js doesn't necessarily have that responsibility in as great a way.

[0:09:59] KB: Yeah. That makes a ton of sense. Kind of providing not just the application framework layer, which is what Next is really focused on. It's like how do I build applications on top of React? But, also, kind of the phone abstraction layer of like, "Oh, phones expose all these capabilities. How do we use them productively in a React Native based application context?" 

[0:10:20] CC: Yeah. But just to call it some ways that things are similar, I think one thing that Expo solves that Next also solves is sort of this routing problem of like, "Okay, how do I take a URL and then map that to a screen or some logical component of our application? And then how do I deliver those to people and organize them in my codebase and also in my app and whatnot?" And Expo router is a big piece of our offering. And that's sort of an evolution of multiple versions of navigation stacks we've worked on over the last bunch of years. 

Evan Bacon, who's probably the most famous person on our team, has driven this forward and done most of the work on it. But it not only sort of solves the routing problem of URLs to screens and whatnot. But we also have a tricky problem there of the way that navigation works on mobile phones is a sort of just different than the way it works in web browsers on your computer. Where on a web browser on your computer, you might have multiple tabs. But if you set that aside for a moment, you have a URL bar and then you kind of have one screen. Whereas in mobile apps, what we're used to is kind of typical sort of app is a tab bar at the bottom that each sort of is its own kind of a browser tab with its own stack and whatnot. But there isn't necessarily a URL bar. You just kind of vaguely know that the home tab of Instagram and the explorer tab of Instagram and the profile tab of Instagram all have their own sort of navigation stacks. 

But the other thing is that that's kind of the norm in mobile apps. But, actually, every app has the potential to do it a bit differently. And sometimes you want it to be done a little bit differently. And then, also, things work a little bit different on iOS versus Android. And there's some differences there. And so that's been a really gnarly problem to get right. 

And then the other layer that we spent a bunch of time over the years working on is also that that's also one thing that people are incredibly sensitive to. And so, there's people out there who still will say like, "Oh, I can tell the difference between a true native app and something built with any other framework by just give me 45 seconds of playing with it." What they usually mean is that they'll try to go back and forth and do some sort of navigation thing and see if there's some little tick there. It's one of the things that people are somehow, for whatever reason, incredibly sensitive about. 

We've done a lot of work to try to lean on native stuff there and incorporate that and integrate that into our offering, so that we get to the point where people basically cannot tell that there's an Expo app or not an Expo app without sort of having access to the source code or something like that. 

There are some rough edges that we're not absolutely perfect on this yet. But that's kind of where we're trying to get to. Where if you're using the Expo app, it's like it feels at least as good. Perhaps even faster in some cases. Because things we can do with multi-threading and whatnot. But I don't know. What would you add to that, James? 

[0:13:05] JI: Just to go into more technical detail, one option that the navigation libraries provide is for developers to use the actual true navigation components provided by Android, provided by iOS. They're not replicas. They are exactly - that means that when you update your phone to the next version of the OS, oftentimes in the fall, if there are subtle changes, those changes just get applied to users running the newest version of the OS with your app. And that means that we're not trying to maintain parity. It already takes a lot of work to make something look pixel perfect. But it takes even more work, sort of to use the iceberg analogy, how an app looks is the part of the iceberg above the water. How it behaves is the part below the water. And that's so much more complex. You can't just like look at it. You have to figure out what are the hit boxes for all sorts of different components, gestures, animation curves. Things that no one really wants to replicate. And rather than spend all of our time trying to figure that out, why don't we just use those components? Why don't we make Expo the easiest way to use the components provided by the native operating systems? 

[0:14:10] KB: I'd love to hear what abstraction you build around that for the developers. Because I agree. Navigation is one of those places where it's not just the UI that looks different. The mental models are different, which is I think why somebody who's a long-time Android user, if they're using something that was cross-platform developed and developed by somebody whose mental model is more iOS, they're like, "This is wrong. This is just wrong." How do you expose those underlying differences in model to the developer building these applications? 

[0:14:41] JI: A lot of it is just provided by using the native navigation controllers. However, our difference is Android really has this concept of going back. And that's all handled by just keeping track of more of a global navigation stack. But, yeah, a lot of this is just handled by the system already. 

I would say, just kind of to add to this, one thing that Epxo brings to iPhone and Android apps is the concept of URLs. Really being a first-class citizen rather than second-class. On the web, every page has a URL. That's just normal when you build a website. The URL is really a first-class concept. On mobile platforms, just for historical reasons, URLs kind of were added on later. Phones got the ability to be able to handle URLs through things like deep links. But you have to write extra code to handle these URLs. 

What we want to do with Expo, and we've done this with the Expo Router, is make URLs a first-class concept. Bring together the best of the web with the best of native mobile platforms. And there are a whole bunch of benefits that fall out of this. One is that, when you write an application, you don't have to think about adding deep link support. It's just built in. Because every page by default has a URL. 

Kind of going back to your original question. What we want to do is actually figure out how do we take these awesome system integrations that Android and iPhone have if you were to add support for deep links and just make that be the default out of the box when a developer uses Expo Router. 

[0:16:15] KB: I'm curious on that. As you say, in the web, URLs are a first-class citizen. Some of the Frameworks have really embraced that and used that as saying URL then drives your state that you're fetching. And, therefore, you can derive everything from that URL. Whereas other JavaScript application frameworks have sort of not been as key there. I'm curious, does your router then tie into your data layer in some way? Or are those kept separate? 

[0:16:39] JI: The data layer right now is fairly unopinionated. It is something that we are working through and developing, especially with React server components becoming more of story for React. And, also, separately as local-first apps is kind of like more of a trend as well. We want to be able to support both of those definitely. 

Yeah. For the most part, we just take kind of a more URL and page-centric approach. And while pages get rendered, there are ways to sort of say I want to - it's currently very experimental. But do React server component logic or have an async component that does the data faction. But it's very integrated with React I would say. 

I think that is an area where we're going to have to explore some more over time. And so, for now, we've been fairly unopinionated about that because we just want people to use whatever data fetching library or maybe not even a library. Call the fetch API and should work. But over time, I want to kind of provide some more opinions around that. So that in addition to sort of being like - to use the analogy of Next.js, to also be more of like a Rails as well. 

[0:17:44] KB: Diving in a little bit. You mentioned you like to give escape hatches. And the Rails reminder is a good reference because they did a great job of this, especially as they matured of like, "Here's the defaults for everything. But here's how you escape. Here's how you sub something in." What does it look like to bring in something that's not already an Expo API but, say, you want to integrate a third-party package or you want to build your own approach to some particular piece of this? How do you approach that within Expo? 

[0:18:09] CC: Yeah. The primary mechanism to do that is with what we call modules, specifically native modules. Let's use the example of like a native API that Google or Apple just added in the latest version of the operating system. And developers want to use it right away. And we believe as a principle, it's really important. It's just really empowering actually when developers are their own bottleneck. They're not waiting for the Expo team to build a feature. They're not waiting for Meta to work on React Native for a new future. Developers are their own bottleneck. 

And to a large degree, modules, we have a whole spec called like the Expo Module Spec. It's all documented on how to write modules and different types. That allows developers to define a module that calls into some native system functionality and expose it to JavaScript and have a bidirectional channel so that JavaScript can call the native code and native code can send events back to JavaScript. This works with not just system capabilities provided by Google and Apple, but really any third-party API that might be written in native code. That's a lot of the surface area here. 

[0:19:13] CC: Yeah. One thing that I want to call out that we put a lot of work into there is we sort of developed this technique in concert with Expo modules. We call it CNG, continuous native generation. It works with something called config plugins. Maybe the easiest way to describe this is if you think back to like before package manners are really good for things like JavaScript and whatnot, if you want to use any kind of like C++ code and something, you often were like following three pages of instructions and installing lots of random build tools on your computer and hoping you had the right kind of computer that the person who wrote the instructions had. 

And then the worst case ends up being you're doing multiple of these things and they're relying on conflicting versions of stuff. And they're stepping on each other's toes. And you're being told to edit one config file. And another thing tells you to edit in a different way. But you aren't sure how to resolve this. And you can see there's so many gnarly problems as you go deeper and deeper and deeper into that rabbit hole. 

And so, with config plant and CNG, we basically made it so that if you follow the spec and you implemented a config plugin for your native module, then you can just kind of add one line to your config file. That's similar to adding in your package.json and like Node project. And when you install it, what we'll do is we'll actually generate the iOS and Android project directories with all the native code there. 

And the implementation of a conflict plugin basically is sort of like a script that sets up and modifies things like your app delegate and your POS files on the iOS side and your XML files on the Android side. And does all these sorts of annoying, tedious, easy to screw up and/or easy to conflict with something else type things. And so, we have those automated. It actually has some of the same properties of what makes React really great where it's kind of like you sort of make the changes at the fundamental abstract level. And then the system kind of takes care of making sure that the whole world ends up in the right place for the user. And as you change sort of the fundamentals, the regeneration happen sort of as a render. And that means that it's a lot easier to use these things and a lot easier to use a bunch of these things and concept with each other without having to go dive into all the details and keep track of a bunch of stuff in your head and have this very fragile codebase because it's kind of like constantly being regenerated from these sort of first principles. 

I think that's one of the things that is - there are a bunch of little random things like that that are kind of two levels below the surface. And so, if this weren't a software engineering podcast, it would be hard to explain that or get your head around. But those are the kinds of things that I think why the people who really like Expo and are big fans and longtime users, classes of problems that go away. You can put your mental energy and your time into making the app you want to make. Rather than going on side quests to sort of solve annoying problems that aren't even programming problems or really the fun kind. But the more Google a bunch of stuff. Try a bunch of stuff until it finally works. And you're sort of like, "I'm not sure why. But nobody touch this, please." That's never really fun.

[0:22:15] KB: Absolutely. And that actually feels like a nice entré into - Expo is this free open-source framework that handles a lot of these problems. But y'all are a for-profit company as well. And you offer the Expo Application Services, which make a whole another set of those challenges go away. Can you talk a little bit about what those services are and how they relate to the core development framework? 

[0:22:40] CC: Yeah. The most popular one that we have that a lot of people use is what we call EAS Build. Or our build service. And that basically just runs XCode and Android Studio in the cloud for you. 

[0:22:53] KB: Wait. I don't have to mess with installing Android build and Xcode to build a native app anymore? 

[0:22:58] CC: Yeah. And so, there's a whole bunch of reasons that's really good. One is, if you don't have a Mac, you can't do Xcode. For people with Chromebooks, for people who are like maybe developing in web browsers at school or for people who are on a cheap Windows laptop or things like that, this is one of the only ways they can actually - I mean, you could - 

[0:23:18] KB: I'm sold. Sign me up.

[0:23:20] CC: Yeah. A big part of what we do I think is making really good mobile apps accessible to this really big community of people that are basically web developers or React developers or people with sort of that skill set. And sort of shield them, for the most part. Although, if you want to make something perfect, you usually do end up having to dive below the surface. But mostly, shield them from having to deal with annoying, gnarly stuff about building and whatnot as much as we can. 

And so, Xcode and Android Studio are both multi-gigabyte, giant downloads that often take a while to download. Xcode, for whatever reason, often takes forever to download from Apple servers. Android Studio has these sort of multipart things you download in Studio. But then you're downloading the specific images for all the different operating systems and things like that. 

And then if you're not somebody - this is especially a big deal for peripheral developers on your team who might be not doing native iOS or Android stuff on a daily basis. And so, they maybe come back every eight weeks to one of these things. And then this is kind of like - this happens to me with my PlayStation, where like I play it twice a year. And every time I do it, it's like, "Oh -"

[0:24:26] KB: You got to do an hour of updates and all. Yeah. 

[0:24:28] CC: Before you can get going. And the same thing happens to people on your team with Xcode and Android Studio. Having it like properly configured in the cloud on really fast servers that are sort of set up to work with Expo projects really well just saves a bunch of headaches. And then there's also stuff where you're like when people are doing automated stuff, it's often, "Well, whose computer are we going to run that on?" We're not going to tie Kevin's computer for however long, blah-blah-blah. And so, it's just nice to have like a Cloud that you can do that stuff on. 

We can also do some other cool stuff where we can just build for you. And then you can download it. And you can do whatever you want with it. But since we already have it on our servers, we can also do stuff help you submit it to the app stores without having to download and then re-upload through whatever process. But just kind of we have a service called EAS Submit that is actually free. But just helps people with that annoying step. 

And then when you make builds, we can help deliver them to other people. One thing we're working on and improve - this is a product that we have some parts of, but it's not fully where we want to be, is helping everyone in your company, or your project, or your team, or whatever get specific version of stuff onto their device with the web. These great services like Netlify and Vercel. You can get Kevin - 

[0:25:48] KB: This dev build. That dev build. Absolutely. 

[0:25:50] CC: Yeah. And in this way that's accessible to the marketing person, to the intern, to the product manager, to the CEO, or anybody on your team. It doesn't have to be who's super savvy. And so, it's a bit of a gnarlier problem on mobile because there's things like provisioning profiles and certificates. And things work different on iOS and Android. And you have to deliver native code builds. And there's a bunch of gnarly things there. But I think we're sort of bit by bit working towards like as seamless and easy as an experience for doing that kind of stuff as well.

One other thing I would throw out there when I'm talking about the build service is we also did build it as - I talked about how it's like specialized for Expo apps and works really well with those. Actually, we try to build everything in this way where we build it in a very general way to begin with. you can actually run kind of anything using EAS Build. You can kind of build anything. It doesn't even have to be like a React Native app basically. 

But, then, we put layers on top of it. If you are using Expo, if you are using our standard suite of stuff, et cetera, your life just keeps getting easier. Because we sort of say, "Hey, a lot of people are going to be doing this. Let's put other affordances in here." But we try to not over-specialize. Because sometimes people - we just find developers want to do all kinds of weird stuff. And it's so common that a company has some - like, "Oh, we have to use this because we signed a long-term deal five years ago with a previous CTO. Or our VP of eng is just friends with this person." Or for whatever reason, we have to use this or that. And that means that X, and Y, and Z have to be this weird way. 

And so, we just want to make sure that we're always supporting that and giving people escape hatches. But, also, knowing that it's really important to take somebody who's just like - after you record this podcast and you have 45 free minutes, how can we get you as far along building your to-do list app, or your pictures of anime scenes, or whatever is interesting to you. How do we get you so far that you can experience something? We sort of call that fast-forward principle internally. 

And I think it's actually super important. Because a lot of the success stories that we hear are versions of something like this, where I lunched a while back with a team and they basically said we're making sort of a meal kit delivery service. And so, our priority is that. We don't have a very big developer team. And so, we thought that we could only afford to make a website in terms of developer bandwidth, and bodies, and resources, and whatnot. Because it just seemed hiring an iOS team and an Android team and keeping those things in sync would be way too much. 

But then one of our developers discovered Expo. And over the weekend, put together a prototype of what an app might look. And they got so far along just over the weekend that when they showed the CEO on Monday that it worked on iOS and it worked on Android. And that they had like already built out more than half of all the screens we would need. And that the same developer team who is already building the website in React could maintain this app and stuff. All of a sudden, now we have these native apps that we just didn't think we possibly could. And so, helping people like stay on that easy path and go really far and glide really fast feels really important to what we do. 

[0:29:00] KB: I love that. And I'd love to dive into a little bit of what that learning journey looks like. But first, I'm curious in this particular type of example. Say, you have a React website. You've built it not knowing anything about Expo. And you suddenly discover Expo and you say, "Hey, I want a mobile app." What does it look like to kind of retrofit? Or are you building from scratch and just replicating screens? What is that process look like there? 

[0:29:24] JI: Being able to just take your React website and have it work, create native user interfaces everywhere is like the dream. And maybe that means you still have to like go dive into the Android and iOS-specific code bases and tune them. But to just have something working would be amazing. That is directionally. Certainly, an aspirational goal. 

Where we're at now is that some of the code would work. However, I would say it's the concepts that really transfer over. And, also, yeah, parts of the code as well. Specifically, React code that is not coupled to React DOM. A lot of that would potentially carry over. Also, code like JavaScript or TypeScript code that does not rely on DOM or browser libraries. Just say something like Lodash I think was a really good example of this. Although, a lot of that's been like subsumed into the ECMAscript standard now. But those types of libraries, they do carryover. 

I think the biggest thing though that carries over is a team's knowledge expertise. The familiarity with React. The mental model of structuring your app in terms of these components, a lot of the data fetching strategies, those do carry over. However, as you mentioned earlier, it's nice to talk about differences as well. And there are many differences. 

With native mobile applications, one key difference is that, typically, mobile applications are installed on a user's phone. The expectations are that they launch extremely quickly. That they are available offline. Whereas on the web, typically, you assume that the user has a very good internet connection. And, otherwise, they wouldn't have been able to load the website in the first place. Setting aside a couple of offline PWAs. There are differences in the Meta model too. 

However, going back to similarities, you would be able to take a lot of your React knowledge. And several companies, what they do is they break their code base out into shared pieces. And then over time, if they so choose, they may even gradually migrate their website to use technology like Expos web support, which also works with React Native Web is the library, which is giving you a way to call into the React Native API and have that render to DOM components. 

And just to give shout outs to a couple of projects in the space, specifically from Meta. There are two projects. One is called StyleX, which is a way to express styling. That uses CSS on the web. But also uses kind of React Native compatible styling libraries for Android and iOS. And other is called Strict DOM. React Native uses a lot of components called like view, and scroll view, and text view. Instead of doing that, what Strict DOM does is it provides a subset of DOM components. Say, div and span that we're all familiar with. And allows developers to call into those components and have them work on React Native. I would say, overall, the ecosystem is gradually moving in this direction. And it's still like aspirational. But every year, there's more progress in that way. 

[0:32:37] CC: Yeah. Another way I think about it is in stories like the one I told you of this meal kit app. I think when they start out, the code base is probably pretty separate. I would imagine something like 10% to 20% of their code was shared. And it was just sort of another kind of React app but sort of developed in parallel. 

And over time, people that try to share more code can get up to something like 70, 80, maybe 85% over time. And then there's another kind of app that like if you start from the very beginning with this idea of like one code base and using Expo's web support, there are apps that it's basically 100% shared with some specialized stuff that says, "On Android, there's something specific I want that's -" just an Android specific thing. And so, that code, it doesn't make sense to be shared. Because the whole point is that it's specific. 

And so, a great example of that would be like Bluesky, which is this Twitter alternative basically. I'm not sure if that's the way they'd like me to describe it. But it's really cool. It's really live. It's got 10 million users. It feels awesome actually. I use it every day. The IOS app feels really great. It's just like a native IOS app. I don't really notice the difference between it and Twitter. It feels basically just as good to me. Android app feels native. And the website also is really good. And it's all one code base. All started by one guy who didn't even have React experience before. Built it by himself in a couple of months. And now there's a bigger team working on it. And they've published it. And it's gotten a lot better. 

But that kind of product is actually really inspiring to us and really awesome. Because over time, we originally saw that - our original thought was there's two problems. There's iOS and Android. Those are the two problems. And we can collapse those two problems down into one. That'll save people a whole bunch of time. That was true. But then we kept finding that if you go look around, United Airlines is like an app that I end up using a lot. Because they have a hub in San Francisco. And their mobile website is basically the same product as their iOS app. And their iOS app is basically the same product as their Android app. 

And I actually don't know exactly how their whole tech team is structured. But just from looking at it, I'm pretty sure that it's they have one product manager and design team that then farms out specs to an iOS implementation team, a web implementation team, and an Android implementation team. And it's pretty good. I don't actually have any problems with it. I think it's one of the better airline apps. And they do a good job. 

But how annoying is that that you have to have these four groups working at concert? And then these three people not only trying to do their own work, but trying to stay in sync with two other sets of people doing the same work? And if you want to add something or change something, whatever. And then whenever there's differences, then imagine trying to deal with your customer support. And the customer support has to say, "What platform are you on?" They're like, "Oh, that's because this only happens on Android or whatever." And you don't want those differences for 20 different reasons. 

And so, I think there's something incredibly empowering that goes beyond just that first order savings of like, "Oh, we don't have to do it three times." But the automatic keeping in sync and that tightening of that loop so you can iterate faster and you can move faster I think it's just a really big deal for anyone building stuff. 

And another thing that is really exciting to me now is that I start of said, "Okay, we start off with two problems and we collapse them into one." And then we started talking to people and it's like, "Oh, there's actually this third problem, which is web. Now we collapse those two problems in one. And now, with React server components, it's almost like there's this other problem, which is the people - we talked to people about why they use Firebase. Or they used to use Parse. They would say, "Oh, I was told I need to add a checkbox to the email page because we have to let people unsubscribe from all emails." And so, I went and implement the check box. But then I had to file a ticket with the backend team to add to their next Scrum sprint that they add a database column and then - blah-blah-blah. And they gave me an API I can call. But I just needed to get this done because the CEO told me to. I just decided to store it in Parse or in Firebase in the cloud and just directly call into it. 

And so, you can see that there's this thing where if backend and frontend are separated, you're breaking the tightness of the loop and it's really inefficient. And so, we're really excited about people use JavaScript and servers now. And so, letting you write this all as one codebase. That's sort of like one team can tackle and balance - and so, sort of shipping the org chart becomes less of a problem because the whole org is working on the whole product in a very holistic way and concert. 

[0:37:01] KB: Yeah. I feel like we're definitely trying to move in that direction. And there's a variety of things leading towards the ability to just kind of have the same people. It's all one product. Let's have them all working together. Love it. Love the direction. I'm curious then, if someone's wanting to get started building with Expo, what does the learning journey look like? Where do they get started? What are the most common gotchas or rough edges? How should somebody who's interested, who's listening, has never touched Expo, what do they do? 

[0:37:30] JI: Well, we have this new website called expo.new, which is designed to be the landing page for people who want to just start building a new application. Actually, Charlie worked most closely with a lot of engineers on this project. You can probably give the best description of how this works.

[0:37:48] CC: I think it's not too different than creating a React web app in a lot of ways. And that what we are currently most optimized for is basically our developer who knows React and/or at least knows React a little bit or knows enough about it to vaguely be dangerous or run it quickly. And so, you typically will do something like run, create Expo app. I'd recommend you start with Expo Router because I think it really sets you up for success in a whole bunch of different ways. And then with anything, you want to just build something that you'll feel like, "Oh, I accomplished something." And that'll like be motivated. 

Actually, one of the things that's a real stumbling block for people is - one thing that's awesome about the web is that if you want to teach a kid to make a website, they already have the web browser on their computer. And so, if they make an HTML file, they can just open that in their web browser. And you can get them into this thing where they're making changes and seeing them happen and all this other stuff without having to go follow many pages of instructions to install this and wait for that, et cetera, et cetera. 

A tricky thing about mobile is that, first of all, you've got multiple devices. You're usually typing on your computer and writing your code on there. But then the real experience, you probably want to have on your phone. Because gestures and animations are so important. And maybe you need to use the camera. There's all these reasons that like being on a phone is good. 

But to do that, you generally need to have a build. And so, then that's one way that EAS Build comes in handy is that we can at least do a build for you and sort of get you going pretty quickly that way. And so, if you go to expo.new, you have a bunch of different options. But a lot of the flows will take you to sort of use EAS build. And we have a free tier. So you don't have to crack open your credit card or whatever right away. But you can do a build and get it onto your iOS device or your Android device. And so, you're not just limited to developing the web browser to start. 

We also have a middle ground option, where if you're only using modules from the sort of standard library or our Expo SDK, you're talking about you're not using any custom native code, which is most things that get to be real production apps need some custom native stuff to be exactly what they want to be. But a lot of things can get pretty far without doing any custom native stuff. 

Especially at the beginning, one thing that people like to do is use this app that we put in the app store called Expo Go, which is sort of development browser for native. You can't go browse other stuff with it because Apple doesn't really allow that. You can open your own projects basically the way that you might open a web browser. You can scan a QR code that that comes up in your terminal and it'll just open up your code base. Bam. Keep going. 

And so, this is awesome for a bunch of reasons. If you find an example project for a shopping list app or something that somebody's put on GitHub, you can just clone that. Then fire it up. And then open an Expo Go and skip that process of doing a build. And so, if you just want to check something out quickly - if you're putting your app in the app store that's going to reach 20 million people and it's going to make you millions of dollars than waiting 15 minutes or 10 minutes for a build, no big deal. But if you're just trying to check out a project and see how it's built and like you only have 10 minutes in between meetings, just being able to open something in Expo Go really, really quickly is actually a big deal. 

We try to give people a lot of options along the way to just speed up their journey in different ways while also trying to balance that with trying to have one fairly straightforward path so that people don't get kind of in the way that Rails keeps you on Rails. But lets you go off in different directions. We're inspired a lot by products like that.

[0:41:17] KB: Question about Expo Go. And this ties a little bit. I saw one of the service offerings you have is things that are JavaScript layer updates. You can help somebody using the Expo application services to ship things live over the web. But things with native updates need to be deployed through the app store as updates. Does Expo Go have those same limitations? Or is it able to give you access to a project that has custom native pieces? 

[0:41:42] CC: Yeah. Basically, the same limitations. You can think of Expo Go as just an app that has all of the Expo modules in it and nothing else. And so, if you want to use anything else, either it has to sort of degrade. And, say, maybe you have a black rectangle where it's just like this just doesn't appear here or whatever. Or it just doesn't work and you just have to do it. We have a solution there as sort of a middle ground that we've been pushing people more and more to. Because I think, for a lot of situations, it's sort of a best of both worlds type of thing. We'll make something call - or you can do this locally on your own machine if you prefer. We'll also do this in the cloud for you if you like. But we call them development clients. 

And that's basically sort of like your own version of Expo Go just for your app with whatever modules you need. And, also, your app's icon and whatever other kind of like weird operating system-level things. If you're using Apple Pay and you have to have certificates fixed in there or whatnot. You can make sure all those things are right in a way so that it actually is a much closer experience to what your app is going to be like when it enters the app store and things like that. 

And one of my core beliefs as a developer - I don't know. Core beliefs is a little strong. But one thing I believe as a developer is just you always want to have your development environment be as close to production as possible. Because whenever there's differences, there's a potential to come back and bite you. And so, the thing we really like about development clients and the reason that we prefer them, and we've been nudging people in that direction instead of telling them to use Expo Go, is just because it gets you 70% closer to production than hand-waving at that number obviously. But they're just a lot more close to production than Expo Go is. 

And then the one big downside is that you have to do a build. And so, either you have to have a computer and it takes some time. Or you have to do in the cloud and it takes a couple of minutes. And if you're in a big hurry or you're just trying to teach somebody how to use Expo, you're trying to get a whole class of 20 students or something like that, Expo Go is great for that. Because they can download from the app store. It's very straightforward. And if you don't need any custom native modules, then it's like a very generalized, generic, limited development client basically. 

[0:43:49] KB: Well, we've talked about a bunch of different stuff. And you sort of hinted towards things that are going to connect to this sort of closing question. But looking forward at the next year or couple of years, what's coming next for Expo? What are the things that you're really excited about that are on the horizon? I know we've talked about some things that are like the long-term vision. And that's great. But if somebody's looking at this and saying, "Okay, what's going to be there in 2025? What do I have to be really excited about?" What would you call out? 

[0:44:19] JI: We've got several things. But kind of to touch upon some topics that we've talked about earlier during this podcast, one is React server component. The idea of rendering some of your components on a server. And not just with server-side rendering. But rather, components that can directly call into server-side APIs. Potentially, they're calling directly into a SQLite or PostgreS database. Maybe they're making a call into an AI service with private keys. Or you're looking at processing payments through something like Stripe for instance. 

These are all instances of code that needs to run on the server. And being able to kind of more cohesively put that code with your React code is one of the things that React server components lets people achieve. That is one area of focus. And we want to provide a whole solution for developers to be able to, yeah, take advantage of React server components across all the platforms we support. 

Another kind of more on the development side is Charlie had talked about how we have this fast-forward principle at Expo. The idea that we want to build general, very powerful infrastructure that has really high ceilings. And then on top of that, we want to build solutions that let developers fast forward past all that complexity when they don't need it and provide really good defaults. 

Going back to having a really generalized base infrastructure layer, that allows us to provide services more than just builds. And so, what we want to do is allow developers to run - bring their own tasks. Self-host your own kind of CI/CD pipeline as part of the whole structure. We've heard stories from many developers who will run some of their CI/CD on one service. And then they call out to EAS to do their builds. Meanwhile, their other CI/CD service is just waiting for the build to finish. And they've almost just begged. Said, "Can we please just run everything on EAS?" We think that is just a natural evolution of some of our build infrastructure as well. Those are two concrete things that I think developers can look forward to in the next year.

[0:46:28] CC: The one thing I'd add to that is just we really are making good progress towards that dream that we're talking about where we're really unified with web. And web developers can come over and just get going right away and be using so many of the things that they're familiar with. But getting native components out of it. So that when they're writing stuff that feels familiar to them, they're just getting a native app on iOS, a native app on Android. I think we won't fully get there in 2025. But we're going to make some big leaps towards it.

[0:47:00] KB: Amazing. Well, this has been super fun. I've really enjoyed diving into this. I have never tried actually using Expo before. But I am excited to. As I said, my mobile days date back to like Cordova and dealing with things in that space. And I've been pretty web-focused recently. But this sounds like a great toolkit. And I'm very jazzed by the stuff you're doing. 

And unlike a lot of companies that have an open source component and a services component, your services make so much sense for building in this ecosystem. They don't feel tacked on. They feel like, "Oh, it makes sense why you're offering this and why it costs money." Because it requires infrastructure. Just super cool stuff. Any last thoughts you want to leave folks with before we wrap up? 

[0:47:46] JI: One thought I have is that we really want to work together with a lot of others. Of course, that can include engineers like joining Expo. But, also, at other companies and partnering together. It's going to take a lot of companies, people working together to build the new default way to make software that just works everywhere. If any of the listeners work at companies where you think it might make sense to team up and partner with Expo, yeah, we'd love to do that. 

[0:48:10] CC: Yeah. And kind of in the same vein, I was just going to tack on a shout-out to the 1600 open-source contributors that fill out the dark corners of the project where they run into a bug, they run into something gnarly, and they fix it. Send a PR to us and we incorporate it. That makes the project so much better. Thankful to have the community participating and making this really good.

[0:48:35] KB: Awesome. Well, Charlie, James, thank you so much.

[0:48:39] CC: Thank you so much for having us. 

[0:48:40] JI: Thank you, Kevin.

[END]