Paul:
Hi there and welcome to PodRocket. I'm your host, Paul, and today we have Evan Bacon with us who is the manager of dev tooling at Expo. He's a Lego master and the firm scratch author of what we now know is the Expo CLI, which is pretty damn cool. Welcome to the podcast.

Evan Bacon:
Yeah. Thanks so much for having me. Thanks for that lovely introduction.

Paul:
Yeah. We wanted to make sure to give you a good one because I mean, Hey, from scratch author of the Expo CLI, that's a good ass talking point. If you asked me, that's pretty great. Well, anyway, we're going to talk about Expo. We're going to talk about a great project that Evan's been involved in, which is the new router that you might find in the Expo app. Some about EAS for hosting your application and all the great things that come around with mobile development and how Expo can empower you. So when did you start at Expo, Evan? How long ago? Years or months.

Evan Bacon:
Oh, man. It's almost been five years. I think I joined when I was 19.

Paul:
Wow. Okay. So this has been your main home base. You're an Expo guy.

Evan Bacon:
Yeah. Well, I had a job prior to that where I worked at a design agency and we used Expo there and I worked there for two years or something. So most of my professional career's been using Expo.

Paul:
All right. So you're really the guy to talk to because you grew up in Expo when [inaudible] our brain form and you're 19, you breathe, speak Expo. So really quick, what is Expo for anybody that isn't familiar with it?

Evan Bacon:
Yeah. So Expo itself is an MPM package, which you can install in a React Native project. And it enables just a ton of functionality that we think is really critical for building a great mobile app that scales for lots of users and then also scales to whatever your team size is. So for instance, it adds features like the Expo Go app. So you can build and share your app instantly with anyone around the world without having to do any extra code signing or any kind of builds. It adds functionality like a Swift and Kotlin API. So when talk about React Native, they're like if there's features you don't have, you can drop down to native, but in React Native without Expo, you drop down to C++, which isn't quite what modern native development is.
And then it also has features which just help deliver on the promise of React Native, where you can write an app and react and then have native. So this thing called prebuild, which sits between react and native and it's a bundler for native apps. So it'll generate the iOS and the Android projects that are required to run the react code. And all those functions are just bundled up in this package. You can install it in any project and then it makes it pretty great.

Paul:
It's like an integrated development environment and almost like some testing ecosystem that lives and breathes with your project as you're developing it.

Evan Bacon:
Yeah. I mean, I could have also summarized it as a framework. Yeah, we do have an IDE in the browser called Snack, which is actually the fastest way to make a native app of any kind. You just open this website and you connect your app and now you're doing native development, but outside of that, it is mostly native tooling that builds on top of React Native.

Paul:
So when you say native, what are we talking about here? What does native mean? It's a heavy word in this context, right?

Evan Bacon:
Yeah. Yeah. Sorry. We're talking about iOS and Android.

Paul:
Okay.

Evan Bacon:
 So those are the two platforms that React Native supports out of the box, that covers the majority of people around the world. And then Expo also adds support for web just because we think it's a really important platform and everyone who uses iOS and everyone who uses Android, they also use web. And that covers a majority of where your users are. And if you want to make an app, which can be successful, you have to go to where the people are. So we support those three platforms out of the box.

Paul:
So when you're writing native code, what's the value add that a program or developer team can expect to have, if they begin to start their creation with a native code base?

Evan Bacon:
If you want to create an experience, which is just really good and you want to share it with a lot of people, the best way to do that is with the website. The web is just missing a ton of functionality, mostly because the platform vendors don't add it to the browser. And also the browser, it's got this backwards compatible spec and it moves at a certain speed. So when a feature dynamic islands comes out a couple days ago, it, that will probably not be available to the web for many years, if ever. So if you want to utilize exciting new technology like that, you need to build a native app.
And what we find is that that switch is not as easy as Web++. It's more like you go from this incredible developer experience of web where you can just build and share your app instantly, and then you drop down into this experience where it's very slow rebuild times and it is very, very difficult. So what we try to do with Expo is find some middle ground there, where you can get that developer experience, but then you can still access new and emerging features as they come out like app clips and Safari extensions and dynamic islands, stuff like that.

Paul:
So I guess I have my brain oriented around the idea that Expo is super geared just towards iOS and Android, but it sounds more hold heartedly ... it's this development platform that allows you to access these lower level features that you might find that React Native supports that you wouldn't find in just a purely web context.

Evan Bacon:
So React Native, it's an engine, and an engine's really good for powering a car, but it's not super great for getting you places. And what I mean by that is if you ... React Native, it provides the ability to run JavaScript and run react code on a native app. So if you want to Expose native functionality, you can write a native module and you generally write that with a macro. There's just a lot of things missing there. You still have the ability with just React Native, to have a lot of fatal crashes. You have the ability to pass a string to a function that expects an object and then natively will attempt to parse it incorrectly. And then it will blow the app up, which you can't really do on web anywhere.

Paul:
Is that what people talk about with the interactivity of what we're seeing as web assembly modules now? They expect certain inputs and you have to call and invoke them. And the correct way is JavaScript's not necessarily typed, but russ is-

Evan Bacon:
Yeah, generally in areas where you will find a native crash, it's usually related to types because by default, you want a system where you're not doing that type checking by default. So in cases, for instance, if you're sending information back and forth, you're trying to do maybe some machine learning, you're trying to parse a bunch of array buffers with image data, in those cases, you don't want to have to do a type check every time. You just want to be sure about it. But in all other cases for a better developer experience, you want everything to just fail gracefully with a very empathetic error message, which tells you how to work. And you want that error message to be in a place where you can see it. Usually in a fatal crash, there will be no interface for you to see what crash you have to connect it to something and reopen it. So Expo adds a lot of that infra around the react need of experience, and it makes it very, very reasonable.

Paul:
Yeah, a nicer experience. So would you say Expo could be used really by any developer that's looking to be on the bleeding edge of web and mobile development through a JavaScript lens?

Evan Bacon:
Yeah. If you're trying to be on the bleeding edge, and if you're trying to build an app that really scales to a ton of people and just grows, that's really in the DNA of React Native, unlike many other ways to build a native app. There's not too many opinions to build a native app. There's a lot in the web ecosystem, but in the native ecosystem, there's a lot fewer. And what we find in reality native is that these are the things that were created by these large infrastructure teams, especially like Facebook at the time. And they're like, how do we make this app, which can scale up and serve the most users of an app ever?
 And so then you come out with React Native, because it can do things that just by default are very difficult to obtain otherwise. The JavaScript all runs off the main thread and then it gathers up all the UI operations and runs those on the main thread. So effectively you're just deferring all information off of the UI thread. Whereas if you were to build an app just in swift, everything runs on the main thread and then you go and you progressively defer information over time.

Paul:
So instead of being blocked at the end, it's going to, almost like a scheduler and a CPU, put it at best effort.

Evan Bacon:
Right. So these are very difficult architectural things to create otherwise, and you just get those out of the box with React Native. So in terms of scale and really supporting just tons of users, React Native is the way you want to go.

Paul:
Enjoying the podcast? Consider hitting that follow button for more great episodes.
So it might even be a good idea to start your app with React Native if you're like, Hey, I want this to be an easy experience. This is going to work on the web. This is going to work on an Android. This is going to work on an iOS. I'm going to have the ability to grow my branch tree in any direction where my users are. You can start React Native and be confident that there's that communication line between the lower layers, excuse me, to grow which direction you need.

Evan Bacon:
Yeah, I think you should always start React Native with the Expo package installed because it's the best way. For instance, when you install Expo, you get the Expo C alliance side of it, so you can do MPX Expo start. And that differs from direct native start in the way that you can use this app called Expo Go, which you can download from the app store and you can just open it immediately. Otherwise, you have to build the app locally, which if you're on a Windows machine, it means you can't build for iOS. And then even if you can build, it takes two to three minutes per platform, just for a basic build and that's on a pretty fast computer.
So the Expo Go app, think of it as a reusable run time. So in a way it's a development browser and it has all the code that you need for the majority of apps. And you can open it up instantly and then you can share that instantly with the people who you are working with on your team. So, that's the fastest way to get going. Right? Any other way is there's too much complexity upfront. There's too much cognitive overhead to get started. You have to install X code, you have to do this maybe eight, 12 hour setup of configuring your environment with this. You just need node and you can get going.
And then over time as your app and your project scales, you can do things. You can stall packages and then Expo has this, like I was talking about earlier, this bundler called pre-build, which will look at those packages. And then will say like, okay, this is a camera package. And so this camera package says it needs a permission message for the camera and then it needs this other configuration on Android. So it'll collect all those configurations up and then it will generate the iOS and the Android codes that you can build it locally with your custom situation, whatever you need. And that's really great for white labeling, scaling, upgrading.
 One of the biggest difficulties people have when using React Native is upgrading because you just have all this native code that you generate and you're like, good, I don't need to know how that works. And then a few months when you have to upgrade it's like, now I need to know how all of that works. So with this bundler, you can keep those folders generated and basically get ignored and just continuously generate them whenever you need. And then that system, it scales up incredibly well. So you can add thousands of libraries, you can remove libraries, it takes all the orphaned code with it. And yeah, the infrastructure there is pretty optimal for building an app.

Paul:
So it sounds like for the Expo Go, what it does is it says, all right, if you're running an Android, I have 83% of the code you would probably use for this native platform for your thing to work. So if you're writing it in this bubble of 83%, we can just run it right away. You don't need anything. We can emulate it. We can send it to your device. It's all good. But if you're outside that bubble, it needs to ... you'll need Xcode, right, if you're on iOS, because it needs to actually recompile it?

Evan Bacon:
Yeah. So actually at that point you have two options. So one is you can keep going with Expo Go, and then you just write your code defensively. So for instance, maybe you'll add a Bluetooth package and then you'll say, okay, if this Bluetooth code is available, then enable this feature. And if it's not, then just skip the feature. And a lot of people do that so they can continuously share their app over Expo Go with people on their team, just because it's substantially easier.
And then the other method you can do, and you can do these both simultaneously, is you can build a custom development client. So that's creating the exact run time that you'll build for production. You can build that locally and then you can install this React Native package called Expedite Client, which adds the ability to basically open URL. And it's basically adding Chrome dev tools to a library. So when you open your app, you don't have to have a dev server running. You select the URL of the dev server and it will load that app in there. So you can create an ad as much custom dev code as you need.
 You can build that in the cloud with a service we offer called ES Build, which as you would imagine, it just takes your code, it uploads it, it auto code signs it, and then it returns a binary, which you can install. So for Windows users or people who maybe you just want to have previews of your build on every commit or something, you can use that. And then for everyone else, yeah, we have this ... in the CLI there's these run commands, which just utilize Xcode and Android Studio. And then they have a bunch of resiliency built into them.
So for instance, if you were to build your project in Xcode, it isn't aware of node modules. It isn't aware of the fact that the majority of your project is in libraries. So it will show you 1400 errors, or sorry, 1400 warnings about things which are just not relevant. So our run commands will do things like they'll auto code sign and then they will add that context back so that you're only seeing information which is relevant to your project. So you go from 1400 warnings down to zero. So yeah, when it comes time to add custom native code, you can build locally, you can build in the cloud, however you need, and you don't really lose out on anything. It just, that's the natural progression of a project.

Emily:
It's Emily again, producer for PodRocket, and I want to talk to you. Yeah, you, the person who's listening but won't stop talking about your new favorite front end framework to your friends, even though they don't want to hear about it anymore. Well, I do want to hear about it because you are really important to us as a listener. So what do you think of PodRocket? What do you like best? What do you absolutely hate? What's the one thing in the entire world that you want to hear about? Edge computing, weird little component libraries, how to become a productive developer when your WiFi's out? I don't know, and that's the point. If you get in contact with us, you can rant about how we haven't had your favorite dev advocate on or tell us we're doing great, whatever. And if you do, we'll give you a $25 gift card. That's pretty sweet, right? So reach out to us, links are in the description. $25 gift card.

Paul:
The one time I tried Expo around a year ago, I had to add some custom code and I was compiling it on my laptop on a MacBook. I don't know, it didn't take me 12 hours to set up. It was pretty good. I had a very good experience running Xcode, click and compile, sending it over to the device and it was instantly. Yeah. It only took two minutes, I think. I guess that's kind of long.

Evan Bacon:
Well, setting up Xcode is the part that takes the most time. The actual build is pretty quick. Xcode, I think in the more recent version they ship it now without WatchOS S or tvOS. So it's a bit faster, but it still takes maybe at least two to three hours to install and set up. But you only have to do that one time for your whole device, and then every year when they update.

Paul:
Right, that's the obnoxious thing. Oh, you have to do it every year. But Hey, you can go use the cloud, right, the cloud solution, EAS. So what does EAS stand for

Evan Bacon:
It's Expo application services, and it's pretty dope. EAA is this build service. You can send your iOS and your Android apps there, automatically code signs them. It probably has the most advanced native code signing out of any tool for any framework or system for [inaudible You can say I'm using this merchant ID for my payment or it will see, oh, you have Apple authentication in use. And then when you go to build, it will register with Apple servers and it'll be like, okay, this project needs to have Apple authentication set up. They need to register this merchant identifier. And then this needs to be linked to this project before the build, because if it happens after the build, then the build will just fail and then you'll have to start over. So that's the credentialed part and that's pretty good at reducing the amount of errors that you'll get during a build.
And then for the actual build, it loads in a container which has very optimal caching build in. So you don't have to really worry about global no module caching, local no module caching, iOS build, artifact caching, all that, which usually you'll end up getting into, if you have to set up a CI for your native app yourself. But with this, it's refined zero config for React Native, so you can push and expect a pretty optimal experience.
 And then when that's done, there's this EAS submit command, which just takes the binary and it pushes it to the cloud, or sorry, it pushes it to the app store or the Google play store. So you can do something like EAS build--auto submit and then that one liner will build your app and submit it to the app store. And then you'll get an email from Apple like, this binary is ready for review, which, as far as I know, it's the only way to do a one click, proper native build and submission that is available. And we're looking at making that even easier, moving a lot of that to the cloud so that maybe you could do that from your phone or say merge a pull request and then have that be submitted.

Paul:
It reminds me of the way Docker builds things, where it can distinctively scope out layers and then say like, Hey, this is a piece of functionality we're activating, or we're not activating. We need this in this image or we don's/ if this is cached or it's not cached.

Evan Bacon:
Right. It's like that, but just super optimized for native applications.

Paul:
Right. The whole tangle mess of what you need and what you don't need, depending what target you have for native. I'm not jealous of the folks maybe like yourself that really get down in the weeds there. Sidetrack right here if you're an engineer there. Are you an engineer that works in this space? Because I feel like you get caught between the Apple and Android wars sometimes with things just being difficult when they don't need to be.

Evan Bacon:
Yeah. Yeah. There's an attitude there where people, they're like, if it's not hard, then it's not good. But it's also like, no, I think the apps speak for themselves.

Paul:
Okay, we can move on from that. So if I was making a React Native app, if I'm making a React app today, the first thing I do is install a middleware. I install a router. I mean everybody wants a router for your website. I want a router for my phone app. You're working on a router, so is this thing that you created, will this work for the web, Android and iOS because it's on the native platform?

Evan Bacon:
Yeah, so that's the goal. Effectively, navigation is one of the hardest problems just in native development in general because there's this really complicated view system, and people expect that view system to work. If you were to take everything and render a bunch of views that just weren't native, but then you got the navigation just a little bit wrong, people would be like this isn't a native. This doesn't feel like a native app. The navigation has to be very refined is what we found.
And that's stuff like if you go to a tab and then maybe you open a tweet and then you go to another tab and then you open something, you go back to the other tab, it should still be on that tweet. It shouldn't unload that view. But then if you open that tab and then you tap the tab again, it should pop to the top of the stack. And then if you tap the tab again, it should scroll to the top of whatever page you were at. So there's just all this integrated functionality.
And then it works differently on Android where there's a mechanical back button built into the phone. So now you need to account for that when you're moving around the routing. And in the browser, you can do things where you have a URL bar. So if all else fails, you could still just change the URL and navigate around the website. You can add hyperlinks, there's URLs, and then there's also this built in forward and back button. And then usually when you transition between pages, there's not actually an animation or a gesture driven animation. On Native, there's animations for everything. All pages need to be loaded into memory in order to animate between the two, and just to get all that right is very complicated.

Paul:
I think that's going to change though, in the near ... because I know React for web recently is now soon supporting native style transitions and all that because people want it. Everybody's jealous of the mobile world.

Evan Bacon:
Right. Yeah. In many ways, it's a bit more of an advanced version. But in doing that, they often they skip over something very important, which is the routing. So any Native app can support an incoming URL from the operating system. So for instance, Chrome supports any URL which has HDPS://, or HDP://. If you tell the operating system open twitter.com, then it'll be like, okay, I'll open that in the browser. But you can have FB://, and if you tell the operating system to open that, if you go into Safari right now and type that in and hit enter, it'll be like, okay, Facebook should be opened. And then whatever is on that URL should go to Facebook, and people utilize this to effectively share content.
If you want to grow user adoption and share parts of your app, the best experience is to link exactly to where that content is. Right? If I'm like, Hey, I found this great TikTok and I send it to you, but then I send it to you and then it just opens the app store to the TikTok page and you have to download TikTok, open it, wait for it to download, open it, watch the splash screen, then you're on the homepage. And I'm like, yeah, it's really funny, look up gorilla or something. And then you look that up and then you got to scroll until you find it.
No one wants that experience. You want this experience where I can send you the exact link and then you click on it and then it takes you exactly where you want to go. When the web does this, it's super powerful. And there's very few apps where you just want to watch it download and open up. Even basically any single app that you hear about, there is one particular feature or function that you are trying to get to and you have to do all this to get there.
So the reason more people don't really adopt this routing system is it's really hard to set up. On top of all the native navigation having to be set up, you need the ability to set up and configure routes for each individual screen and feature. Now the web does this really well, dating all the way back to PHP, by having this file system based router. So people who have Next.js Or Remix, they know that you go in, you create a file, home.js, pages/home.js. Now, if you open that website/home, whatever react component you Exported, that's going to be at slash home.
This is great because you can reason about it. You can look at the source code and be like, okay, I see all the pages. I know these all exist. And without even having to run the project, you get a sense for how it works. And you don't have to test and verify that all those links work. You just know that by them existing, they work. And now you can share those URLs with people.
So the idea behind this new route I'm working on is basically that, but for native apps and just universally. So it's very similar to Remix, which has this nested system, because Native really plays heavily into nesting where you'll have a tab view at the bottom and that's at the parent level, and then there will be a bunch of children which live inside of that. And then maybe one of those children has another tab and then there'll be children inside of that.
If you go to the Instagram, your profile, and then there's posts and reels and stuff, that's two nested tab views, so it's similar to that system. But by default, any link that you open will link you to anywhere in the application, just out of the box automatically. So if you create an app, you could be like, here is ... you don't have to tell people, check out my new app. You could be like, check out my jokes app, here's a funny one. And then they can open that and go right to the joke or the video or the product or whatever you want, but that also has its own set of issues.

Paul:
So I have a quick question, if I could interject real quick. So if I'm in Reddit, my Reddit app, and somebody posts a comment and they're like, check on my joke, would that Reddit app presumably need to have your router? Or is that whole thing you just explained where it's like, you can put the app name://?

Evan Bacon:
Yeah. So Reddit needs to implement its own native router in order for you to link in there. And so traditionally the way people do it today is they just set all that up manually. They have this giant manifest and then there's no URL bar for a native app. So you have to manually check by launching URLs to check to see if it works. So you'll actually see ... maybe you won't see this. If you really pay close attention, then you might see sometimes very big apps where actually their routing will just break. You're like, check out this, and this happens, I think a lot with maybe the GitHub app, where you're like, heck out this GitHub file and you click on it and it'll just take you to the GitHub homepage and then you'll be annoyed with it. Right? Or to the app store or something. So yeah, when you do it manually, it's very prone to failure. With this automatic system, it's all in the file system, so the entire thing is generated without any room for human error, which is pretty sweet.

Paul:
Just like the NGINX does it. It's like you could set up a file system proxy or road, or yeah, like you said, Next.js. So it's all statically there and it's just like, this is it, go address. Okay.

Evan Bacon:
Yeah. So we're excited to bring that to Native, but then there's also ... it gets even more complicated after that. Okay, say I send you a link to a TikTok and you don't have TikTok installed. If you go to open that link, nothing will happen. It'll fail. It won't take you to the app store. It won't know what to do because that app does not exist. So to combat this Apple and Google made their own systems because of course they're not unified. One's called Universal Links on iOS, and it's called Deep Links on Android.
 And the way that these work is you effectively ... you can have a website. And then that website has a manifest, which says, okay, certain links in my website map to certain links in my native app. And then you can publish that, and then an Apple bot scans that and finds those. And then on your native app, you submit that to the app store, you code sign to register those links in that website. And then if you get all of that correct and nothing fails, then I can send you TikTok.com/myTikTok. When you open that, if you have the Native app, it will take you into the native app. And if you don't, it will keep you in the website.

Paul:
So we need a third party CICD orchestration ballet to make things work.

Evan Bacon:
Yeah, it's the most complicated pattern, but if you get it all right, then you are able to open up and share and just grow user adoption of your app way, way faster than any other. So giant companies will do this, but it's just too hard for an indie shop or just any reasonable size project. Even if you were maybe a food app or something, maybe you work like BMW, it wouldn't be very reasonable to set all this up. It takes a lot of time. So this new tooling would effectively just do all this automatically because you can deploy the app to iOS Android web. On iOS, if you use ASE build, it knows how to code sign and register all these URLs for you automatically. When this router is done, it will say, okay, all these routes exist.
Usually what people do is their routes won't be exactly one to one. It'll be like TikTok/video?, and maybe TikTok has it right, but usually people will do something like that. With this, it's just every single route matches every single version of ... you can access anything. So for instance, maybe YouTube would be like, they'll support going to a video, but they won't support going to a profile or going to a playlist or going to a particular video in a playlist just because it is too difficult to implement. It would just be out of the box. And then on top of that, when you take a step back, that's I think the grand ... if all that worked, it would just be a really incredible system, which I think it'll work pretty well. But if you take a step back, it's just like, it's also pretty hard to set up routing and navigation right now, and this just makes it easy. You just create a folder and you create a file and now your navigation's going, so a lot less boiler plate.

Paul:
Do you think that you could see issues? Because you're presumably interacting on a deeper level with the file system and how these end nodes or devices are reading the static content. Do you think you might run into issues with the jail broken people out there or the rooted phones and the way the file system might be permissed or underpermissed?

Evan Bacon:
Yeah. So the file system, that's a developer facing implementation. So one thing that makes this a bit harder to implement than if you were to do it web only, for instance, Remix or Next, is that those have a server component, but a Native app needs to run all offline. So it's smoke and mirrors to make it work on Native. And then on web, it just works exactly as you would expect it. You hit a URL, you ping a server, the server's like, okay, that file maps to this, and you return it. In native, a lot of that needs to be handled by manifests and offline routing.
So as a developer, you build it in a file system, but then it compiles down to a system which just works with intercepting URLs. So you pass an URL, and jail broken or not, it's more of an operating system implementation. And I don't think anyone is actually modifying how URLs are handled. I think maybe some people modified. Well, yeah, there's this one thing where on Android, if you were to open a link to a browser and you have more than one browser, it'll be like, which browser do you want to open? And on iOS, it doesn't do that. It's just like first come first serve.
 So you could create an app which handles HDTP and then you could just publish that. I think Apple actually at the app store review level checks for that, but there's a number of ways to exploit that, and then you could intercept URLs going to other apps. So I think some people in jail breaking, they do add that switch or dialogue in so you can pick, but that wouldn't affect this. That would just make it work as it should.

Paul:
Gotcha. Gotcha. Okay. So, they're doing your thing a little bit.

Evan Bacon:
Yeah. They're helping to better support this concept of opening universal links.

Paul:
Right on, okay. So is this out now? Can people use it now?

Evan Bacon:
I've been teasing it for a while. I'm probably going to publish a working group RFC repo to the Expo repo or the Expo [inaudible] on GitHub this week.

Paul:
Yeah. We should include a link to that. Is it going to be a forum RFC where people can read and post?

Evan Bacon:
Yeah. It'll have GitHub discussions and people can post about it because with a convention like this, there's not a lot of conventions in native development, so we want to make sure it's right. We want to make sure it doesn't have to change too much. So yeah, it'll be in the Expo org, probably Expo-router. I don't know when the podcast will come out, but it may come out before the podcast comes out and then I can send you the link.

Paul:
Well, Evan, is there any social or blogs of things that you do if people want to follow what you're developing on besides your GitHub?

Evan Bacon:
Yeah. Yeah. I'm on Twitter at baconbrix. I tweet a lot about native development, a lot of new features we're working on. And then the GitHub is great if people are fans of Expo, starring the repo helps. For some people who want to use the project, they look at the stars and they're like, oh that's not enough stars for me, I guess.

Paul:
Damn.

Evan Bacon:
Yeah.

Paul:
You're right out the gate.

Evan Bacon:
Yeah. This is what I heard the other day, so now I've got to promote starring the repo.

Paul:
Okay. Yeah, starring the repo people. I mean, I will again say I'm not like Evan. I'm not from Expo and it was a great experience if you want to at least try out mobile development. I feel like mobile development is a big mountain when you're looking at it, because it's just so much about web and they're like, ha, ha, you know nothing, welcome. And Expo really walked me through it and it felt like a great experience to learn the basics. Enough was abstracted at the beginning that made it palatable.

Evan Bacon:
Yeah. I think if you look at the opinions that we lean into, a lot of them, they take from the best of web. So for instance, TypeScript, it has this first class TypeScript support. If you convert file to TypeScript, it will be like, install these TypeScript [inaudible] and you can write TypeScript. If you create a native app, you usually have to go through some sort of wizard or something with Expo. We just have one of the classic create Expo app, create app type packages, installs really quick and you get going.
So it should feel very familiar to someone who knows a lot about the web. You should be able to utilize, not just your surface level web knowledge, but pretty deeply integrated web knowledge. You could be like, okay, how do you do suspense in this paradigm? And you should be able to be like, okay, you do that here or maybe you don't do that because we had this other system. For instance, one is pre rendering. People will ask how to pre renderer in React Native, but it doesn't have HTML or CSS, so pre rendering is an HTML and CSS level system. So in React Native, there's no overlap at all, but you should be able to carry as much of that knowledge over as you can and create a robust experience to match.

Paul:
Right on. So it should be good for intro people. Stay tuned for your router. Follow Evan at baconbrix. That's what it was, right?

Evan Bacon:
Yeah. baconbrix.

Paul:
Okay, star the repo.

Evan Bacon:
It was inspired by my Lego days.

Paul:
Oh, right. Yeah, because you're a Lego master and we're not just kidding about that, Evan is a Lego master. But yeah, baconbrix. And then yeah, are there any other shout outs or plugs you would want to give before we wrap it up, Evan?

Evan Bacon:
Yeah. So I think one ... we got this new thing that we just created. I'm not working on it directly around. It's called EAS Metadata, it's pretty sweet. It lets you manage your app store presence, so categories, title description. And you can do stuff like maybe automate your change log from your commits and push those to the app store, keep it all in git. And in the future you'll be able to do stuff like auto localize all your metadata and submit it to every app store or automate creating screenshots and updating them on Commit and stuff like that. So it's pretty cool. That one's actually out so you can use it today. And a bunch more functionality to come, but I highly recommend checking it out if you're interested in ... if you're using React Native, this is a pretty sweet feature.

Paul:
Like mass distribution, right? Yeah. Oh, yeah.

Evan Bacon:
Right, yeah. On the web, you get this for free. You're just like, here's my website, you host it, and then it goes to everyone. But on Native it's like you need tooling to auto localize everything. Otherwise, your app is not available to the majority of the world, which is not ideal for building a product.

Paul:
One more time, what's this, EAS Metadata? That's the name?

Evan Bacon:
 Yeah.

Paul:
Okay, one last thing to throw in there. All right. Well, Evan, thank you for your time and for talking to us about Expo, and hopefully some people will come star the repo, right?

Evan Bacon:
Yeah, maybe I shouldn't done that in there. Whatever. Yeah, thanks so much for having me, it was great.

Paul:
Thank you.

Emily:
Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you there would be no podcasts. And because of that, it would really help if you could follow us on Apple podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts.