Building Apps Faster: How AI and React Native are Changing the Game – Charlie Cheever, Expo

David Barnard:

Welcome to the Sub Club Podcast, a show dedicated to the best practices for building and growing app businesses. We sit down with the entrepreneurs, investors and builders behind the most successful apps in the world, to learn from their successes and failures. Sub Club is brought to you by RevenueCat. Thousands of the world's best apps, trust RevenueCat to power in-app purchases, manage customers, and grow revenue across iOS, Android, and the web. You can learn more at revenuecat.com. Let's get into the show. Hello, I'm your host, David Barnard, and with me today RevenueCat CEO, Jacob Eiting. Our guest today is Charlie Cheever, the co-founder and CEO of Expo, the easiest way to create native apps and websites that run everywhere using React.

On the podcast, we talk with Charlie about why React Native has become the default for VC-funded apps. How AI is accelerating development cycles, and why speed of iteration matters more than programming language. Hey Charlie, thanks so much for joining us on the podcast.

Charlie Cheever:

Hey, thanks for having me. It's awesome to be here.

David Barnard:

And Jacob, nice to have you on as well today.

Jacob Eiting:

Excited to talk about, I think one of the ... the dev tool I've been aware of for a long time has also become suddenly super, super relevant in 2025. So yeah, Expo.

David Barnard:

Yeah, Charlie, so there's a lot of reasons I wanted to have you on the podcast, but the main one, kind of Jacob alluded to, as CEO of Expo, you're seeing a lot of things happen these days with new people getting into programming with React specifically, becoming more and more popular, more and more used, kind of the default for a lot of companies to build on. So why don't we just kick things off with a high level overview. I think a lot of folks listening won't be developers themselves, so they might not understand what React Native is and we can talk about that and then as well as how Expo works with that. So yeah, tell us a little bit about React.

Charlie Cheever:

Yeah, so React is this JavaScript framework that was invented, gosh, over a decade ago by a guy named Jordan Walke at Facebook to build complicated UIs in a way that you could reason about and generate consistently. The core idea is that it's sort of component-based, so the way a human being would break down a product or a UI, it lines up pretty much with that. You'd say like, "Oh, here's my pricing component" and within that I have the dollars component and the cents component or something like that. But then the real magic to it is that you represent State as sort of like ... You have this abstract state of the world and then the UI is always sort being re-rendered to update, to represent whatever the current state of the world is.

So if you remember older websites, a lot of times you might click a button to say follow somebody and it would update correctly where you clicked, but then things sort of would look incorrect on other parts of the screen or there'd just sort be the inconsistencies with that. And as a general rule, when you use React, all of this stuff sort of magically falls into place because this stuff happens. Actually, this sort of idea I believe came from the way that video games have come to work. So if you think about really old video games, like a snake is moving across the screen on a really low res monitor, and so the way that the snake moves is that you draw one more pixel on the right for the head to move, a little one step further and you erase one pixel on the far left for the tail to kind of shimmy forward.

It's simple enough that you can actually just manipulate pixels directly to kind of change things how you want them to be. But then if you imagine sort of a modern video game or anything, once you get into the era of 3D, it's kind of ... think about Call of Duty and trying to figure out any given pixel on the screen is just crazy to figure out how to do that. And so the way that people end up doing it is basically having some sort of representation of what's going on in the world and then a system that sort of figures out, okay, here's this 3D model and it's made up of all these triangles, so we're going to draw this here, and then everything gets sort of re-rendered every frame because of that.

And so React is sort of that for UIs, for applications. So it's become by far the most popular way to build websites these days and there's still a lot of older code out there that's using jQuery and Angular is still pretty big, but almost everything new that's done by reasonable people is done using React.

Jacob Eiting:

Revenuecat.com, app.revenuecat.com, reasonable people.

Charlie Cheever:

Yeah. All this AI development is even further accelerating that because there's sort of the most training data to train on and because it's sort of component-based system that's lines up with the way human beings reason about stuff ... There's a bunch of reasons why LLMs are really good at generating React code and things like that, but what Expo is, is basically a way to use React to write UIs that not only work on the web but also work on iOS and Android and other surfaces and give you sort of actually native apps there. It's built on top of this technology from React Native ... Called React Native that came out of Facebook Meta, but you can kind of think of Expo as sort of the equivalent of what Next.js is in the web world.

If people don't know what that is. That's basically this framework from Vercel that's become sort of the most popular way to build a new website using React. A lot of batteries are included. A lot of nice features are just sort of already configured for you and set up properly and a lot of problems are just solved and it just sort become the standard and so, there's a lot of other ... a lot of example code relies on it, things like that. Where we provide with Expo is sort of a couple of different things. One is we provide this, what we call, the Expo SDK, which has literally 100 different APIs that let you have access to all the sensors on the device like the accelerometer, the gyroscope, things like that, but then also handle basic tasks like video and audio playback and recording and things that you want to do in an app like that, location services, things like that.

And generally they'll give you access to ... There's sort of multiple implementations of these and they're well-tested, and things like that. So they work on iOS, they work on Android and they work on the web. In the same way that a standard library in Python or something like that includes a lot of the basic things you need to do or write a program that actually does something. The Expo standard library is basically a sort of basic batteries included way to get started and then, we have a bunch of tools that include Expo Go, which is an app in the App Store that'll let you sort of get going, editing a live real app on your actual device within seconds, which is a real differentiating factor.

So a lot of the new tools that are doing AI stuff with development, they end up using Expo as their way to deliver that stuff because you can download Expo Go on your phone, scan one of these QR codes that these AI tools are generating and it can actually be sort of vibe coding or live editing your app on the fly. And then we also provide a suite of cloud services that are sort of how we make money. We run a build service that runs Xcode in the cloud and Android studio in the cloud. We run sort of an update service, which is the analog of web hosting. We also do web hosting and a few other things.

Jacob Eiting:

One of the beauties of React or working in React on Web or on React Native is live updating, which is not something for mobile that we had without React Native is you would build ... you'd modify your Objective-C or Swift or whatever, you'd have to recompile the whole app. You'd have to deploy it to the simulator or to the device and it's like, if you have a small app, maybe it's 30 seconds, but if you have a big app that could be minutes. The cycle of using React Native and then, Expo Go, allowed you to have this insanely tight build and change in view cycle, that was ... even though React Native I think especially in the early days was somewhat difficult to work with.

It wasn't as batteries loaded as you've made it now with all the Expo stuff. If you could get that to work, it was just crazy how fast you could iterate. I mean, I that was a huge ... I don't know how much credit Expo gets for making React Native a thing, but I think that made the developer experience really viable and actually in a lot of ways better than the native development experience on mobile.

Charlie Cheever:

Yeah. That iteration speed is a huge reason why people have moved in this direction. I think a lot of the customers that we have now, a lot of them have actually had working iOS written in Swift, written in Directive-C apps and working Android apps that were written in Java or Kotlin. And they just sort of found, it's too much work to maintain these ... but if we wanted new features, so we can't move fast enough on either platform, much less both at the same time. It's really hard to hire for these sort of specialized positions. We're at risk all the time, if our sort of one Android person leaves, what are we going to do?

And so a huge deal for all these companies is basically we can move faster than we could on either platform by itself, but now we're able to write one React code base. There's way more React developers in the world than there are basically any native platform like Swift developers or Kotlin developers.

Jacob Eiting:

Yeah, just because it's the default on the web, creates just more-

Charlie Cheever:

Right, and so, you can take of the same pool of people that you'd be hiring your website team from and put them all on application team and they can work on all products all at once and that's a really big deal for a lot of people. But then even on top of that, you're still moving faster because you're getting ... Instead of having to recompile every time you make a change, you're usually getting the same benefits that you would, basically work on a website. A lot of the way to think about what Expo does is sort of takes the things that are good about doing web development and bring them into the world with native mobile.

Jacob Eiting:

Did you guys ever get guff from Apple for pulling down live code? Because they used to have stupid rules about this and I think they relaxed them.

Charlie Cheever:

They've really changed the rules over time. They used to be really strict and say, you can't download any code, but then people would just use web use and then of course, the way that the web works is it downloads much of code like JavaScript and CSS and stuff. And then also, big companies were just doing it and so, it was sort of a don't ask, don't tell policy or whatever, but then they kind of realized that it was just stupid to prevent that. They changed a lot of the rules over the last couple of years. So now it basically says don't trick people or mislead people and you can download code and you can run it.

It has to be sort of interpreted code, not compiled binary code, which is fine. And the way that that actually works is you download JavaScript or JavaScript byte code and then it gets interpreted on the device, kind of the way that your web browser and your computer might download JavaScript for a website and run stuff. And so, we never had too much trouble with that because as we were starting to get popular, Apple was in the process of pulling back a little bit from being super-duper strict about those rules.

Jacob Eiting:

It was five years earlier, you would've probably had a hard time, but they were ... yeah.

Charlie Cheever:

Possibly, but they've also ... there's maybe literally one or two cases where something that was a FinTech app or something like that, they sort of said, "Hey, we don't want you downloading anything." We see network requests for things that look like they changed the UI of this. It's been a while since you've heard of anything like that, but maybe back in the early days we heard of one or two things like that, but that's pretty common that Apple and Google, but especially Apple are often pretty ... They like to just kind of poke at things and sort of come up with reasons to reject apps every once in a while, to just remind you who's in charge and make sure that-

Jacob Eiting:

Well, I mean it literally in a way, does circumvent app review. You can blow away an entire app-

Charlie Cheever:

Yeah, the way they've changed the rules is not to sort of say you can do whatever you want, it's to be more product focused in the way that they describe it, where if you were to use this downloading new code technology to take an app that was for buying groceries and turn it into some OnlyFans type thing, then they would say, "Hey, you can't just change this under people's feet. This isn't what they signed up for. You're tricking people. We're going to ban you for that." But it's less about the mechanism they're using to do it. It's more just the fact that you're tricking users and pulling the rug out from one them.

Jacob Eiting:

Is it Von Neumann? Who's the one that says code and data are the same thing? You know what I mean? It's really hard to differentiate, because you could send JSON down that your app functionally interprets to do things, right? So it's really difficult to say what's code and what's not.

Charlie Cheever:

That's the way a lot of modern apps that don't use Java, things like Yelp that are older apps that are written in Objective-C, Swift or whatever, they're doing exactly what you're describing, where they're downloading lots of chunks of JSON to deliver custom UI, they're sort of edging their way into building sort of a half-baked dynamic interpreter of UIs.

Jacob Eiting:

Basically react rendering a scene graph or I don't know what it's called in React land, but ...

Charlie Cheever:

There's a kind of moderately famous old CS quote that's sort of like any sufficiently complicated system in C++, contains the half-working inefficient version of Lisp or something like that. And it's kind the same thing that you're describing.

David Barnard:

Well, one of the things I did want to kind of talk through is that the combination of React Native and Expo especially, have kind of become a new default and yeah, you quoted in our state of subscription apps report that the pragmatic engineer reported that almost all new VC funded startups are using React Native versus building native and huge apps, Spotify, Discord, NFL, tons of the biggest apps that people interact with on a daily basis are built in React Native. And we kind of already touched on a speed of execution being able to change things remotely, but do you think building apps with native code is less important in 2025 and why?

Charlie Cheever:

There's a couple of things going on. One is just there's a general improvement in the technology. You see this happen all over the place where writing stuff in client side JavaScript didn't make sense in 2004 because of just all the features you needed weren't there and the performance of JSVMs wasn't there, et cetera. And then things just get faster and better. That's one part of what's happening here where there's a lot of stuff that's happened in this space, some it is pretty low level. Meta is responsible for two of these things and it's great to have sort of a deep pocketed company behind a lot of this that relies on it for a lot of important things.

And so two really important things that have happened in the ecosystem are this new JSVM called Hermes, which is actually like ... I don't know if you want me to go too much in the weeds here, but basically, there's ... The most famous JSVMs these days is the one that Google made for Chrome called V8 and that's a really great JSVM where it really moved the web forward, it moved JS forward. It's a jitting VM and so it does just in time compilation of your code. And so, as your code is running for the first couple times it'll also track the hot paths and sort of compile those on the fly.

And they'll run faster, but in UIs, you actually don't really want that a lot of times, because you're not doing lots of complicated computations or mathy type things. You should just trying to run through stuff once and put stuff on the screen. And so, you actually want to opt ... and a lot of times when you think about what you want in the UIs, you want it to be like that first interaction comes as quickly as possible rather than you start running faster and faster as your code runs over time.

Jacob Eiting:

He's really good at passing some certain benchmark but not actually what matters for team graph rendering?

Charlie Cheever:

Because of Apple's restrictions on sort of native code execution, you can't really run a JIT on an interpreter.

Jacob Eiting:

That was going to be what I asked, what the status on that was, because I didn't think you ... Famously like Apple wouldn't allow this for essentially, but probably legitimately security reasons.

Charlie Cheever:

Yeah, I think it's not crazy that they restrict stuff in this way. So Hermes is designed to not JIT for performance reasons in an interesting way and it's really designed for this use case in particular and a few others. And it also uses a bytecode format. So instead of just sending down strings of texts that are human-readable, it's pre-compiles in a sort of more intermediate format and gets send that down, that saves some time, that just boosted performance especially on low end Android. But across the board, Hermes is a big step and there's also something called the new architecture React Native that's been talked about for years and finally in the last year, it's now rolled out.

And sort of the default of new expo apps and new React Native apps, to use as new architecture. It allows a lot more control over low level stuff that you actually want to really optimize the performance of things like lists are really important to UIs on mobile. Almost every app that you use involves scrolling through lots of lists. Think about Instagram, think about any messenger you use.

Jacob Eiting:

UI list view. I think famously it was like the singular most important component of Coco, originally because it was just super optimized and so fast and we made the original iPhone feel so good.

Charlie Cheever:

And so, one thing that this new architecture enables is just like you can write much faster List because you can sort of synchronously measure elements and react to those changes without having to go through lots of re-rendering steps. I'm glossing over a lot of stuff there, but basically this new architecture is a big step forward in terms of performance possibilities and a few other things. The other thing that's happened is the way you pose this question was like is it less important to write native code on mobile? But actually one thing that we spent a while doing at Expo was making it a lot easier to write Native code as part of a React Native app.

And so part of the sort of dream of React Native was always that you're actually interweaving stuff that's native code with stuff that's orchestrated by JavaScript

Jacob Eiting:

And you're writing React for Web, how you can interleave like HTML basically, like style within your JavaScript, you can seamlessly write components out and then switch back and forth.

Charlie Cheever:

It's kind of like that and React Native when you generate a view or a list view or a scroll view. One of the things that's really appealing about React Native is it's actually generating the operating system components. So a view interact native on iOS will generate a UI view from UI kit and on Android view. And so, the actual elements that you're interacting with should feel exactly right to the operating system you're on, but then if you do need to write some sort of specialized native code to do some sort of fluid simulation or some really custom video player or something like that or some view that pops up a native share dialogue or a native payment dialogue or something like that, you can easily drop down into native code and write that stuff.

A big thing that we worked on at Expo is we ... This gets in the weeds a little bit, but it's actually pretty important. We developed this thing that we call config plugins in CNG. And the sort of way that you would do native code in React Native projects before that was kind of the same way that you might've dealt with like PHP extensions back in the day or weaving together C++ code with a scripting language where you're doing a lot of compiling stuff yourself, figuring out which things you need to download and which dependencies you need to download and how to put them all in the right place.

Jacob Eiting:

And then, if you were making ... In my shoes, trying to make a React Native SDK that somebody else could then go use that was based on native code, this is rough.

Charlie Cheever:

Really, really rough to do. And so, a lot of these projects would have ... you go to the GitHub for it and the Read Me is sort of like a four or five page long thing with here's all the steps you need to do on Android, here's all the steps you need to do on iOS, and then, if you're bringing in the RevenueCat module and a special video player module on a camera module, a lot of times those things would actually ... the instructions, what have you, editing various config files or whatnot, they might step on each other's toes like, "Hey, in this app delegate, add these lines." And then you're like, well those lines, that doesn't look the way it says it's going to look.

Because I added this other module or whatever. And so, what config plugins are, are basically sort of in your module, you can add sort of a set of instructions or scripts that basically tell the native code how to install itself in a generalized way and then what CNG is Continuous Native Generation. And so in a typical old school React Native project, you'd have your JavaScript source directory that has your React code and then you'd have an Android directory and iOS directory where it's sort of the special native code for Android and iOS would live. And in a sort of expert project using CNG, you don't have the Android and the iOS directory typically living in your project, because they get generated every time that you make a change to the set of config plugins you use.

Jacob Eiting:

They're almost like a machine code now, right? They're kind of like halfway between

Charlie Cheever:

When you NPM install some package, it figures out what needs to get downloaded and kind moves those files into the right directory and makes it so you can just require that in your ... or import it in your project and it'll just kind of work. And you can kind think of it as the same thing where you can just kind of one command to install a new React Native purchases or some other package and then, all of the setup just gets taken care of and if you upgrade to a new version of React Native or new native stuff, all that stuff, it just sort of happens seamlessly.

It's gotten way, way easier to actually use native code. And so even for people that think native code is really important, it's gotten much more sensible to use React Native than it was in the past because it's a lot easier to access the native layers of stuff. The way a lot of people probably look at it is, if you think about what's going on in the world of AI, obviously performance is super important in doing all this machine learning type stuff, et cetera, et cetera, but a lot of the code that people who work on optimizing these models at OpenAI or playing around with these things, they're running a lot of Python.

Because some things need to be really, really fast, but a lot of stuff doesn't need to be really, really fast. You're just sort of saying, go do this task that has to be really fast and you're sort of orchestrating things and so you see this happening in a lot of systems and so that's one big factor. Another factor is a couple of years ago engineers were sort of considered assets to tech companies and so people were trying to hire ... if I can hire 100 people, I'm worth 100 million dollars or something is a blog post I read and people are not thinking that way anymore.

A lot of the companies that we talked to that are using Expo, they even had working iOS apps that were well-reviewed, perfectly fine and good Android apps that were also in sync with that and perfectly functional, but they were just finding it was really hard to move forward quickly, really hard to keep those things in sync, really hard to hire for these positions. And also just, they were really at risk if they were to lose their one Android developer or their one iOS developer and they'd just be stuck and unable to keep their product going.

Jacob Eiting:

Creates some really awkward choices too when you're like, "Oh, we want to experiment with something," but then you are forced to not do parity. You had to do it on one platform and then, backport it and then that backport never happens because you're busy, yeah.

Charlie Cheever:

Now all of your documentation to your users and your customer service team is getting confused and has to ask more questions. There's just all kinds of things that are bad news about going on that path in general, there used to be this idea that your Android users have fundamentally different expectations than iOS users and the web is its own beast. If you go rewind time back to say 2011 ... I think Dropbox and Slack were two pretty good examples of this where they had totally separate design teams working on their Android and iOS products. So if you switched from an Android phone to an iOS phone or vice versa, and you're using Dropbox, you're using Slack, you would just be like, I don't know where anything is.

What the heck is this ... Because it's just a totally different product. And now, things have really gone pretty far in the other direction where-

Jacob Eiting:

Convergent evolution, right? It turns out that there's only so many ways to make a decent mobile app.

Charlie Cheever:

People want basically the same product on iOS and Android and Web and if so, when I use the United Airlines app on my phone, whether it's on my iPhone or my Android phone or the mobile website or the website, it's basically the same product, same design language, things are all in basically the same places. I don't think United Airlines actually uses React Native, they might, but I don't believe ... I just think the general thinking around product has moved in that direction, but then once you're thinking around product moves in that direction, you're like, why doesn't our implementation matched the way that we're actually building product?

Jacob Eiting:

I see what you're saying. So the actual conformity comes first, that we should just have things be identical and then ... from then it follows why do we have these separate tool chains, right? Yeah.

Charlie Cheever:

And then another thing that's kind of come online is we did a lot of work to make Expo work on web as well as iOS and Android, so a lot of the people now that use Expo actually literally have one team across iOS and Android and Web, and so it's not just a mobile only thing. So one of the most prominent exciting Expo apps is BlueSky, which feels really good and I find it basically as good as an app ... missing a few advanced video features and stuff, but otherwise pretty comparable to Twitter, in a lot ways, feels great, but they had their sort of thing they'll say is one man, three platforms, four months was how they built the first version of app.

Because they weren't even planning to build an app. It's a complicated sort of origin story, but when Jack Dorsey was sort of thinking about how social media needed to evolve and how it could be federated, he sort of allocated some funding for a federated kind of protocol, but they're really just imagining they would make a protocol for how to federate something like Twitter and that Twitter would be the first client of this protocol. Then unless at Twitter are just sort of like, why do I need this ... I am trying to cut everything and make this a lean and mean machine. I don't need to deal with this. But they had incorporated as a separate company and the funding was sort of already earmarked for it.

So they were able to keep going, but they were looking around and they're like, we have a 10 person team and we have no developers who are iOS developers or Android developers and we're on a kind of tight timeline here and we realized our only way forward is to actually make an app to be the flagship version of our federated protocol. And so, they just had Paul on their team, didn't even have React experience and he just learned on the fly and he was just a really sharp guy with pretty good taste and was able to make something pretty good out of the gate. And they still only have about three people working on the app and it works across all the different platforms.

Jacob Eiting:

And so, they have one code base for their web that's like Extreme React UI, right? To be able to scale. That's crazy. One thing, we were talking about the Facebook investments, who is doing most of the work on that last translation layer now from your scene graph to rendering and native UIs and stuff, is Facebook still developing a lot of that? Is it handled by the community? Because I imagine a lot of what makes React Native plus Expo work really well is kind of that last mile of translating it to the platform.

Charlie Cheever:

How of that kind of doesn't need as much change as you might think? One reason it works pretty well in a lot of ways is that it's not a super heavy layer. I'm glossing over a bit here, but if you make a view in React Native ... use angle brackets in your right view, you're writing some react code. When that target is web, that's just going to turn into a div. There isn't some sort of crazy giant transformation and you can kind of reason about how it's going to end up rendering. And when you have that view and it goes on iOS. It's going to end up with just a UI view from UIKit and there's a little bit of wrapping and other kinds of things that go on there.

And basically a lot of what we think of as apps is just sort of rectangles and sort of color and styling and text and then some images and things like that. And so, there is work to do. We released something not that long ago called Expo image, which a lot of people are using things like SD web image and fast image and certain like, things that will handle, caching in different formats and things like that. And some of those weren't that well maintained and so we just sort of decided this is something we should build ourselves and pull it to the SDK and sort of standardize and whatnot. So we do a lot of that. There's also a lot of the innovation that's happening right now that's pretty good for the space is expectations of what we expect from products have gone up a lot.

This is true on the web, kind of double true on mobile, but if you think back to a web, 15 years ago or something, what you'd expect from a website is you wouldn't expect any kind of 3D graphics or interesting transitions, but now you even go to some random product pay for something and a lot of times, you'll scroll down and some sort of crazy 3D animation will happen as you scroll or something like that. And a lot of this is web GL and just things for doing that on the web have advanced lot. And so, if you want to add a lot of really nice touches to sort of React Native app or something like that, there's some really good libraries out there like React Native Skia, which adds this sort of Skia 2D graphics engine.

And then there's ... at this conference I'm at today, there was just some announcements around React Native web GPU and having access to that and then there's something called Reanimated made by a firm in Poland called Software Mansion. They also think something called React Native gesture handler that ... like these powerful libraries that let you get all these gestures in the animations to be really right but also be things that you can write in just JavaScript instead of having to go write a bunch of custom native code to make something look and feel really cool.

Jacob Eiting:

Not getting back into the multi-platform problem where you have to do some native stuff. It sounds like stuff is really accelerating. I think there was a ... I don't know when this was, but there was a moment, maybe it was five years ago when Facebook kind of dropped React Native and there was a lot of flood about maybe React Native is over, but it seems like that's the opposite now, was that always just a fake news or what was the story?

Charlie Cheever:

There were a couple of things that were challenging. The most damaging thing that probably ever happened in the history of React Native is that Airbnb was kind of an early user of it and they had a couple of guys there that were really good developers and contributed a lot and they'd go around at a lot of conferences and talk about their work, for a bunch of complicated reasons, the engineering team at Airbnb decided it doesn't make sense to kind of maintain our sort of native stuff and our React Native stuff and we decided that the native people kind of win and so, we're going to just stop doing this.

Jacob Eiting:

And they were never a fully React Native app though. They had React Native components.

Charlie Cheever:

No, they were using it for 20% of the app or something like that, but they were pretty vocal about it.

Jacob Eiting:

Which is you get less benefit then, like if you have a native and-

Charlie Cheever:

It's somewhat complicated to kind of have a really mixed brownfield type approach. It's more complicated than having a website that was using jQuery and then is using React for one of the screens because in a website, you're using JavaScript everywhere. And so, if you have some data that's pulled down by a jQuery, Ajax call and then you want to use it inside of a React component or reuse some of the same state, you can just pass those variables back and forth or refer to them. And this is just one example just to illustrate the point. But let's say that you had a screen on Airbnb's app that's written in Swift. And then, another part of that screen is written in React Native, and then it's relying on some profile for a house listing.

And that house listing has some data and has a you URL of a photo or something like that and you pull down on that data in Swift and it's now in Swift variables, and then all of a sudden you're like React Native wants access to the same photo to make sure it's the right thing or it wants to highlight something, and that data isn't available in JavaScript, so you have to create some sort of way to marshal things across some bridge and whatnot.

Jacob Eiting:

Bridge and then now, at a minimum, you're probably duplicating your memory consumption, right?

Charlie Cheever:

There's different ways you can handle it, but it's almost like you have this three things to worry about your native world, your JavaScript world, and then, the way to move between them. And so, now a lot of things that are ... I think that's something that I really want to work on is making that sort of incremental transition easier. But in the world where we are now, definitely the things that are having the most success that we see are things that kind of start from the beginning. As you're as React Native apps, they might use a lot of native code, but it's usually in this way where it's like, "Oh, we're going to do some really specific stuff, have a custom video player, but it's going to be a React Native module and that can just sort of plug in and we can drop down a native code wherever we need to," but the whole system is being orchestrated and controlled by React Native.

Another thing that ... When I was talking about the transition to this being pretty standard, a thing that we spent a lot of time on was Evan Bacon on our team was amazing, spearheaded this work on something called Expo Router, which is pretty common in the world of React, our website's to have a sort of router thing that will handle just mapping out the architecture of all the tabs on your screen or what URLs map to and whatnot. It's a much more complicated problem on this sort of multi-platform mobile type thing because if you think about ... this is probably something that anybody can understand if they stop and think about it for a minute, but most of us don't. Well, on the web, the structure of websites is that you have this URL bar, and there's a back button.

And it means that there's kind of one stack of navigation in a lot of cases, where if you think about ... Everybody probably is familiar with Instagram who's listening to this podcast, and that's a pretty common paradigm where there's four or five tabs at the bottom of your screen and each of those is kind of its own stack. And so, if you go to your profile tab and then, you tap on followers and then, you tap on somebody else's profile, that's all happening underneath the profile tab. But then if you go to the search tab, you go look at somebody else's profile, but then if you go back to your own profile tab, it's still whatever you've navigated to and there's multiple hierarchies of stuff going on.

And so, when you're making an app that exists as a mobile app, you often want that paradigm that's more like the Instagram app, but then when you're on the web, you want it to feel like a website and be natural in that way. And then, there's also this deep linking, this gnarly problem that is actually pretty hard to get, right? Where if you think about, anything you have an app installed for, they might send you an email that has like a "Hey, check out this listing for this product for sale on our app or whatever." And then you tap in the link and it opens the app and it just gets confused and takes you to the home screen and you're like, I was trying to get to this specific product or this specific video.

Jacob Eiting:

It's about 50/50 I feel like when I deep link into an app if I'm going to get where I'm trying to go.

Charlie Cheever:

Yeah, so Expo Router handles that and just works basically as well as anything can work across iOS and Android and web, and just that problem just becomes a thing that's solved for you rather than a thing that you spend hours and hours and hours trying to get right and stressing about and whatever. So that's a very nice thing that just made it a lot easier for people to adopt.

David Barnard:

In researching for this podcast. And then now, in listening to you for the last 30 minutes or so, I've updated my prior's a lot. And I was one of those snooty iOS developers who was like ... that was like so focused on, "Oh, it's got to be native, React Native is just a lame web wrapper and users are going to notice the performance is not going to be there. It's going to be more complicated, and all of that is-"

Jacob Eiting:

Which may have been true in 2019 or '18, but maybe not today

Charlie Cheever:

On the web, you can always view source and so you can always figure out whatever any website is built with. But one thing that I've always found funny is when somebody does an awesome job building a React Native app, you don't notice and you just assume that it's truly native or whatever-

Jacob Eiting:

You can make pretty trash with UI and UIKit apps too, right? I've seen them.

Charlie Cheever:

Right, so there are some bad React Native and bad Expo apps out there that are just unnecessarily causing all kinds of re-runners or loops or whatever, but you can also do that, as you're saying, with Swift UI or whatever. A lot of times there'll be a bad Swift UI app and people will just be like, "Oh, stupid React Native. I can tell what this is." And because there's no easy way to do a view source or-

Jacob Eiting:

Have you ever done any blind taste tests? I'd be very funny to-

Charlie Cheever:

James and Brent on our team, I think used to be pretty good about being able to sort of, "Oh, I'm going to drag this screens and I'll notice some artifact in this thing and I can tell that that's using this library and stuff like that." It's getting harder, but there's still some ways that you can tell certain things for sure. But we've also tried scanning the App Store and downloading a lot of the top apps and just sort of like, we did a research project to basically just figure out what ... because we're an open source project, so we don't actually know everybody who's using Expo. If you're just using the open source framework, we don't know. So we had to download just the top 100 apps in every category just to get a sense of what was going on there.

David Barnard:

So I was talking about updating my priorities. The biggest thing that forced me to update my priors was actually our state of subscription apps report, and that's what I wanted to talk about next, is that in our report we showed that React Native apps actually monetize better than native apps. There's probably a little bit of a-

Jacob Eiting:

100% causative. It's all the framework, David.

David Barnard:

There's probably a little bit of bias in that, and then, we've talked about this before that we have a ton of indie developers on RevenueCat who are iOS only, and that to our point earlier, a lot of the VC funded apps are cross-platform from the beginning and kind of building a business, not a hobby, tend towards React Native. So there's some bias in the data, and you kind of alluded to this earlier, that what matters is your product, and if you're able to iterate more quickly, build a better product, it doesn't matter what technology you're using. And in fact, maybe it does and that React Native lets you move quicker, and that you don't have multiple teams, you don't have things getting out of sync and stuff like that.

But I know you saw that data, because we had you do a little blurb in our report, but did that surprise you to see our data that React Native apps are monetizing better than native apps?

Charlie Cheever:

This is a little surprising to me just because, I would've expected that a lot of the native apps would be iPhone only and iPhone tends to monetize better than Android and my limited ... I mean you guys would know better than I would, but-

Jacob Eiting:

But it's almost always like it's iOS and Android, so the Android is almost probably always incremental?

Charlie Cheever:

I could see something here where it's just a lot of the people using React, you're going to have more React Native apps that are newer because React Native is just ... Certainly Expo has gotten way more popular recently. Our NPM weekly downloads have tripled in the past year, for example. So a lot of stuff that's built that way is going to be newer and is going to have people ... People making active choices, researching the best way to do stuff and working on things and trying to use the best technologies and the best practices, whereas some of the older stuff might just be like this project has been around a while, it's kind of in cruise control mode. I'm not saying maintenance mode, but just like, we're just trying to keep this running or whatever.

That would be part of the guess, I would make. But I also would just bring up the point again that whenever you need to in React Native, it's now quite easy to drop down and write a whole screen in Swift UI and Kotlin or whatever you want for those specific platforms. And so, if you're a good React Native developer, you're probably doing that at various points whenever you need to, but under settings screen, you basically don't ever need to do that in most cases. Those are the kind of things that a lot of ... Even a lot of the parts of the actual iOS settings app, if you go into manage your subscriptions of your iOS, a lot of stuff has actually been using web use, even though we think of it as sort of native to the Apple platform.

Jacob Eiting:

Yeah, yeah, like the subscription one, it drives me nuts. It is markedly slower. It would be better to React Native-

David Barnard:

Yeah, you should-

Charlie Cheever:

I think it actually would be.

David Barnard:

They would never dare put JavaScript between them and UIkit,

Charlie Cheever:

But I think a big part is like, the ceiling has gone up, because it's a lot easier to access the best capabilities of the device than it used to be.

Jacob Eiting:

My two cents is it's probably all ... I mean no knocks to React Native and Expo, but it's very much a selection bias thing. If you are more focused on business success and business outcomes, which maybe that's a great argument for the platform. And I think ... And as Dave was saying, I think if you're a native mobile developer, I think it is time to at least give it a try and re-evaluate your priors, because I've built apps and React Native. It's been frustrating in different ways, but this was five, six years ago and things have changed.

Charlie Cheever:

It's gotten way better, way easier to make stuff.

Jacob Eiting:

Yeah, thanks to you guys. And also, just baseline technology changes, phones are faster as well. And so, I remember in the late teens, being skeptical of people that were making this choice, because I was tried and true mobile objective and Java developer and I remember being skeptical, but now looking back, those companies have had various success and not success, but none of it was hurt by the fact that they were ... In fact like I argued, but for all the reasons we talked about today, I think these were good choices.

Charlie Cheever:

It depends on the business you're in into.

David Barnard:

And then now today, speaking of making things easier, the next kind of topics I wanted to discuss was AI assisted development. I did want to kind of cage these two different things, because I think they get blended a little bit. So we'll talk first about what I'm calling AI assisted app development where you're a programmer, you know what you're doing and AI is accelerating things, whether you're using React Native or not. And then you have the kind of vibe coding of like, I'm going to jump into Bolt to Replit and throw a few prompts in there and I don't really know how to code, but it's going to build an app.

But let's talk first about what you're seeing in that AI assisted app development loop of really top-notch programmers using AI and React to just move quicker, using things like Cursor and Windsurf and GitHub, Copilot and Cloud Code and all these kind of tools to move faster. What are you seeing there?

Jacob Eiting:

And also maybe what Expo is like, kind of has a unique position right now in this world, which I think is interesting.

Charlie Cheever:

For that kind of stuff. One thing that's really ... a big deal is how well-trained are the models and the stuff that you're having it, right? And one thing that's just good about React is there's just a ton of open source example code out there and people ... it's much more common to make a React project open source than it is to make a Swift project. These alums are actually pretty good at figuring most things out to some degree, but just the more training data they have, the better they're going to be and whatnot. And so there's 1.2 million plus Expo products that are open source on GitHub right now. And some of those are old and out of data and that can cause its own sort of niche problem or whatever, but a big part of it is just there's that.

But then another thing that happens is that when you have this sort of AI assisted coding and you're a developer ... Actually I was teaching a workshop the other day at a college and a few years ago when I would do that, a lot of the time I would spend and when I was teaching a workshop, making a basic app would just be me typing out basic stuff of state management or going to our docs to look up the right thing, the right incantation to import the camera module or things like that. And then, I was just like, in five minutes, I had sort of built a whole to-do list app and added a couple features to it and I was just sort of like, "Okay, class. I'm not going to have you watch me use Claude for the rest of this session. Just come up to me if you have problems and I'll just talk to you guys."

The time it takes to do basic stuff just goes way, way down. And so when that's happening. We start to get super sensitive to the things that start to take a lot of time and slow you down. And so, I am sure you guys have seen that famous XKCD comic where there's the guys, cardboard sword fighting in the spinny chairs where they're waiting for things to compile. And so, when it's taking you a split second to write code and then all of a sudden, you're spending a minute and 45 seconds as your app ... the sort of nasty thing about compiled apps and stuff like that is they start off ... when you have a white screen with one thing of black text and it just says like, "Hello. It's like compilation is pretty quick," but then even when you get to start six, seven screens that are pretty, it's like-

Jacob Eiting:

Four get sub modules, SPM CocoaPods, somehow both in the same project. Yeah. Yeah.

Charlie Cheever:

All of a sudden that's now 45 seconds, a minute 45, and it just sort of big companies that have these huge sprawling apps like Uber, a huge chunk of the engineering and stuff is like, it takes 45 minutes plus to compile our app. And so people are going off and making new projects where they're building new UIs and then trying to copy paste them over and some crazy stuff. So anyway, tangent, but you can imagine that waiting for stuff to compile when you're not really spending any time writing code just becomes super, super painful. And so, the idea that you can just make a quick change, you save it and that UI is now updated on your phone or in your simulator or whatever right away.

That just feels so much better and that bottleneck is really exposed as you really ratchet down the amount of time that you're spending writing code. Sort of similar principle is happening with vibe coding as well where models like Claude and Gemini or whatever are decent at writing Swift code or whatever. That's actually kind of exciting for React Native because I was just talking to someone today who is a really good ... a React Native developer, this guy Fernando, who's the head of mobile at Vercel. He was saying a lot of what he's been doing lately is doing more stuff in Swift on iOS because he doesn't have to become a Swift expert. He can kind of ... when he wants to go do something, he can just have AI point him in the right direction, clean up stuff and make it work.

And so he's able to write more stuff in native code. So LMs are actually decent at writing that stuff. But imagine you're a vibe coder and you're just like, "Hey, I want to try ... I heard that I can make stuff as ..." Just vibe coding now, and you decide you want to do that by writing some Swift code and it's like, "Okay, well first of all, you need to have a Mac" only what 12% of computers globally are Macs. Okay, so now a lot of people are just stuck and they can't do anything. But let's say you do have a Mac and let's say it's a Fast Mac, whatever, and it's kind of like, okay, now here's ... your next instruction is download Xcode. And that often takes like 45 minutes and then, setting it up is another 45 minutes of-

Jacob Eiting:

$99, sign up to the Apple developer program, a DUNS number ... No, you don't have to do that, but-

Charlie Cheever:

You don't need a DUNS number. You want to go to the App Store, but it literally can take you three days before you get your developer account approved. You don't need a developer account anymore to just put something on your own device, but like-

Jacob Eiting:

And not even the simulator actually on your own device, you can do it without-

Charlie Cheever:

Yeah, if you plug your phone into your computer, it's pretty handicapped in a lot of ways, but they're a little bit more lax. The mindset just seems to be like it's a privilege that you would be able to write any software on these devices that are sort of pristine playgrounds.

Jacob Eiting:

I mean I won't do back in my day, but it's a heck of a lot easier now.

Charlie Cheever:

It's gotten easier, but it's still not actively easy. It's like they're just sort of a whole bunch of hurdles.

Jacob Eiting:

Opening an HTML file in Chrome and boom, you're running.

Charlie Cheever:

Expo is just a bunch of different tools and it will take me a long time to explain all of them, but one of them is this Expo Go app that you can download from the app store and that has basically just most of the modules in the Expo SDK kind of baked into it already. And so, if you would just want use the camera view or location or the gyroscope or any of the sort of basic things, those are already just baked in natively. And so, that covers a lot of ground for a lot of people. And so, if you can write stuff that ... You can use any font you want, you can do any kind of styling you want, you can do any kind of things ... Even as React Native Skia built into it. And so you could do pretty complex stuff with just this.

And so, a lot of the Vibe Coder stuff basically just is like here, here's your instructions. Download the Expo Go app from the App Store. We're popping a QR code up on your screen, scan the QR code, bam. In less than 30, 40 seconds, you now have your app on your phone as you make changes to it and you're writing stuff that's just happening. So I was just up in Seattle this place called the AI ... it's sort of a complicated thing that's like an incubator plus event space, plus coworking space personally runs the sort of physical space there is telling me that they needed some sort of check-in. A lot of offices have this sort of check-in step where you go up to the desk and they have an iPad and you sort of fill out your name and who you're going to visit and whatnot.

And she was saying that because they're this sort of hybrid of a couple of different all at once, none of the sort of off-the-shelf solutions were exactly what they needed, but they'd also didn't need something super crazy complicated, because it's just like, they don't have 100 locations, they just have this one space. She's not a traditionally trained developer or anything, but she was able to just fire a Bolt with Expo and build an app, just vibe coding that has their whole list of experts connected to that database and then, has a whole sign-up form and you can sign your name and then, it submits it and it stores it in a Postgres database in the cloud, using Supabase and they can access it and she was able to do that in a couple of hours, just sort of repeatedly prompting, not editing any of the code.

Jacob Eiting:

Which would comparative even an expert developer that would take a week now, to make it work, right?

Charlie Cheever:

Yeah, probably that's actually live now, using some of the Expo tools to help get stuff into test flight. A lot of what we actually do is just solving this distribution problem of like, "Hey, I want to take this app and get in."

Jacob Eiting:

So it's great that you can get up and running in the Go app. I mean I know you guys still do a lot. I think the thing that's made Expo ... One of the things that's made Expo so relevant all of a sudden for all these people is that last mile on mobile is so painful, so it's great. You can vibe code something up and it's basically running in a browser, but then okay, you want to get on the App Store.

Charlie Cheever:

Right, and so a lot of what we've been working on the last year or two is stuff to ... We just released a module and not that long ago called NPM Test Flight where you can basically in an Expo project run NPM test flight and it'll just walk you through all the steps and put it in test flight and you don't have to ... You're not thinking about provisioning profiles, you're not thinking about distribution certificates, all these things that are just like ... I feel like I've talked to so many people who are in the mobile world and if you sort of get them aside and you're like, "Explain to me what a provisioning profile is," they're kind of like-

Jacob Eiting:

Charlie, I am probably one of the few people that could actually do a really good job, but-

Charlie Cheever:

Right. I'm sure-

Jacob Eiting:

The knowledge I would love to free up in my head, trust me.

Charlie Cheever:

Right, and there's just a lot of people who are like, "I just kind of keep refreshing things or Googling things until it finally works."

Jacob Eiting:

When they added ... At some point in Xcode, they added a fix my provisioning profile button, which-

Charlie Cheever:

The worst. They never click that button.

Jacob Eiting:

Which is actually roll a dice and maybe nuke my developer profile.

Charlie Cheever:

There's still some sort of rough edges around there because Apple just wants to stay in control of stuff and it is hard to make something that's perfect, but we put a lot of work into making it so that getting up and running on the web because we've added web hosting, it's like that, or getting up and running through test flight or the app store or whatever. All those things have been a lot easier. A really good flow that a lot of people like is we actually run Xcode and Android studio in the cloud for people. That's sort of one of the main ways that we make money as a company and if you don't have a Mac or you don't have a fast computer, that's just pretty nice, but it also means that you're not grinding your computer a hall, every time you do a check-in, it's easy to have a cloud to kick off.

Then we can also take that artifact and just submit it for you or put it in test flight or just do wherever that artifact needs to go. We can sort of solve those problems. You can have a bunch of scripted tests run against it and then a report generated, and whatnot. So solving a lot of those problems is a big part, and we've just realized that people need to go from idea to living thing that's running in production the way they want it to be.

Jacob Eiting:

You mentioned there's Bolt and Replit and Lovable and a Zero, there's a bunch of these. And most of them are going through you. Do you think that that's the way things are going to shake out? Because I'm wondering for us as an infrastructure company too, it depends on your belief in AGI, whether or not you can be Build Expo as a command line thing. Do you think these companies continue to run through a centralized service provider or do you think they're going to need to own this? I guess it comes out of a question of where the value accrues and stuff, or maybe you can even say, are you guys thinking about just owning the Vibe coding layer? Where do you think it goes?

Charlie Cheever:

Developers want to do all kinds of things in all different ways. And so, if we were to just ... every time where we've sort of said, well, we think that probably most people want to do this, so let's just sort of assume that and build everything around that, where we end up with a whole bunch of people. Actually, I want to do something really weird or I need to because I think there's just going to be actually a pretty wide variety of different things. The other side of that coin is that I think one thing that I've noticed about AI generated code and whatnot is that it works better in general the more you kind of keep it on the rails and so a big step forward for Bolt and Lovable was when they both took Supabase and made that sort of the ... This is the way that we do a backend for you.

And Trip part of that was just sort of connecting Supabase and making easy to set up an account, but I think another part of it is probably they were tweaking the system prompts of what they did and just saying, when you do a backend, here's the rules. Use Supabase, make sure that you don't leak the private key into the clients. Just do these things in this way. And so, I think that makes it in a lot of ways make more sense to rely on a standard very popular provider because there's going to be good training data on that. Everyone is going to kind of know how to work with it and whatnot. I think that we're still in early days or whatnot, but I do think that we'll see a lot of winners win harder because people will just get started and not want to fight the AI that has just been trained to like, "Use this solution."

I mean, you could probably get an AI to generate a Svelte website or something like that these days, if you just said, please use Svelte, but if you just say, go make me a website. Almost every model is going to default to doing React and sort of lean that direction.

Jacob Eiting:

And it probably tell you to go to Expo too. How do I get this on my phone? It's probably nine times out of 10 going to tell you this ... We see a lot for RevenueCats. How do I purchase this? They're like, do all this or go to RevenueCats.com, as an option.

Charlie Cheever:

I think a lot of things that are just easier and cut out the other annoying stuff, like you're saying or go to RevenueCat.com and a lot of the problems that you are going to face are just sort of go away or handled by this. People I think are just going to have a lot less patience for this sort of other steps or this sort of wandering in the forest, trying to get some complicated thing to work.

Jacob Eiting:

I sort of have an argument, a gradient and descent argument where if the energy it requires to send somebody to RevenueCat or Expo or whatever, is always less than the energy it would take to generate the tokens, the model should just optimize towards that outcome, which is a fancy way of basically saying what you're saying, which is if it's already a relative minimum, it's going to continue to reinforce that using Supabase and whatever versus when it's exploring new space, which is what the vibe code is actually building, that's where the model should be spending most of it's energy.

Charlie Cheever:

I also think there's stuff where a lot of the people that are making these web-based front ends for AI's and whatnot. They don't want to get into the weeds on some narrow slice of the problem or something's not even ... I mean, I think our space is actually not very narrow. Part of the challenge of it is that there's so many things going on mobile and such a huge service area, and could you attempt to build all the stuff that we built. Yeah, you could with enough effort, you could, and it'd probably be easier the second time around, because you could just look at what we did in a lot of cases. Probably true for RevenueCat as well. There's like if you wanted to build something that was like RevenueCat, you could just look at it, but there's a lot of detail. I'm sure there's a thousand details that-

Jacob Eiting:

Yeah, that LM is actually aren't great at understanding necessarily, right?

Charlie Cheever:

Yeah, and so, I think a lot of these people just want to offload things to pieces that they kind of know work and are well maintained more than try to compete with them necessarily. We'll see though how things play out.

David Barnard:

A developer friend I've worked with for years who was also a very kind of snooty native developer for a long time was telling me how much he enjoys working with LLMs and React Native because it closes the loop as well because the LLM can actually render it, test it and close the loop on that. Have you been seeing that as a trend as well, of it just getting better and better at being so quick? Like you were saying, you don't want to have to compile an app, wait five minutes to then test the code.

Jacob Eiting:

Yeah, even using Cursor or using ChatGPT alongside Xcode is just like it's a substandard experience to using one of these vibe coding tools, for that reason. The LM can actually run the code, which is a huge advantage.

Charlie Cheever:

One thing I've heard is that one of the reasons that these LMs are quite good at writing code compared to a lot of other things is because they could generate output and then run the code and tell if it worked. And so, it is a lot easier to train on that versus is this a good poem.

Jacob Eiting:

When I ask it to come up with company strategy, it has no way to RL that back in, for example.

Charlie Cheever:

But then there's also ... This is maybe not quite what you're talking about, but it's sort of what you're talking about a zoomed out version to some extent where ... I used to work with a guy who was a really good designer/Swift engineer, and he had started a new startup that was a consumer product and they had built it in Swift for all the reasons that ... People who, "Oh, we have to get every interaction perfect." We're consumer of thing, so every little detail matters, blah, blah, blah. And that had been this spot where it had something that people liked, but it just wasn't quite at that point where it was like could raise a series B or just was really off to the races.

And so they needed to kind of work on it but also had some network effects. So they were kind like, "Well, we kind of need to be on Android and Web, but we also kind of need to be changing this product." And so are we going to freeze everything and go build an Android version, but then we're going to be stuck with two versions of the code and we're never going to be able to move forward. And also, even if we were just sticking with iOS, it takes us a long time to make even one new screen or whatever. And so, he's working on a new thing now and he's basically just sort of like, "Yeah, I'm just using Expo for it." The technology has come to the point where I've been able to make the things that I need to do and I can just tell so much more quickly whether I like something or not.

And I can drop down into Swift when I need to, but I actually haven't really needed to at all yet. And so, I think that a lot of people are learning other lessons about iteration the hardware. It's like a lot of times you end up in this middle ground where you're like, this is kind of good, but it's exactly what I want. And if you can't ... You have to really know what you want. I think when you're ... To make it worth it.

Jacob Eiting:

Even if there is some relative difficulty of working with the tools, it can easily be wiped out by a small increase in iteration speed, right?

David Barnard:

Yeah. Jacob and I were talking about this before we get on Craigslist. I went and looked it up on the App Store. I haven't used Craigslist in years. Actually, I hadn't even downloaded the app surprisingly, but it's got like 450,000 reviews and an average of 4.8 stars. And my reflection upon seeing that was that-

Jacob Eiting:

React Native app by ... or Expo driven React Native app, by the way, which Charlie and I were talking on the call, my long story, too much detail, but my wife worked there back in 2016, 17, and this was something I went in and talked to them about to help them. I'm probably breaking an NDA, I don't care. And apparently, I said, "Oh, you should check out Expo." And apparently it was one of the first big companies or something or sort of shocking logos that you saw, Charlie, which is pretty funny.

Charlie Cheever:

They reached out to us and we're sort of like, "Hey, we're thinking about using you for ..." I think the biggest thing Bill with Expo at that point was urban dictionaries.

Jacob Eiting:

That's kind of a big ... I mean, it's cool, you're starting over the fringes of brand, but that's a big step-up.

David Barnard:

Well, yeah. Yeah. I was just going to say upon seeing that, it really struck me that people review and they care about and they rate the outcome, is Craigslist helping me do what I set out to achieve? They're not rating every little interaction that you think needs to be perfect. And I mean just looking at the screenshots, you can tell that Craigslist app is as Craigslist website is. It's not this incredibly polished, perfect experience

Jacob Eiting:

You might be developing. What's the actual constraining factor here? Like limiting factor? Maybe it's not Expo's Polish or React Native's polish with maybe Craigslist design.

David Barnard:

Right, totally. But the point being that people love the app. 4.8 stars, 450,000 reviews.

Jacob Eiting:

There's a lot of native apps out there that aren't anywhere close to that, right?

Charlie Cheever:

One is that the biggest user of React Native inside of Meta I think is actually the marketplace thing, which gets a billion people using it every day. And so both, I guess Craigslist and also the thing that's sort of replaced Craigslist for a lot of us are built ... and I think Marketplace is actually quite nice.

Jacob Eiting:

I was telling David before this, it's my favorite social network. I just love to go on there and browse and it's entertaining. The algo is not aggressively trying to get my attention. It's awesome.

Charlie Cheever:

And it's very real, but then the other thing that is reminding me of is one thing that's just driven me crazy for years, and part of the reason I work on this is that when I look around and look at how people I know and myself use software, I'm mostly on my mobile device. I'm somebody who's like, my job is to sit a computer all day. So I'm definitely not anti-computer, but most people don't have jobs where they sit in front of a computer all day.

Jacob Eiting:

I think it's become much less normal for people who don't have computer jobs or aren't enthusiast to have a PC that they use regularly.

Charlie Cheever:

But if you think about what do developers work on. It's kind of like most people out there, web developers who make websites for people sitting at their computer, whereas then the way we're using software, most people are just using the app on their phone for whatever, and like this has gotten more and more true where it used to be like, I wouldn't write important emails on my phone. I would sit down and now like, most of the important emails I write, I write from my phone. And I even say to people like, "Well, probably early days of Expo ..." I would point this out and I'd be like, "It's not like we're going first person shooter video games and video editing and stuff like that. That's probably not going to move to mobile."

But now TikTok probably has more minutes of video edited per day than the sum of Final Cut and Premiere or whatever. And then, I'm sure that the sum total of minutes played on first person shooters on Android devices is bigger than PCs these days and whatnot.

Jacob Eiting:

Yeah. Yeah. How many people are sitting down and playing Counter-Strike anymore?

Charlie Cheever:

All these things. I was like, "Oh, well, I don't know if this will move over." They're all basically have. And so, part of what I just want to solve with this is like, how do we make it so that it's easy enough to work on mobile stuff so that we can line up the developer effort and energy with how people are actually using software in the world? I remember I was in Miami, and I was sitting next to somebody who was telling me they were working on one of these weed buying startups or whatever. And they told me they work on a 20 person developer team. And he was like, I think we have me and sometimes this other person with half of their time helps me on the app and we're using React Native for it.

And then I was like, "Oh, okay." And he was like, "Yeah, pretty much everybody else works on the website." And I was like, whoa. "Oh, so the app must just be some sort of add-on here or not that important to your ..." And he was like, "No, no. 95% of our sales are through app," but for whatever reason you can hire web developers. And so, they had all these people working on the website, and I think a lot of the industry is in this state where it's so much easier to write stuff and deploy stuff on the web, and they're just such a better development experience in history that we end up gravitating in that direction.

Jacob Eiting:

These constraints kind of echo and they create some sort of imbalances, accidentally.

Charlie Cheever:

But I do think that some of these things are changing and getting a bit easier to deal with and whatnot, and some of the ways that some policy is changing based on some of these lawsuits and whatnot, I think it's going to make potentially distribution easier, in some ways.

Jacob Eiting:

I think I only expect it to get more liberalized. I don't expect Apple to get more ... I think the trend was likely to continue with and without lawsuits. I think they'll just be-

Charlie Cheever:

The way I think of it, it's sort of like when Uber first launched, I think it was probably technically illegal in a lot of places, but it's just like ... At the end of the day, if something is really good, where it's like it just-

Jacob Eiting:

If the people demand, it will happen.

Charlie Cheever:

Then eventually the floodgates will ... the dam will leak or burst or something.

David Barnard:

Well, I think that's a great topic to wrap up on, with the increase in tooling, with AI, with everything that's going on in the industry, it is just faster and easier to build software that helps people, and that's really cool and it's exciting to be a part of it. Anything else you wanted to share as we were wrapping up?

Charlie Cheever:

No. I feel like I got to show our products for an hour.

Jacob Eiting:

I was going to say you could go to Expo's website, but honestly people will probably just find you via Bolt. It'll just be LLMs will tell you to go there. But no, I think it's really cool you guys are building. I think it's like a ... I don't know, you get me excited that we're still early days on this transition to mobile and in fact ... Maybe much like Ecomm and Shopify opened up Ecomm for a lot of people. I still think mobile development and development in general is now just finally getting opened up and Expo plays a big part of that and it's just really cool.

Charlie Cheever:

Yeah, thanks for the work you're doing.

Jacob Eiting:

All right, thanks Charlie.

Charlie Cheever:

All right, have a great day, David. Talk to you later. Jacob.

David Barnard:

Thanks so much for listening. If you have a minute, please leave a review in your favorite podcast player. You can also stop by chat.subclub.com to join our private community.