Streamlined React Native Development with Charlie Cheever and James Ide

0:00Expo is a development framework that streamlines the process of building cross-platform mobile apps using React Native. It eliminates the need for 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 Eide 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.

0:39He 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.

1:07Hey guys, welcome to the show. Hey, thanks for having us. Yeah, excited to have you on this. So let's get started and maybe have each of you introduce yourselves briefly and then we'll get into the meat of the show. Charlie, do you want to go first? Yeah, sure. I'm Charlie Cheever. I grew up in Pittsburgh, Pennsylvania, studied computer science in college and I 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, actually.

1:40Nice. And James? Hi, I'm James Ide. I've been working with Charlie for over a decade now on Expo. Similar feelings, like it was 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 what Expo does. So it's been a great journey so far. Yeah. So 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. 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.

2:19and how do we make it so that like it's as easy and as fast and efficient as possible to build that at like the highest level of quality that you actually want to achieve and specifically like the modern version of this problem involves attaching to like a bunch of services mainly like 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 like we try to balance like trying to you know we really start from this one code base philosophy so you have one engineering team working on one code base we also try to balance that with respecting each platform and its differences and sort of making sure that we're you know it feels native to each platform and it is native as much as we can possibly do it would you add anything to that james 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 code base at the same time when building for, say, an iPhone, we want to be able to use the iPhone's native user interface capabilities.

3:20It'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. So we want to have native apps. We'll also have a universal code base that one team can work on. And so that way, like a product manager or designer doesn't need to go talk to the Android team and iPhone team and the web team, they can just talk to the accounts team or the user profiles team and have one conversation.

3:56So the product is very coherent, we'll still have native apps for each respective platform. For an old timer like me, this sounds like what phone gap and that which became Cordova was trying to solve. Are y 'all kind of similar to that? Or how would you describe your relationship to that project? I think that like a lot of what we wanted to do was born out of frustration with those, where there were 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. It doesn't have a lot of the little details that make using our phones like delightful in a lot of ways.

4:35I mean, you could see this where I think like a while ago now, but there was, I remember a TechCrunch article where the headline was like, you know, Mark Zuckerberg announces biggest mistake Facebook has ever made is building its mobile app with HTML5, is ditching that and rewriting everything in native. And like, that was going to be a little bit overblown. And I think there are times and places where, you know, HTML is a perfectly fine way to render stuff, especially as phones get faster. But there are lots of things where like, it just doesn't feel right or native to the platform in a mobile context if you're not using the operating system of the 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.

5:12And I think the thing that we really believed that we had to push hard on to build was this that like, we believe you could use technologies like JavaScript and things like that and achieve this, but that all the layers of, you know, accumulated backwards it's compatible standards-based stuff that had built up in the browser over time, the implementations of, you know, mobile Safari and Chrome as it was at the time. And it's still to this day, they just weren't quite delivering the experiences people wanted. And like, I mean, just, you know, you can still see this where people just complain about not native apps and just like, 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 our qualitatively, our users didn't really like it.

5:59Our stars in the app store and our, you know, just feedback was worse. And also just quantitatively, we just saw, you know, 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. So we just wanted to solve that for ourselves as much as anything else. Like I, I really just, you know, 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 you know an app on ios an app on android because that's how people use technology like if you think about how often but just like how you probably if you look at your own behavior like obviously there was just this you know when blackberry came out and then especially when the iphone came out and etc 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 like 10 times as many web developers as mobile developers, when our usage is now tilted probably like 70 % to mobile as human beings.

6:59So a big part of what we're trying to do is just sort of correct that imbalance of like, this is how people show us they want to use software. But still, as developers, we all like, you know, 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 like, how can we make the tooling and mobile match that? Yeah, that makes sense. So, 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.

7:27Looks like you're building largely on top of React Native on the sort of the development experience. Yeah, I would say Expo kind of sits adjacent to React Native. It complements it. So 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 of the developer experience that you'd want when using the react native technologies so 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 yeah it's a pretty good analogy people use that a lot.

8:15It's not absolutely one-to-one matchup 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. So 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? 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 widgets and things that you need are available already. Whereas one of the big efforts that we put in is building what we call like the expo sort of sdk or standard library where we you know built like something like over 90 apis that just are standard across ios android and in most cases web and just kind of are well tested valid tested work across these things and importantly like work with each other and so you can kind of just like trust that these are well maintained and the apis are going to feel similar and look similar and like 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 like 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 you know sometimes people talk about it's like batteries included or whatnot and just makes it like so much like 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?

9:36What if I want to have vibration? What if I want to play a video? What if I want to, like, there's so many things like that, that just like every individual developer was sort of having to work out those details on their own in a lot of cases. And then across mobile platforms and just having that, I think is probably the biggest difference where I think like the web has, you know, on its own evolved a lot of that. And so the Next.js doesn't necessarily have that responsibility in this great a way. Yeah, that makes a ton of sense. So kind of providing not just the application framework layer, which is what Next is really focused on.

10:06It'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? Yeah. But, you know, just to call out some ways that things are similar, like I think one thing that Expo solves that Next also solves is sort of like this routing problem of like, okay, how do I take a URL and then map that to like a screen or some logical component of our application? And then how do I deliver those to people and organize them in my code base and also in my app and whatnot?

10:40And ExoRouter 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. You know, 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 like URLs to screens, 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 like web browsers on your computer. Where like on a web browser on your computer, you might have multiple tabs, but if set that aside from like you have a URL bar and then you kind of have one screen.

11:19Whereas in mobile apps, what we're used to is kind of like typical sort of app is, you know, a tab bar at the bottom that each sort of is its own kind of like a browser tab with its own stack and whatnot. But there isn't necessarily a URL bar. You just kind of like vaguely know that like the home tab of Instagram and the explore tab of Instagram and the profile tab of Instagram all have their own sort of navigation stacks. But the other thing is that like, 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.

11:51And 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, like I can tell the difference between a true native app and like something built with, you know, 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, you know, see if there's some little tick there.

12:26So it's one of the things that people are somehow, for whatever reason, incredibly sensitive about. So 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 having access to the source code or something like that. There are some rough edges. 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 Expo app, it feels at least as good, perhaps even faster in some cases because things we can do with multithreading and whatnot.

13:03But I don't know. What would you add to that, Jens? 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. So 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, like sort of to use the iceberg analogy, how an app looks is the part of the iceberg above the water.

13:46How it behaves is the part below the water. And that's so much more complex. You can't just 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 be the easiest way to use the components provided by the native operating systems. 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.

14:19The mental models are different, which is, I think, why somebody who's a longtime 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. So how do you expose those underlying differences in model to the developer building these applications. A lot of it is just provided by using the native navigation controllers. However, some of it, like there are differences, like Android really has this concept of going back and that's all handled by just keeping track of like more of like a global navigation stack.

14:56But yeah, a lot of this is just handled by the system already. I would say that just kind of to add to this, one thing that Expro brings to iPhone and Android apps is the concept of URLs really being a first class citizen rather than second class. So on the web, every page has a URL. That's just normal, right? When you build a website, like the URL is really a first class concept on mobile platforms. Just for historical reasons, URLs kind of were added on later. Phone's got the ability to be able to handle URLs through things like deep links, but you have to write extra code to handle those URLs.

15:34What we want to do with Expo, and we've done this with 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. So kind of going back to your original question, like what we want to do is actually figure out how do we take these like awesome like 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.

16:14I'm curious on that. So 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 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 like local first apps is kind of like more of a trend as well so we want to be able to support both of those definitely and yeah so for the most part like we just take kind of like a more url and page centric approach and while pages get rendered like there are ways to sort of say i want to it's currently very experimental but do like react server component logic or have an async component that does the data fetching, but it's very integrated with React, I would say.

17:20So 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, they just call the fetch API and should work. But over time, I want to provide some more opinions around that so that in addition to sort of being like, to use the analogy of like Next.js, to also be more of like a Rails as well. Diving in a little bit. So 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.

17:55Here'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? Yeah. So the primary mechanism to do that is with what we call modules, specifically native modules. So 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 this we believe as a principle, it's really important. It's just really empowering, actually, when developers are their own bottleneck.

18:32They'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 feature. Developers are their own bottleneck. And to a large degree, like modules, we have a whole spec called like the expo model 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.

19:11So that's a lot of the surface area here. 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 ExoModules. we call it CNG for continuous native generation it works with something called config plugins that like maybe the easiest way to describe this is that like if you think back to like before package managers were 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 like hoping you had the right kind of computer that the person who wrote the instructions had.

19:53And 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 convict 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 Conflict Plugins and CNG, we basically made it so that if you follow the spec and you've 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 like adding in your package.json and like a node project.

20:29And 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 config plugin basically is sort of like a script that sets up and modifies things like your app delegate and your, you know, plist files on the iOS side and your XML files on the Android side and does all these sort of like annoying, tedious, easy to screw up or easy to conflict with something else type things. And so we have those automated. It actually has like 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.

21:06And 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 happens sort of as a re-render. And that means that like, it's a lot easier to use these things and a lot easier to use a bunch of these things in concert with each other without having to go dive into all the details and keep track of a bunch of stuff in your head. And, you know, have this very fragile code base 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 like, there are a bunch of little random things like that, that are kind of two levels below the surface.

21:40and so like if it was born 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 long-time users like classes of problems that go away so you can put your mental energy and your time into like making the app you want to make rather than like going on side quests to sort of solve you know annoying problems aren't even programming problems are really the fun kind but the more like 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.

22:13Like, that's never very fun. Well, and that actually feels like a nice entree into, so 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 nother 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? Yeah. The most popular one that we have that a lot of people use is what we call ESBuild, our build service. And that basically just runs Xcode and Android Studio in the cloud for you.

22:52So wait, I don't have to mess with installing Android build and Xcode to build a native app anymore? Yeah. And so there's a whole bunch of reasons that's really good. One is like, if you don't have a Mac, you can't do Xcode. So like 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 i'm sold like sign me up yeah like a big part of what we do i think is making really good mobile apps accessible to like this really big community of people that are like basically like web developers or react developers or people with sort of that skill set and sort of shield them for the most part, although, you know, 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 like annoying, gnarly stuff about building and whatnot as much as we can.

23:45And so, you know, Xcode and Android Studio are both, you know, multi-gigabyte giant downloads that often take a while to download. Like Xcode, for whatever reason, often takes forever to download from Apple servers. Android Studio has these sort of multi-part things where you download it in the studio, but then you're downloading like the specific images for all the different operating systems and things like that. And then if you're not somebody like, this is especially a big deal for like peripheral developers on your team who might be like not doing, you know, native iOS or Android stuff on a daily basis.

24:16And 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 like twice a year and every time I do it, it's like, oh, before you can get going. And it's the same thing happens to people on your team with ExpoDenter Studio. So having it like properly configured in the cloud on really fast servers that like are sort of set up to work with Expo projects really well is just like saves a bunch of headaches. And then there's also stuff where you're like, when people are doing automated stuff, it's often like, well, whose computer are we going to run that on?

24:51Like, we're not going to tie up, you know, Kevin's computer for however long, you know, 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 like help you submit it to the app stores without having to download and then re-upload through whatever process, but just kind of, you know, we have a service called EA submit that is actually free, but just helps people with that annoying step.

25:20And then we can also, you know, when you make builds, we can help deliver them to other people. Like one thing we're working on and improve like this is a product that we have some parts of but it's not fully where we want to be is like helping everyone in your company or your project your team or whatever get a specific version of stuff onto their device you know with the web these great services like Netlify and Vercel like you can get kevin. This dev build that dev build absolutely and like 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 someone who's super savvy.

25:59And so we have, 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 like, there's a bunch of gnarly things there. But I think we're sort of bit by bit working towards like, as, you know, seamless and like 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 services. We also did build it as I talked about how it's like specialized for Expo apps and works really well with those.