Jamon and Robin, joined by new guest-host Bryan Stearns, interview Brent Vatne about the new EAS service from Expo!
Jamon and Robin, joined by new guest-host Bryan Stearns, interview Brent Vatne about the new EAS service from Expo!
This episode brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.
Helpful Links:
Connect With Us!
Jamon Holmgren:
Hey everyone, welcome to the React Native Radio Podcast where we explore React Native together. I'm your host, founder, and CTO of Infinite Red, Jamon Holmgren. I am located in Vancouver in Southwest Washington State. I'm on the React Native core team and also primary maintainer of MobX-state-tree. I'm joined by my mukuva co-hosts Robin, not Harris, not Adhithi, unfortunately they didn't make it. But I did bring in a guest co-host, Bryan Stearns. I'll introduce him in a second, “mukuva”...
Robin Heinze:
First, I need you to back up and define what you just called me.
Jamon Holmgren:
“Mukuva,” I am learning Finnish. I am learning Finnish and mukuva means nice, kind, et cetera. “Mukuva” is ... I like the word, I like saying the word “mukuva”. It sounds really cool. So if I said “
sinä olet mukava,” that means you are nice.
Robin Heinze:
I'll take your word for it.
Jamon Holmgren:
The person speaking there was Robin Heinze. She is a senior software engineer. She is located in Portland, Oregon, and works at Infinite Red. She specializes in React Native and podcasting. What is up Robin?
Robin Heinze:
Not much Jamon, just waiting for the incoming blizzard they say is coming.
Jamon Holmgren:
Right? Yeah. We are supposed to get hit really hard. They canceled school already without a single flake hitting the ground.
Robin Heinze:
You know they're pretty sure it's going to be bad if they do that.
Jamon Holmgren:
Yeah. It's supposed to get bad. The kids are excited though. Also joining us today is Bryan Stearns. He is going to guest host today. You may see him on the podcast from time to time. I'm kind of excited about that, getting him on the program. Bryan's been doing this a long time. He worked at the very first computer store in the world in the 1970s, worked for Apple from the Apple Two days all the way through Newton.
Jamon Holmgren:
Did Ruby on Rails for a decade and has been an Infinite Red core team member for the last couple of years. Bryan now lives in Portland. From the Apple Two to React Native, not much has changed, right, Bryan?
Bryan Stearns:
Pretty much not. I dropped off my punch cards at the end of the day and hopefully get my output the next morning and everything's fine.
Jamon Holmgren:
I love it. I love having Bryan around and you on the podcast cannot see this, but he just held up a punch card, I kid you not on Zoom here where we all are. This is fantastic. Bryan brings a lot of perspective to what we're doing here. There's a lot of new stuff in technology of course, but there's some things that have been around for a long time. It's great to have him with us.
Jamon Holmgren:
But it's not just as hosts, but we also have a special guest today, and that is Brent Vatne. Now Brent has actually been on the program, but it's been a long time ago. 2015 was the last time that he was on React Native Radio. And that was prior to Infinite Red taking over, which was more recently. Brent is a developer at Expo, a core contributor to React Native, primary maintainer of React Navigation.
Jamon Holmgren:
He lives in the other Vancouver, the one in Canada that you may also know as Gastown. I was waiting for Brent's expression on that one, Gastown. Have you ever heard that Vancouver used to be called Gastown?
Brent Vatne:
I know we have an area called Gastown that is like a popular neighborhood for tourists, but I didn't know that people actually called it Gastown.
Jamon Holmgren:
That was its original name before you stole it from us. We both live in Vancouver, so that's kind of fun, but yeah. So Brent is awesome. Brent's been around for a long time in the React Native community and actually spoke in the first chain React as well, which is where I met him. So I'm very excited to have Brent on the program. Before we go into that, this episode is sponsored by Infinite Red.
Jamon Holmgren:
Infinite Red is a premier React Native design and development agency located fully remote in the USA and Canada. With years of React Native experience, since it was released and deep roots in the React Native community, Infinite Red is the best choice for your next React Native app. Hit us up hello@Infinite.red, you can email me directly jamon@infinite.red. And don't forget to mention that you heard about us through the React Native Radio Podcast.
Jamon Holmgren:
Also Infinite Red is now hiring React Native engineers. If you're a senior level React Native engineer located in the US or Canada, go to careers.infinite.red and fill out the fancy new form that I made.
Robin Heinze:
It is very fancy. I tried it.
Jamon Holmgren:
Yeah. The only problem was I couldn't get HTTPs to work. So I hope I fixed that before this episode comes out.
Robin Heinze:
Infinite Red, stealing all your data.
Jamon Holmgren:
See, this is why we need more engineers. I actually think it's a problem with DNSimple. Anyway, let's get into our topic for today. Today we're going to be talking about advancements in Expo. Brent, can you tell us a little bit of the history of Expo? How did it start? Who are the founders? Why was it created? Sort of what's the mission? Give us kind of an overview of what Expo is all about.
Brent Vatne:
I'll give you the short version. So it was founded by Charlie Cheever and James Ide. This was back around 2014. They were kind of exploring it as a kind of way to improve the state of mobile development. Charlie was previously working on Quora, where he was responsible for leading the teams and building the mobile apps. And he was a co-founder at Quora and I guess had a lot of experience working with the product from the start.
Brent Vatne:
And he kind of went from working on the website to working on the mobile app and found it to be extremely painful in comparison to working on the website. And then once he released the iOS app, he found that building the Android app was not as easy as you would expect from having already completed the iOS app or at least not as easy as you would expect as a web developer without kind of experience in that area. And so after his time at Quora ended, he kind of spent some time just learning more about the mobile space and exploring that.
Brent Vatne:
And got together with James to try and figure out like what they could do to improve the state of cross-platform mobile development. And they were actually building something similar to React Native at the time that React Native was released. And I think they cleverly identified, well, why should we build this thing totally separately? Let's just combine efforts with this other project since they were already big fans and users of React JS on the web.
Brent Vatne:
So, that's kind of how it started off. The project itself has changed a lot over the years. We had kind of a focus towards originally building sort of a browser for Native apps and due to, of course, limitations on certain platforms with certain companies, you are not always able to do everything that you might want to do when distributing an app such as the app browser on the app store. And so that model has essentially gone away and we're entirely focused on enabling developers to build cross-platform apps as quickly and with high quality and work on teams and basically all of the great things that you would like to have when building a mobile app.
Brent Vatne:
We're just trying to identify all of those pain points and all the areas where we can make things better and kind of try to handle that accidental complexity of building these apps for developers where possible and make everyone more productive.
Jamon Holmgren:
Yeah, that's interesting. I didn't actually know that Charlie and James, the original idea there was to actually build something like React Native. That's kind of an interesting angle that I hadn't heard before.
Brent Vatne:
I think it's similar to how Charlie at Quora had built something similar to React at the time. And so that's sort of ideas. I think that a time comes for an idea and multiple people kind of built this similar sort of thing at the same time and then ultimately one or two or however many solutions the marketplace can support and end up rising to the top and having some staying power.
Jamon Holmgren:
Yeah. I see Expo as being very much a kind of a layer on top of React Native that it's a layer of services. It's a layer of technology. It's a layer of even like just service and support on top of React Native that really doesn't exist otherwise. You can obviously hire a consultancy, obviously we're a consultancy. But in terms of having that kind of productized, that's what Expo does. And it's a really cool concept. I'm glad Expo exists.
Jamon Holmgren:
I'm glad it's existed from such an early time in the React Native world. One of the things that I've really enjoyed is that Expo has been an advocate for the community within the React Native core team throughout all of this. And I think that's a really important thing. Because your customers are us, that's who you're trying to support. And because of that, you have a very strong voice within the React Native core team.
Robin Heinze:
How did that come about? At what point did Expo and React Native start to be pretty entwined? Because you see a lot of Expo references in the React Native official docs. How did that relationship sort of start to form?
Brent Vatne:
Really early on. I actually met Charlie and James, the co-founders, because we were all contributing to React Native and back in the earliest open source releases of React Native, both James and I were responsible for writing the release logs and putting together the releases and publishing them and so on. And so, we worked together and met up, and eventually decided to start working together on Expo or Exponent as it was called at the time.
Jamon Holmgren:
Yeah. I remember that.
Brent Vatne:
I was against the name changes originally, but now, I can't imagine why we would have stuck with Exponent. Anyways. Yeah, so we're working a lot with the React Native core team at Facebook through our contributions. And at one point, a topic came up of like there was someone at Facebook group who wanted to improve the time to Hello World of React Native. Because you go to the React Native documentation and then it says, all right, well basically it didn't say this, but it might as well have said, "Okay, I hope you have a few hours because you're going to need to download XCode and you're going to need to, if you want to run on both platforms, also download Android studio and do all this other stuff."
Brent Vatne:
And that's fine. That's kind of like what you have to do to sometimes get tools working. But we want to explore like, is there a way that we could work together to bring that time to hello world down to something in the order of minutes, rather than an hour or multiple hours if you're on a slow connection or unfamiliar with the tools? And so we built something that was slightly different from Expo, but basically using a lot of the same infrastructure called React Native app with the blessing of Facebook.
Brent Vatne:
And we announced that at React Conf 2017, maybe? I can't remember anymore. And kind of started using that in the documentation as a way to get started. And so over time we've moved away from that package as the entry point, primarily because it was a little bit confusing for people where they would say, "Okay, I ran Create React Native app. And then I got this like Expo project," and we were having to maintain multiple versions of very similar code base between Expo CLI and Create React Native apps.
Brent Vatne:
So we just kind of condense that into Expo CLI and updated the documentation accordingly. And I think a big reason why that was possible was that one of the reasons we put Create React Native app there in the first place instead of Expo CLI was we wanted to keep the doors open in case some other company like Expo came along and wanted to provide a similar service and Create React Native app was meant to be kind of agnostic about what tool you use within that context.
Brent Vatne:
And so there could be multiple sort of development client apps, if that was something that someone else wanted to do. But ultimately, nobody came along and did that. I'm not surprised, it's a lot of work. And so, we moved towards Expo CLI there.
Jamon Holmgren:
Yeah. That's a little bit of a sneak peek into Expo's culture. And I've been around you folks for over five years now. And I can attest to this. You have kind of a unique internal culture where you're very open. I don't even know how to say this really very well, but it's basically like you embrace competition, you embrace other alterNatives. You talk about why you might not use Expo. And I think that there's some really cool things that come out of that.
Jamon Holmgren:
Because at the end of the day, you will stand on the things that you're good at, and you're not going to hide the things you're not good at. You're going to say, "This is why you would use Expo. This is why you would not use Expo." And I've always really appreciated that about your team. That's a hard thing to maintain over time as you grow, because the pressure from just building a business is the other direction, is to like, okay, let's trumpet our strengths and hide our weaknesses.
Jamon Holmgren:
But I've always really appreciated that. And we'll probably talk about this further into the podcast, but one of the things we did with our CLI Ignite, which spins up a boilerplate, it sounds like it overlaps with Expo. The reality is that it now works with Expo. You can use Expo, or you can use the regular React Native CLI. In some ways, it kind of fits that original vision of what you were going for with Create React Native app, where it can kind of hit either direction.
Jamon Holmgren:
And I really liked that. But we like Expo so much that even if you spin it up not using Expo, you still end up with some Expo parts in your app because they work well even outside of Expo. And that, again goes back to the culture. You're not going to keep all of the good stuff for yourself. You're going to actually share that with the community.
Brent Vatne:
Yeah. Historically, I guess for most of Expo's history, it hasn't been possible to use a lot of the SDK packages in sort of vanilla React Native apps. And that wasn't because we didn't want to do it. It was just that it was very difficult when you're coming from the perspective of building a client that is kind of this monolithic tool that has a kind of fixed Native runtime. And you can have interdependencies between modules and get certain benefits from writing code in that way.
Brent Vatne:
So we kind of started from that approach. But to kind of like split that out, it was a lot of work and it took us a while to get there. And so it was something we wanted to do, but it just wasn't the top priority. I think that was probably a mistake and it should have been a top priority from the start because we ended up, I think, creating more divergence than we would've liked in the ecosystem with things like React Native camera.
Brent Vatne:
At one point, they kind of wanted to sync with the Expo implementation. And so they just copied and pasted the Expo code base and then renamed a bunch of things. And then started working on that in parallel. So it just ended up being like us working on our patches for Expo camera and they're working on now a separate stream of Expo camera. And so, it wasn't the best outcome, I think, in some cases. And we're still trying to make that as good as it can be.
Robin Heinze:
Yeah. We've had a great experience with uni modules and it was actually one of my first introductions to sort of the Expo ecosystem. And it was a great way to sort of see all of the cool stuff that Expo can do while still being in our sort of normal vanilla React Native world. And now I'm like, "Oh yeah, this Expo thing is really cool," because I've seen what all the different uni module packages can do.
Jamon Holmgren:
Let me back up a second for our audience here. I'm going to attempt to explain how Expo works. Brent, you go ahead and correct me in any way that I'm wrong here. So from my understanding, how this works is you spin up basically a JavaScript project here. You've got a JavaScript project. You don't have the iOS folder. You don't have the Android folder, the Native stuff isn't on your computer. Now, when you run the project, otherwise it looks kind of like a React Native app.
Jamon Holmgren:
Like you've got an app entry point and you can write JSX, and you can use TypeScript, and you can do all these things that you would normally do in a React Native project. When you run yarn start, it spins up a packager similar to how the normal React Native app would work. And then you have your Expo app on either your simulator or on your device. And it installs that JavaScript package instead of into like my app or pizza app or whatever else you're building, it installs it into Expo app. Like the Expo app that you built.
Jamon Holmgren:
And Expo already has all these kinds of Native bindings inside of it, that where it knows how to talk to your code. They're pre-packaged already. Now I know that some of this stuff is changing. We're going to be talking about that. But this is essentially how this works so far. What that means is that you don't have to have XCode. You don't have to have Android studio. You just have to have a device that can take that JavaScript bundle and have that app on it, and then it'll start running. Is that correct, more or less?
Brent Vatne:
Yeah. Exactly. That's what we call the managed workflow. And we call it managed because we manage the iOS and Android Native side for you and use this right JavaScript code. And so, the Expo app on your phone, we call it Expo Go, used to be called Expo Client, but renamed it to Expo Go for some reasons we can discuss a little bit later. And so yeah, once you start a server or you run yarn start or NPM start or Expo start inside of your project, we start up an instance of Metro bundler.
Brent Vatne:
And then we add some middleware for an Expo server in there. And that server serves up a manifest file that describes things like what's the splash screen app icon, and name of the app and so on. And so, when you scan the QR code that pops up, or if you open the Expo Go app and open the app directly from there, because it will be pre-populated based off of knowing that like you're assigned into your Expo account on your computer, or you're signed in on your phone. So we can connect you to this.
Brent Vatne:
When you do that, we download this manifest and display this loading screen and then start downloading and loading the bundle. And yeah, that's the basic idea.
Jamon Holmgren:
Yeah. And the brilliance of that is you don't have to be compiling Native code. You don't have to have Android studio, you don't have to have XCode. And that's a really big advantage when you're really trying to get started. There are some other advantages as well. And we did a project recently at Infinite Red, where we used Expo. And I want to talk about that, but I also want to cover uni modules, which Robin mentioned.
Jamon Holmgren:
Uni modules is essentially a step toward making modules that work with Expo and with vanilla React Native, where you can use it on either of those. Now you do have to install a small package called Expo, or just the uni modules, I guess, uni modules core. And then once you've installed that, then you have access to Expo third-party packages or Expo libraries. What we really liked about that wasn't just that we could use it on Expo apps and React Native apps. That was great.
Jamon Holmgren:
But the quality is great. You folks do a really good job with your libraries. And that's something that can be outside third-party modules are of varying quality in the React Native space, but we always know Expo packages are going to be well done.
Brent Vatne:
Yeah. I think another nice thing that you get from using a set of modules, like the Expo SDK provides is that there are consistent API conventions. And so you know if there's an async function, it's going to be using an async suffix, we're going to use promises wherever possible. Everything is written in TypeScript. We kind of had very similar sort of documentation between each of the modules. And so, there's something nice about having that consistency across the libraries that you use, for sure.
Jamon Holmgren:
Totally.
Robin Heinze:
Yeah. We really appreciated that. It was nice while we were building when we came across a need for a third-party service for whatever it was, geolocation, maps, camera, whatever, like, "Oh, Expo has one, has something for that." And you know it's going to be well-documented, you know what to expect.
Bryan Stearns:
We were worried that we would discover a need to eject from the managed environment, which it's great that Expo provides that. If you run into something where you have to install a dependency that has a Native component, you can eject from the managed environment and turn your app into a vanilla React Native app and continue developing. We were worried we'd have to do that. But never did. And it just worked out great. We use this project as a way to build Expo support into our Ignite boilerplate, that worked out really well.
Jamon Holmgren:
We did get close one time. Remember Bryan? We were working on a feature of the app where, because it was a two-sided marketplace app and we needed to integrate Stripe connect. So normal Stripe, like you can use normal Stripe in Expo just fine. No problem. But Stripe connect didn't have like full support at least at that time. And so we were lucky in that, like, okay, do we inject, do we work around it? We had a long discussion about that.
Bryan Stearns:
We ended up using the non React Native libraries for Firebase and for Stripe, the web libraries work just fine. So that worked out fine.
Jamon Holmgren:
Because of JavaScript. Yeah. So that was an interesting thing. And because we were doing this, this was our first fully full like managed project in Expo, this was a bit of an experiment. And I hit up Brent a few times. Brent is awesome about responding to me on Twitter, even though I probably should be using official channels and stuff, but I just DM him. He's awesome. But I would ask him things and he would very nicely point me to the docs or do whatever.
Jamon Holmgren:
And it's fantastic having that sort of a resource as help. We paid for the managed service to get prioritized builds at the time and whatnot. It was a good experience. Overall. There were some points where it was a little like, "Ooh, what do we do?" Especially if it came to a point where we needed something with Native code. And we're going to be talking about something new that Expo is working on that solves that problem.
Jamon Holmgren:
Before we get there, I want to mention there a couple of years ago, I met with your team and just kind of talked about our use cases. And one of the things I said, if you can remove the pain around React Native upgrades, which was a real pain at the time. It's gotten a lot better since then, but it's still kind of an issue, that would be amazing. And also there's just a myriad of just small cuts that you kind of run into with React Native. And if you can just make that experience better, then I'd be a customer for sure.
Jamon Holmgren:
I've said for a long time that I think Expo's the future of React Native. But with this new stuff coming, I feel like it's starting to become more the present. So I would like to shift more into EAS. Brent, would you tell us what EAS is?
Brent Vatne:
Sure. So we kind of split up Expo as a company into two categories. There's the Expo platform, which is the SDK. Like we talked about before, like the various modules that we provide for access to Native capabilities. There's the client. So Expo Go to open your app and development and things like Expo CLI, is also a snack for loading small sandboxes in the browser to play around with.
Jamon Holmgren:
Snack is really good. It's great.
Brent Vatne:
And then we have the services side of the business. So the Expo platform side is totally open source and everything is completely free to use and you can fork it and do whatever you want with it. The services side is largely closed source, although there is an open source component to it. And maybe before we talk about the specifics, I think a key thing to identify here is that even though it's like a set of hosted services, that it's a business, they're a paid offering. There's also a free tier and there's also no lock-in.
Brent Vatne:
So these services, you can run them on your own CI if you want to, you don't have to use our hosted servers for that. And so, the part of it that is closed source is just like our server that like integrates it into our website and dashboard and so on. But if you want to run our build service on your own CI server, you can just install the CLI tool and use the same thing that we used to do that. And so, we definitely want to not get people feeling like they're locked in whatsoever and that they have full ability to take their app wherever they want to and so on.
Brent Vatne:
So these services we have a couple of them so far. We have the, like what we call now the classic services, what you've used in the past. So like Expo Build. So from the Expo CLI, you'd run Expo Build iOS, and that would create a build of your JavaScript bundle and upload all of your assets and create a manifest and then start a Native build on one of our servers that would take all of that and put it inside of a binary and apply all of the necessary changes to it.
Brent Vatne:
And then upload that binary somewhere so that you can then download it and upload it to the App store or Play Store, whatever you need to do. And then there's an update service. So for publishing over your updates and as well one for notifications. And so what's happening now with EAS is we kind of run into limitations with our classic services specifically around build. But they're limitations really in all of them that have required us to revisit kind of the initial design.
Brent Vatne:
And so around built, the main limitation is that we kind of use the very optimized approach to building that was not flexible enough to solve the problem that you nearly run into when using Expo at Infinite Red of wanting to add your own Native code to the project. And so, the way that that worked was basically we have a pre-built unsigned archive sitting in a tar file that we then download on our build service and go through and rename all of these strings in the file and copy over all of the assets and copy in your JavaScript bundle.
Brent Vatne:
And then we sign that and then give it to you. And so this is not the standard compilation process, and that's how on iOS we're able to do a build of your app in something like a minute or a minute and a half because it's just copying resources over and changing strings. And so, that's great for doing fast builds where you have a fixed Native runtime, but it doesn't work so well when you actually need to compile the app from scratch.
Brent Vatne:
And that's a very different problem, because rather than uploading your assets and JavaScript bundle and manifest, you now need to upload your entire project somewhere. So you would need to like with CI, often you connect your Git repo or something like that. You now need to pull in that entire project. You need to install CocoaPods and you need to run Cradle and Fastlane and whatever else you're doing in that context.
Brent Vatne:
To complicate things a little bit further, in managed apps, you don't have an iOS or Android directory. And so we have to create those on the fly in order to then do a build. So it's fundamentally a different approach to doing builds than our classic build service, which is really driven by the need to support Native code in managed apps. The ability for people to say, "Well, I would like to use the Stripe connect React Native plugin in my app."
Brent Vatne:
And that's not something that's part of the like preset Expo SDK runtime, but I'm going to install it and then do a build and it will be there. And so, that's kind of the direction that EAS Build is headed in where we rebuilt our build infrastructure, lots of uses of the word built there, but I hope that's clear enough and kind of made it into something that much more closely resembles your standard mobile CI, CD kind of infrastructure.
Brent Vatne:
You get access to a machine in the cloud that is, it knows how to build your React Native app. It knows how to build your Expo manage app and tries to take care of as much of that as it can for you, but you still get the full power and customizability of doing a full, proper Native build rather than kind of using this pre-built happen and modifying it.
Brent Vatne:
So, we have a couple of other services as well, and one of them is submission. So we've found in the past that it's been a limitation for people where you can use Expo managed workflow to build an iOS app on windows, because you just need to be able to run node on your machine and have an iOS device to test on, but you don't actually need to have a Mac to do the development. And so our submission service is a hosted way to upload your app to Apple.
Brent Vatne:
So you can run EAS submit once you've done a build with EAS Build and from any CI server or from your Mac or Windows or Linux machine submit to the app store. And we kind of try to provide a nice experience around that with giving you a better context for errors that pop up and try and help you with fixing those and overall more guidance there. Now there's some other stuff I could talk about, but that's the most interesting, probably.
Robin Heinze:
So it sounds like you're really aiming to be sort of an all encompassing one-stop shop. Does that mean you kind of see Expo replacing the sort of go-to build tools that a lot of people use now, like Fastlane and Match and test flight for beta builds and those kinds of tools?
Brent Vatne:
I think, yes, build and Expo, like we've fit in nicely with those. In terms of fast lane, we actually use fast lane by default in our build process. To build the iOS app, we use Fastlane Gym, and you can customize your Gym file. That's the approach that we take to allow you to customize your builds further. And for a test flight, we provide something called an internal distribution, which is similar to what you might get with other tools like App Center or Firebase app distribution that basically allows you to manage an ad hoc certificate or ad hoc provisioning profile rather, and add some list of devices to it, and then do a build and distribute to those devices.
Brent Vatne:
But that's not always a good alterNative for test flight. I think test flight has, for example, higher number of devices that you can distribute to. So with like ad hoc provisioning, you can only distribute to up to 100 devices. Whereas Tesla I think it's something like 10,000. But there are trade offs there. And so I think generally it kind of fits in with those, and it's more of an alterNative for tools that just work out of the box with React Native and with Expo projects.
Brent Vatne:
And maybe another good example is something like Fastlane Match for credentials. You still kind of have to set that up. You need to create your app sign in credentials and then store them somewhere and teach Fastlane about how to get those and allow you to synchronize those between machines. Whereas using yes for this, we help you generate those credentials on your own. We store them and then anyone that's a part of your team on the Expo dashboard is able to then build using those credentials provided they have sufficient permissions to do so.
Robin Heinze:
Wow. Yeah. So, that really is like everything all wrapped into one. That's pretty cool.
Bryan Stearns:
Do you see anything changing in the way you support the runtime environment? Right now, you've got a back end for doing notifications that apps use, our last app used worked great. Are there other sort of runtime components you see yourself building for the back end of Native apps?
Brent Vatne:
Yeah. I would love to get into in-app purchases and really make that flow as easy as possible. This is something that people have wanted for a long time in Expo manage apps. And I think that it's not super easy to do, especially not like in a cross-platform way. And I think that would be really interesting for us to get into that once we get EAS Build into a state where we can allow people in the managed workflow to use any custom Native modules, because we can't actually include any code around in-app purchases in our app store distribution of Expo Go.
Brent Vatne:
And so a big part of being able to support custom Native code in managed apps is to allow developers to build their own version of Expo Go. And so that was what I was alluding to earlier, the rename from Expo Client to Expo Go was intended to describe that Expo Go is kind of the way to get started. And it's this preset runtime that I think will work well for a lot of people and a lot of smaller apps, but at some point, you might want to include something like Stripe connect or in-app purchases, and then you can do your own custom build of the Expo Client and include your own bespoke Native runtime that you're then building against. That kind of approache is necessary to do this. But we absolutely want to expand to other things like purchases.
Jamon Holmgren:
That'd be very cool. With the EAS, does it handle both sort of normal Expo apps and ejected apps, or how does that work? Do you have to use one or the other?
Brent Vatne:
I would say that like a normal Expo app just to clarify is like, and it's an injected app or a managed app. But we treat them both as being totally valid ways to use the tools. And some people like to work in an environment where they don't have to deal with the iOS and Android projects at all. Other people are more comfortable when they can at any point drill down and do any sort of work to do in Native code.
Brent Vatne:
And so EAS Build actually currently only has some early experimental support for managed apps and it works great for any React Native app. You can run NPX React Native in it or you can Ignite new and you immediately in that project run EAS Build and hit enter a couple of times and type in your Apple credentials and you'll have an app building that you can upload to the store right away.
Brent Vatne:
And so, it works with really any React Native project and it could potentially work with any Native project as well, but we're really focused on specifically React Native and Expo projects. That's where we think we can differentiate from other mobile CI/CD services where we're building this tool chain that people use in development, but we're also building the end to end experience and throughout the entire process, we're considering React Native and Expo as being the tools that people are using.
Brent Vatne:
And so if you're using Expo CLI for development, if you're using packages in your SDK, the Expo SDK in your project, React Native packages as well. These are all things that we can optimize to, for example, speed up your builds, or kind of just provide you with good defaults around like having options in your configuration to customize like Expo updates out of the box and that sort of thing. So kind of really deeply integrating this idea of a mobile CI/CD service with React Native and Expo, and kind of seeing how far that can go is the idea here.
Jamon Holmgren:
Interesting. So in a way, you're really supporting the kind of, I guess you call it bare workflow side of things. You're emphasizing that even more than you did before, where you always supported it really well, but you're making it so that this is actually something that you can provide services around, you can provide more than just the tooling around it. You can provide a lot of other processes.
Jamon Holmgren:
To me, I'll just give my opinion as someone who has only worked on an Expo project for maybe a month like scattered throughout the project that Robin, Bryan, and I worked on. But I did really like not having to deal with XCode or Android studio. I really liked the managed workflow. To me, it was like working in a browser. It was like command R, and it would refresh. You didn't have to think about it too much. I do really like that side of things, but I also understand the limitations and the fact that people kept running into these situations where they'd have to choose between do I get like Expo's awesomeness, or do I jump out of it and kind of don't get as much of that anymore?
Jamon Holmgren:
So, you're making it so that when you jump out, you're not jumping out of the frying pan into the fire. You actually have some good services around that.
Brent Vatne:
Yeah. That was an issue in the past was when people would eject their projects, they would now lose access to running their builds on Expo build. And that wasn't great because already you're taking on this additional complexity of managing the Native projects, and now you have to also figure out again what your build pipeline is going to look like. And so that was something that was important for us to solve to build and continue to provide the same experience, whether you have the Native projects in your source control or not.
Brent Vatne:
And we're working towards a point with the eject command where it will just work perfectly in every situation essentially. And sometimes it's a little bit tricky right now. There's a lot of sometimes manual work that needs to be done to set up some modules that are included in your project. For example, you might have to modify your build griddle to add a Maven repository if you're using a camera library, for example, and little things like this, or modify your main application or app delegate to add a little bit of code in order to initialize the module that you're using.
Brent Vatne:
And so these sorts of things were just like chipping away at those, making it so that we have a generic infrastructure for people to build on top of, so that any of these libraries, if you're using something in the React Native ecosystem that we didn't even build, it's very easy to plug in a, well, a plugin that will know how to configure a project when you inject so that it just works right away. And ultimately then the difference between like a managed project and a bear project will just be whether you ran eject or not.
Brent Vatne:
And then if you like, you can just like delete the iOS and Android directories and go back to being a managed project. So you might even do that for debugging. If you find like, I really like using the managed workflow, but I'm not able to do something that I want to do in debugging right now, I need access to XCode for it. So then you can eject, do whatever debugging you need to do to go, "Okay. This seems to be an issue with this library."
Brent Vatne:
Or you profile something and see this particular animation is problematic. Then you just revert that. And you're back to working without using XCode and Android Studio.
Bryan Stearns:
That's really great. Do you think you'll be doing anything to improve the debugging experience, sort of the other end of the development flow? I'm not sure if you have any ideas on how to improve that.
Brent Vatne:
Yeah. I think we'd like to get into that. I'm still, I think, looking to see how React Native tackles this with the Hermes debugger and whether we end up, I know on Android, the plan is to get rid of JSC entirely at some point and move over to Hermes. So if that's something that ends up happening on iOS as well, I think right now, they're React Native 64. I think a lot of people are going to be testing the waters with Apple and how open they are to people using Hermes instead of the built-in JSC API.
Brent Vatne:
And if that's something that Apple seems okay with, then maybe in the future, React Native could switch over to Hermes, and then we get Hermes debugger everywhere. And that would be great. Ultimately with the new architecture and with turbo modules, it seems like the debugging experience needs something like that, like with, if you include Reanimated in Reanimated Two in your app currently using JSC, which is not possible outside of Expo currently, but it is possible in Expo apps.
Brent Vatne:
Then you can't use the Chrome debugger because of the synchronous calls and various things that are incompatible with using a Chrome debugger. And so, I think that's kind of the direction it'll go. And we're at the moment not investing in working on debugger as we have a bunch of other stuff to do, but pretty optimistic about what Facebook is doing around Hermes. And we hope that'll be a good answer for people.
Jamon Holmgren:
It's worth noting that our debugging tool Reactaron works great with Expo. And if people, because it is just a JavaScript side thing, you can use Reactatron to debug like your state and get logs and inspect network requests and whatnot. Flipper is another debugging tool that Facebook released. I don't think it works with the manage workflow, is that right Brent?
Brent Vatne:
Right.
Jamon Holmgren:
But it works with the other.
Brent Vatne:
Yeah. You can only use it to the extent that it provides access to React dev tools inside of Flipper. But in terms of like the Native hierarchy debugger and things like that, that's stuff that is not available currently. I think that's something interesting-
Jamon Holmgren:
But will be with EAS, right?
Brent Vatne:
Yeah. It depends, I guess. EAS, you could potentially like, we're actually in building this new version of the Expo Client. Really we're building that also from scratch and we'll have a preview for that soon that people can actually try. In any React Native project, you can just install this library new project and add a couple of lines of configuration to give it a try. But you could conceivably set up your project such that it works with Hermes using this other development client and sorry, it works with Hermes and also it works with Flipper. That's something that we just haven't explored yet for the manage workflow.
Jamon Holmgren:
This is awesome. It's really cool to see the direction that Expo's taking. Like I said, Ignite’s been using, or it allows Expo. And so we've been really paying attention to what you folks are doing. When there are new projects coming in, new startups, we always evaluate whether Expo makes sense in that particular case. It sounds like with EAS, Expo Application Services, when it is kind of fully available, that we are going to have that option, even with pretty customized apps.
Jamon Holmgren:
So, that's great news for us. We really like what you all are doing over there. I've always believed in your team. It seems like it's always good code and good decisions kind of coming out of that. You have had kind of this evolving thing, and I'm sure that you have a lot of, I don't know, stories of back flips you've had to do to make some of this stuff work, but it's interesting to see for sure.
Jamon Holmgren:
If people want to read more about EAS, there is a blog post about that. I'll link to it in the show notes, so that I think Brent, you actually wrote that blog post that introduces EAS, and they can get a good sense for what's coming down the road.
Brent Vatne:
Yeah. And we'll be releasing our first update blog posts maybe within the next week or so about the improvements that we've made to EAS since the preview released in December. And we're targeting the end of Q1 for releasing full managed workflow support. So that's exciting, something to keep an eye out for it.
Jamon Holmgren:
Very cool. So we're going to go to the next section of the program, and this is where we talk about weird bugs. So from what I understand, Bryan's got a weird bug that he wants to talk about. Bryan, what do you got?
Bryan Stearns:
Well, it's not actually a weird bug. It's kind of an ordinary bug, but it's a weird solution. I was upgrading this app that we've been talking about, our first managed Expo app to SDK 40. And this app has a typical scrolling list of cards on its home screen. And you tap on one of the cards that takes you to a detailscreen. After upgrading to the new SDK, that tap would crash and restart the app, but only in Android production builds.
Bryan Stearns:
And this was the first time I'd had to track down a production only bug. I found the tools are pretty limited ADB log cat or whatever, will show you the system Android system log that has some React Native stuff in it, but it's not console dot log. And it's really noisy with unrelated stuff. And also production builds through Expo's wonderful service, we're no longer on the paid priority build system and they can take half an hour or longer, which when you're doing one a day, that's not so bad. But if you're trying to iteratively debug, that's painful.
Bryan Stearns:
So my first strategy was to start cutting out pieces of the app to see what made the crash go away. And I wasn't sure if the crash was something related to navigating from the old screen or rendering the new one. So I just made the detail screen render a single text element, and then I told Expo to do a new production build so I could test it. And when I did that, Expo gave me a warning that the non JavaScript parts of the build were the same as the existing build.
Bryan Stearns:
And I could speed things up by using the over the air update mechanism, which is something we use routinely in our publishing of the app to push out JavaScript only updates that don't involve going through the app store. It's a great way to get new fixes to your customers. But I hadn't thought of using this in development to narrow down this bug. And it was great because that only takes like 30 seconds for iteration.
Bryan Stearns:
So within three or four iterations, I'd track the problem down to a known issue with the little math component that we were using not liking our custom marker image. It isn't Expos math component. I don't know why we picked it. But anyway, the issue was Googleable. It's a known issue. It has an easy workaround and had the problem fixed. And it was just great to have that over the updates mechanisms to speed my development.
Jamon Holmgren:
Yeah, that's awesome. One of the things that is the most frustrating in debugging is when you have a slow feedback cycle, so you try something and then you have to sit there and wait for ages and ages and ages. That can be very frustrating. And so finding a way to really speed up that cycle is awesome. I think we can call that one a wrap. Where can people find you Robin on Twitter?
Robin Heinze:
I'm at Robin_Heinze with an E at the end.
Jamon Holmgren:
And Bryan, where can people find you?
Bryan Stearns:
I'm at Bryan Stearns on Twitter at Bryan with a Y and Stearns is S-T-E-A-R-N-S.
Jamon Holmgren:
Perfect. And Brent, how can we find you on Twitter?
Brent Vatne:
I am Not Brent on Twitter.
Jamon Holmgren:
I thought you were Brent though, confusing. Yeah. You can find me at Jamon Holmgren, and you can find React Native Radio at React Native RDIO. Thank you to our guest host, Bryan Stearns for joining us today and our guest Brent Vatne. Next time don't wait five years between appearances. Hopefully, we'll have you back on to talk about some other things in the future.
Jamon Holmgren:
As always, thanks to our producer and editor, Todd Werth, our transcript and release coordinator, Jed Bartoceski, our social media coordinator, Missy Warren and Justin Huskey and Jenna Fucci who are responsible for the React Native Radio artwork. Thanks to our sponsor Infinite Red, check them out at infinite.red/reactNative. And also thank you to all of you listening today. Make sure to subscribe on all the major podcasting platforms.
Jamon Holmgren:
Look for React Native Radio and let other people know about this. Reminder. Infinite Red is hiring React Native engineers. If you're a senior level React Native engineer located in the US or Canada, go to careers.infinite.red, and I will get that HTTPs error fixed soon. I promise. See you all next time.
Robin Heinze:
Bye.
Jamon Holmgren:
Bye.