← Software Engineering Daily
Software Engineering Daily
Streamlined React Native Development with Charlie Cheever and James Ide
00:50:37
Expo 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,...
Loading summary
Transcript58 lines
- [00:00]
Kevin Ball
Expo 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 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 K. Ball, 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 K. Ball on Twitter or LinkedIn or visit his website, K Ball LLC.
- [01:07]
Host
Hey guys, welcome to the show.
- [01:09]
Charlie Cheever
Hey, thanks for having us.
- [01:11]
Host
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?
- [01:20]
Charlie Cheever
Yeah, sure. I'm Charlie Cheever. I grew up in Pittsburgh, Pennsylvania, Studied computer science in college, 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.
- [01:41]
Host
Nice.
- [01:41]
James Ide
And James, hi, I'm James Ide. Yeah, I've been working with Charlie for over a decade now on Expo. Similar feelings, like it's just kind of like 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.
- [02:03]
Host
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?
- [02:11]
Charlie Cheever
Sure. I think like at the highest level it just starts from this thought of like basically what James is saying where like people have an idea of something they want to build and how do we make it so that like it, 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 surfaces, 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 is native as much as we can possibly do it. Would you add anything to that, James?
- [03:06]
James Ide
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, 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. 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, say a product manager or 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. So the product is very coherent while still having native apps for each respective platform.
- [04:02]
Host
For an old timer like me, this sounds like what phonegap 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?
- [04:12]
Charlie Cheever
I think that 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 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, 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 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 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 just that we believed you could use technologies like JavaScript and things like that and achieve this, but that all the layers of accumulated backwards compatible standards based 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. And 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, 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 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 our, I think for ourselves as much as anything else. Like 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 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. So 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 new 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?
- [07:17]
Host
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. Looks like you're building largely on top of React Native on the sort of the development experience.
- [07:34]
James Ide
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, expose it 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.
- [08:04]
Host
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?
- [08:13]
Charlie Cheever
Yeah, it's a pretty good analogy. People use that a lot. It's not absolutely one to one, not match up perfect, but in like broad strokes, like I think that makes a lot of sense for getting your head around it. It's a good way to explain it.
- [08:23]
Host
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?
- [08:30]
Charlie Cheever
One thing that jumps out is just that one thing that has been built out over time on the web is just that like 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 like the Expo sort of SDK or standard library, where we 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, battle tested, work across those 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 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 you're zero to getting a product together that works can be way faster when you're not getting hung up on like, 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 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 multiple platforms. And just having that I think is probably the biggest difference where I think like the web has on its own evolved a lot of that. And so the Next JS doesn't necessarily have that responsibility in as great a way.
- [09:59]
Host
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 is 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.
- [10:20]
Charlie Cheever
Yeah, but just to call out some ways that things are similar. 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? Then how do I deliver those to people and organize them in my code base and also in my app and whatnot. And Exo 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. 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, 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 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 for a moment, like 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 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 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, 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. So it's one of the things that people are somehow for whatever reason, incredibly sensitive amount. 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 like, we get to the point where people basically cannot tell that there's an Expo app or not an Expo app without sort of, you know, having access to the source code or something like that. There are some rough edges that, you know, we're not absolutely perfect on this yet, but that's kind of where we're trying to get to, where like if you're using XL 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, Jens?
- [13:06]
James Ide
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, all 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 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 look at it. You have to figure, figure out like what are the hitboxes 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?
- [14:10]
Host
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 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 like how do you expose those underlying differences in model to the developer building these applications?
- [14:41]
James Ide
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. But 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, 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 those URLs. What 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 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.
- [16:14]
Host
I'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?
- [16:39]
James Ide
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. So I think that is an area where we're going to have to like 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 like 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 like next JS to also be more of like a Rails as well.
- [17:45]
Host
Are your software deployments secure by design? Lately secure by design and shifting left principles have been hot topics in the software industry, pushing development teams to make security a foundational part of software development. Today's sponsor Bitwarden supports developers in securing every phase of the development lifecycle with end to end encrypted credential management. This ensures software is Built on secure principles to prevent data leaks and unauthorized access. Try Bitwarden Secrets Manager, built specifically for developers to safeguard infrastructure and machine secrets, or Bitwarden Password Manager for everyday logins and other sensitive information. Start a free trial today@bitwarden.com 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, 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?
- [18:46]
James Ide
Yeah, so the primary mechanism to do that is with what we call modules, so 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, 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 feature. Developers are their own bottleneck and to a large degree like modules. We have a whole spec called the Xmodel 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 bi directional channel so that JavaScript can call into 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. So that's a lot of the surface area here.
- [19:50]
Charlie Cheever
Yeah. One thing that I want to call out that we put a lot of work into there is we sort of develop this technique in concert with exo modules. 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 before, package managers were really good for things like JavaScript and whatnot. If you want to use any kind of C code and something you often were 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 then 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 plugins 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 in a 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 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 and, or easy to conflict with something else type things.
- [21:32]
James Ide
And.
- [21:32]
Charlie Cheever
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 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 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 code base because it's kind of 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 in your header. 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 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 annoying problems that 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 touched this. Please. Like absolutely never. Very fun.
- [22:53]
Host
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?
- [23:16]
Charlie Cheever
Yeah, the most popular one that we have that a lot of people use is what we call esbuild or build service, and that basically just runs Xcode and Android Studio in the cloud for you.
- [23:28]
Host
And like, so wait, I don't have to mess with installing Android Build and Xcode to build a native app anymore?
- [23:34]
Charlie Cheever
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 curate your own.
- [23:55]
Host
I'm sold, like sign me up.
- [23:56]
Charlie Cheever
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 annoying gnarly stuff about building and whatnot as much as we can. And so 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. You download Android 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. 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 like twice a year and every time I do it it's got to do an hour of updates, right. And so before you can get going. And it's the same thing happens to people on your team with Xcode Android 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? Like, 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 this build for you and then you can download it, 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. We have a service called eASubmit that is actually free, but just helps people with that annoying step. And then we can also, when you make builds, we can help deliver them to other people. Like one thing we're working on and, and improve, like this is a product that we have some parts of, but it's not fully where we want it 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, you can get Kevin this dev build, that dev build.
- [26:26]
Host
Absolutely.
- [26:26]
Charlie Cheever
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. And 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 we're 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. We actually, we try to build everything in this way where we, we build it in a very general way to begin with so you can actually run like kind of anything using AS build. Like you can kind of build anything. Doesn't even have to be like a react native app basically, but then we put layers on top of it. So 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 like say, hey, a lot of people are going to be doing this, so let's put other affordances in here. But we like 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 like 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 you know, our, you know, VP of Manage is 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 like it's really important to take somebody who's just like, you know, after you record this podcast and you have 45 free minutes, how can we get you as far along building like, you know, 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 like fast forward principle internally. And I think it's actually super important because a lot of the success stories that we hear are like versions of something like this where like at lunch 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 like 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 like. 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 already built out like, you know, 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, you know, 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 like, helping people like stay on that easy path and go really far and glide really fast feels really important to what we do.
- [29:36]
Kevin Ball
I love that this episode is brought to you by WorkOS. If you're building a B2B SaaS app, at some point your customers will start asking for enterprise features like single sign on, skim provisioning, fine GR authorization and audit logs. That's where work OS comes in, with easy to use and flexible APIs that help you ship enterprise features on day one without slowing down your core product development. Today, some of the hottest startups in the world are Already powered by WorkOS, including ones you probably know like Perplexity, vercel, Brex and Webflow. WorkOS also provides a generous free tier of up to 1 million monthly active users for user management, making it the perfect authentication and authorization solution for growing companies. It comes standard with rich features like bot protection, MFA roles and permissions, and more. If you are currently looking to build SSO for your first enterprise customer, you should consider using workos. The APIs are easy to use and modular, letting you pick exactly what you need to plug into your existing stack, integrate in minutes and start shipping enterprise plans today. Check it out@workos.com that's workos.com and I'd.
- [30:43]
Host
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, right? 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? Like, what does that process look like there?
- [31:06]
James Ide
So being able to just take your React website and have it work like 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 like have something working would be amazing. That is like directionally so 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. So 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 like browser libraries. So 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 carry over. I think the biggest thing though that carries over is a team's knowledge and 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. You know, set me aside a couple of like offline PWAs. So there are differences in the mental model too. However, like going back to similarities, you would be able to like take a lot of your React knowledge. And several companies, what they do is they, 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 xpos 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 this 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 React native compatible styling libraries for Android and iOS and the other is called Strict DOM. So react native uses a lot of components called like View and scrollview and Text View. Instead of doing that, what Strict DOM does is it provides a subset of DOM components like 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. So 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.
- [34:20]
Charlie Cheever
Another way I think about it is like in stories like the one I told you of this little 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 like 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 if you start from the very beginning with this idea of one code base and using Expos Web support, there are apps that basically, like, 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 real live, it's got 10 million users, and it feels awesome, actually. Like the. 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 polished it and it's gotten a lot better. But that kind of product is actually really inspiring to us and really awesome because, like, over time, we originally saw that, like, our original thought was, like, there's two problems. There's iOS and Android. Those are 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, like, if you go look around, say, like, 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 like 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 in 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 when, if you want to add something or change something, whatever, and then whenever there's differences, then imagine like trying to deal with your customer support and the customer support has to say, what, what platform are you on? They're like, oh, that's, that's because this only happens on Android or whatever. And they're just like, you don't want those differences, like for 20 different reasons. And so, you know, just. I think there's something incredibly empowering that goes beyond just that, like first order savings of like, oh, we don't have to do it three times, but like 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 you know, another thing that like, is really exciting to me now is that like, I sort of said, okay, we start off with two problems and we collapse them into one and then we start talking to people and it's like, oh, there's actually this third problem which is web. No, we collapse all those three problems in one. And now with React Server components, it's almost like there's this other problem which is the people. We talk 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 implemented the checkbox, 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, and it give me an API I can call, but I just needed to get this done, done because the CEO told me to. So 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 back end and front end 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 code base that sort of one team can tackle and balance. And so the sort of shipping the org chart becomes less of a problem problem because the whole org is working on the whole product in a very holistic way in concert.
- [38:43]
Host
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. So 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, like, gotchas or rough edges? Like, how should somebody who's interested, who's listening, has never touched Expo. What do they do?
- [39:13]
James Ide
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. He can probably give the best description of how this works.
- [39:30]
Charlie Cheever
I think it's not too different than creating a React web app in a lot of ways. And that like, what we are currently most optimized for is basically like, you are a developer who knows React 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 like, with anything, like you want to just build something that you'll feel like, oh, I accomplished something, and that'll like, keep you motivated. There's actually one of the things that's a real stumbling block for people is one thing that's awesome about the web is that like, 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 like, you can get them into this thing where they're like making changes and seeing them happen and like all this other stuff without having to go follow many pages of instructions to install this and wait for that. If it's this or. A tricky thing about mobile is that like, first of all, you've got multiple devices, so you're usually like 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 EISBUILD comes in handy is that like, we can at least do a build for you and get you going pretty quickly that way. If you go to Expo new, you have a bunch of different options, but a lot of the flows will take you to use esBuild. 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, your Android device. And so you're not just limited to developing in 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 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. So 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 like development browser for native. Like 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. So you can just, you can scan a QR code that comes up in your terminal and it'll just like open up your code base, bam, keep going. And so like, this is awesome for a bunch of reasons. Like if you find an example project for like, you know, shopping list app or something that somebody's put on GitHub, you can just clone that, then fire it up and then, you know, open an Expo Go and like skip that process of doing a build. And so like, if you just want to check something out quickly, like if, you know, 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 you only have 10 minutes in between meetings. Just being able to open something in Expo Go really quickly is actually a big deal. So 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 pass 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 projects like.
- [42:58]
Host
That question about Expo Go because. And this ties a little bit. So 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?
- [43:24]
Charlie Cheever
Yeah, basically the same limitations. So like, you can think of Expo Go as like 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 like, so maybe you have like 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. So we have a solution there as sort of a middle ground that we've been pushing people more and more to, because I think it's for a lot of situations. It's sort of a best of both worlds type thing. We'll make something called. 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 weird operating system level things like if you're using Apple Pay and you have to have, you know, certificates baked in there or whatnot, you can make sure all those things are right in a way. So it actually is a much closer experience to what your, your app is going to be like when it enters the App Store and things like that. And one of my like core beliefs as a developer kind of core beliefs.
- [44:35]
James Ide
Is a little strong.
- [44:35]
Charlie Cheever
But like one thing I believe as a developer is just like you always want to have your development environment be as close to production as possible, because whenever there's differences they just, there's a potential to come back and bite you. And so the thing we really like about development clients and the reason that like we prefer them, we've been nudging people in that direction instead of telling them to use Expo Go, it's 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 it in the cloud and it takes a couple of minutes. And if you're in a big hurry, or you're just trying to, if you're saying you're trying to teach somebody how to use Expo, you're trying to get a whole class of 20 students or something like that, XPO 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 like it's like a very generalized generic limited development client, basically.
- [45:31]
Host
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 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 that?
- [46:01]
James Ide
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 Components, the idea of rendering some of your components on a server and not just with like 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. So that is one area of focus and we want to provide a whole solution for developers to be able to take advantage of React Server components across all the platforms. We support another kind of more on the development side is like 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 CI CD pipeline as part of the whole infrastructure. 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? So we think that is just a natural evolution of some of our build infrastructure as well. So those are two concrete things that developers can look forward to in the next year.
- [48:11]
Charlie Cheever
The one thing I'd add to that is just like 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 like when they're writing stuff that feels familiar to them, they're just getting a native app on iOS and 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.
- [48:42]
Host
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, 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, very jazzed by the stuff you're doing. And unlike a lot of companies that have an open source component and a services component, like your services make so much sense for building in this ecosystem. They don't feel tacked on. Right. They feel like, oh, it makes sense why you're offering this and why it costs money because it requires infrastructure. So just super cool stuff. Any last thoughts you want to leave folks with before we wrap up?
- [49:27]
James Ide
One thought I have is that like we really want to work together with a lot of others of course that can include engineers like joining Expo but also like at other companies and partnering together like 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. So if any of the listeners work at companies where you think it's might make sense to team up and partner with Expo like yeah we'd love to do that.
- [49:53]
Charlie Cheever
Yeah. And kind of 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. So thankful to have you know the community participating and making this really good.
- [50:17]
Host
Awesome. Well Charlie James, thank you so much.
- [50:21]
Charlie Cheever
Thank you so much for having us.
- [50:22]
James Ide
Thank you Kevin.