Jed Bartausky:

Welcome back to another episode of the React Native Radio podcast. This week we've got another installation in our Expo member series, episode three 15. What to Do Without App Center With Quinn Jung

Robin Heinze:

Welcome back to React Native Radio, everyone. I'll keep it brief. I'm Robin, he's Mazen. We are React Native Radio. We do have a lovely guest today. I'm sitting here not only with Mazen, but with Quinn Jung. She's a software engineer at Expo and she leads work on a S update. And then she's originally from Vancouver, Canada, I'm reading, and now based in Seattle and she enjoys gardening and Brazilian juujitsu in her spare time. That's pretty exciting. Welcome Quinn.

Quin Jung:

Glad to be here, Robin.

Robin Heinze:

Yeah, so we're here to talk about App Center and Code Push, but before we get into our topic, I should let you know about our sponsor who is of course Infinite Red. Infinite Red is a Premier React native consultancy located fully remote in the us. We're a team of 30 senior plus level React native developers and support staff, and we've been doing this for nearly a decade. I'm excited for someday being able to say over a decade, but if you're looking for a React native expertise for your next project, be sure to hit us up at Infinite Red slash Radio and of course mention that you heard about us through the React Native Radio podcast. Alright, let's get into our topic, which is what to do without app center and we're going to talk about that. But before that, I got to go back to the Brazilian Juujitsu thing because that's the coolest thing ever. How long have you been doing Juujitsu? I've been doing

Quin Jung:

It on and off for about a year now. So before I settled in Seattle I was nomadic and it was one of those things where you need a hobby and one of those things where if you're in urban area, there's always going to be a Brazilian jiu-jitsu gym or whatever that

Robin Heinze:

You can train at. Oh yeah, I can picture the one that's near my house. There's always one

Mazen Chami:

Everywhere.

Quin Jung:

Yeah, it's a much better hobby than say golfing or tennis where wherever you relocate, there might not be a golf course, there might not be a tennis court, but there's always going to be a Brazilian juujitsu gym. That's one of the rules of the world, kind of like the rules on the

Robin Heinze:

Internet. So if I can ask, what belt are you now?

Quin Jung:

I'm currently a white belt, so because I switch so often, I'm always perpetually the new person. So perpetually white belt.

Robin Heinze:

Well, you'll have to let us know when you

Quin Jung:

Get that belt progression.

Robin Heinze:

What's the belt after white?

Quin Jung:

It depends if you're an adult or a child as an adult, it goes from white, blue, purple and black. Or I think there might've been a brown in between, but for children it's like a different color progression. There's yellow and there's gray. Interesting. I wonder why is it different? I wonder. I don't know. Maybe there's different milestones. So children might progress more slowly than adults, so you want to acknowledge each well,

Robin Heinze:

You want to keep reward. You're like, that makes sense. You got to keep 'em interested. It's like I want all the colors of the rainbow. Come on. Well that's really cool. On the tech side of things, maybe you can tell us a little bit about how you got started at Expo and how you got into the industry and what's your story?

Quin Jung:

So I started at Expo in the early days. So in 2017, and this was back when we all were working in one small tiny house in Palo Alto. So to paint you a picture when you first go in, there would be the precursor of EAS build running in the back room and they'll be like, don't use the kettle. If you use the kettle, it'll trip the circuit and then the build service will go down. So that

Robin Heinze:

No way. Yeah, so super early days. That's amazing. So that was back when it was called Exponent, right?

Quin Jung:

Yeah, yeah, exponent. Wow.

Robin Heinze:

Yeah, and then they shortened it. Oh, that's wild. So have you been on the EAS update team from the beginning or did you start somewhere else?

Quin Jung:

So I started off as a generalist, so just whatever people wanted, we'd have this canny board where people would upvote all the features that they wanted and it was truly a democracy. Whatever had the most up votes would be the thing that you'd work on.

Robin Heinze:

Oh wow.

Quin Jung:

And I dabbled in a lot of things. So for example, the brightness module, somebody wanted it rewritten so you'd rewrite it, but eventually I ended up specializing in the infra stack and EAS update eventually.

Robin Heinze:

Oh, very cool. I love hearing about the early days of companies that have grown big and that everyone uses now. I remember I just like hearing about the days when Facebook was in a garage and

Mazen Chami:

Yeah, I do remember that upvote thing. It was open to the community too, right? Where it was a discussion board almost and based on the number of up votes it got worked on kind of thing. Is that right?

Quin Jung:

Yeah, yeah. So think of it as a kind of stack overflow Kanban board.

Mazen Chami:

Yeah, yeah, okay, I remember that. Yeah, that was pretty cool. I also was the troll that kind of went in there and said up, up

Robin Heinze:

Mazda everything. No, because

Mazen Chami:

That was when Expo had first started and everyone I was like, I think I see the vision here. Let's get all these modules and hindsight obviously apologies, but maybe I helped push Expo, get to where they are now. I don't know, just saying

Robin Heinze:

Anyways, making all these demands of a team of however big you guys were at that point, at least working in the house, the folks weren't random, they were very ated. Yeah,

Robin Heinze:

That's awesome. So we should probably talk about our actual topic too. As I'm sure most everyone who's listening has heard, Microsoft App Center is shutting down. So if you don't know about App Center, Microsoft App Center was one of the first React native do it all kind of services that did React native builds and they had a particularly popular service called Code Push, which we'll talk about, but they announced earlier this year that they are shutting down completely. And so a lot of people that are using app center are having to find alternatives. So today we're mostly discussing the expo alternative, which is EAS and how Expo and its tools can sort of step in and be a good replacement for the app center features. So app center features were build test, distribute diagnostics and analytics. I pulled these straight from my app center dashboard. These are things that are on the sidebar, they're like main features, but let's start with build. This one's pretty self-explanatory. Mazen. Have you used App centers build functionality at all?

Mazen Chami:

I have not used App Center at all. I have heard anecdotally a lot of maybe the time that I'm asking these questions now with Expo being around that everyone is very, can we say this on air anyway, hot take everyone's happy. I'm not going to name names, but everyone's happy that app center is going away while EAS and EXPO exists in this ecosystem. That's my take and I guess I'll follow that same sentiment. I love Expo for EAS and their developer experience for sure.

Robin Heinze:

But let's talk about build specifically Quinn. Can you talk about how EAS build can step in and replace apps in or build?

Quin Jung:

Yeah, for sure. So the way most people are introduced to our build service is when they have an expo app and then they run the command EEA s build on the command line. So what that does is it takes your project and the directory and it uploads it to our servers and you can see on the website all the build steps that it takes to convert your Android or your iOS build into a binary. I'd say it's not just for expo apps, it's for plain React native apps as well. So for expo apps we run pre-build and it generates the iOS and Android directory and that's basically a plain React native app. And if we see the iOS or Android directories, we'll just continue building it. Oh, it's a regular React. It's

Robin Heinze:

Like okay, we don't need to pre-build, we'll just continue. Yeah, it's built on fast lane, right?

Quin Jung:

It is, yeah. So actually late last year we released something called custom build where you can more easily declare things in your build. So honestly it's a yamo file. So all the steps for the build are declared step by step and you can modify it, you can run any command and in theory if your build can be expressed with a gym file, it can be built on our systems in Fastlane.

Robin Heinze:

Yeah, I mean I think a lot of us probably remember the old days before a s before EAS before expo, that's how we were doing our automated builds was with just fast lane scripts that would be like, okay, first you do certificates and profiles, then you run Xcode or Gradle or whatever the actual build command and then you figure out where the binary is and upload it to wherever it needs to go. And that's essentially what EAS is doing. So what I love about EAS build and I've used it for quite a while, is it really takes a lot of the pain of all the auxiliary steps like the certificates and stuff. It really takes the pain out of those in a way that doing it manually and it even has the option for local builds is so cool. And in the customization that you were talking about. So people who are worried like, oh, I don't want to be tied into this third party ecosystem, whatever, it's really not, that's really not the case. You have so many ways to customize your build and have control. We even have a client where we do local builds and we pass our own credentials and there's so many ways to use it.

Mazen Chami:

I think one other thing with a client that I'm actually going to mention a lot during this episode for build, we are doing a situation where we create our build but then we analyze the build based off of expo fingerprint. If listeners are familiar with that and based on that fingerprint reading of the build, we decide if we need to go through our full test suite and our full build pipeline process. So for example, you change the Read Me file, do you really need to test and build and do everything that you usually do in every pull request commit, oh you forgot a period, push another commit. Okay, got to wait another hour.

Robin Heinze:

Now you wait, run your full CI suite.

Mazen Chami:

Exactly. So build and all the customizations and even sometimes local build, we were initially doing this locally that gives you the ability to have all that. And I do remember you mentioned Fast Lane robin, I remember having to do that and doing that in Fast Lane, but I remember that being overly complex in doing and now I feel like, like I said, developer experience has been

Robin Heinze:

Elevated. I would never go back at this point.

Mazen Chami:

No, never.

Quin Jung:

Yeah. So one thing I will say about Fastlane is when you do run the build locally, it does expect your environment to be configured a certain way and it does take some finagling and in the early days I remember we would ship Fast Lane in the CLI for everybody to run and Fastlane is written in Ruby and it's one of those things where it's notoriously hard to run uniformly on everybody's machines. So I totally feel your pain.

Robin Heinze:

Oh yeah, I used to be a Ruby death and so I always had the latest Ruby on my machine. I had Ruby version managers and all that stuff and so it was pretty easy. Then I moved to React native and all of a sudden my Ruby environment was always way behind and trying to figure out why Fast lean was failing, it was like, oh, it's like my Ruby is out of date and then you upgrade Ruby and you're like, oh shoot. Now I also have to upgrade Bundler and then I have to rebundle and get all the right gems. I am already having to maintain my node environment, all my node versions, my NPM versions, my main development stack and then also having to manage all of my Ruby versions and GEM files and all that stuff was just an unnecessary headache. And now I'm like the EAS servers just like they have everything and it just works and I just have to run a command. Just works. It just works. Trademark that. So let's move to test. So I've never actually used this feature of App Center myself, but from what I've read, it is a feature where not only can you run your builds, but maybe before you run your builds you can run your test suite, your integration test suite. I think App Center said they support things like Appium and a few other specific test frameworks. So what sort of options does EXPO or EAS provide for filling this test void? The app center's leaving,

Quin Jung:

So as I mentioned before, when you run EAS build, it kicks off a build job and it has all these build steps and late last year we released a customization where you could declare these build steps in a yaml but in addition declare these test steps. So we really support for running maestro tests on simulators, but really because you can just run any command you want on the machine, as long as it's specified in a yaml it can. It could be pretty much anything. But right now we have the most support for the maestro tests.

Robin Heinze:

That's awesome. We've been using Maestro for the last couple of years and we really like it. So are there any limitations on the software stack that's on the servers? Whether because Maestro needs to be able to run simulators, right? So I'm guessing you have to run it on Mac machines or something like that.

Quin Jung:

So a lot of our machines, they are Mac runners and we do have a slew of simulators all set up in the yamo files. If you don't specify anything, we'll just use the default simulator. But if you want you can also specify a device ID and we'll run it on the simulator if it exists.

Robin Heinze:

That's really cool. It's so weird for me to imagine a simulator running on a headless server. Like if no one is looking at it on a monitor, is it really working? I dunno, it just seems odd to me. Go ahead.

Mazen Chami:

I can confirm that we are using this pipeline that you're talking about Quinn and it's working very well for us. I mentioned about the fingerprint and all that, but let's say it gets all through all that. We run through all our maestro tests on the cloud and it's great. I know EAS has EAS cloud, which is a different product where you can run tests on there and Maestro also has Maestro Cloud and you can see screenshots, you can see re-recording of all this. You don't get all that by doing it in GitHub actions, which is fine if it works for you. But we do have the ability where when it does crash, so let's say you get to a screen where you're supposed to press the specific row within your row of product, but my store doesn't find it because you forgot to scroll to press it, you will get a screenshot in your errors, which you can go into EAS dashboard and get that screenshot and it'll tell you what your error was and you get to see those green check marks and red xs that usually see in your terminal. So it does a very good job of alleviating all that for you

Quin Jung:

And Robin, to your point on it's running headless on the machine. So we do export artifacts, so if the test was successful or failed, you can download those. But to Zen's point on being able to see screenshots, that's honestly where we want to be in the future, but to have more support to be able to go to the dashboard and be like, oh, I can actually see right away where it is. But right now we're on the road to just releasing these more custom steps, these custom workflows that you can just run anything under workers.

Robin Heinze:

It seems like you have a lot of flexibility to run whatever you need to run. So we're able to build the app with EAS build and we're able to test the app and run whatever test suites we have. So that's two app center features that we've covered. Let's move to distribute, which is probably the one that most people are talking about. And I think most people who were still using app center were using because distribute includes code push, so there's actually two parts to the distribution. So the app center provides the ability to upload a binary or either you've built it on app center itself or you've built it somewhere else and you can upload a binary and they distribute it, meaning there's a way for your users to go to a link and download the build onto their device. So that's one piece. So let's talk a little bit about how Expo and EAS cover that. I think that's probably internal distribution, is that correct?

Quin Jung:

Yeah, so for that one it's basically distributing your app a more production version of your app, but in a way that you can just scan a QR code and it'll download it on your phone. And behind the hood we use something called an ad hoc provisioning profile, which is used for this type of distribution from Apple where you register your device and we put it on the profile and you're able to see what this version of your app will look like before it hits test flight or before it hits the app store. And in a way that you can distribute it very easily to anybody or the marketing guide, they just scan the code and the app just plops

Robin Heinze:

In. So if users are wanting to distribute to more of an open-ended, anybody can download, not necessarily people who have the ability to register their devices, is there a way to do that as well or is that going to go into submitting to the app store territory?

Quin Jung:

Yeah, so for Android there isn't that limitation, so anybody can do that. But for iOS platforms there is a limit of a hundred devices on this kind of QR code distribution.

Robin Heinze:

Notoriously they're still locked down about it, but EAS does have the ability to programmatically submit to the app store. Correct.

Quin Jung:

Yeah. So that's a service called EAS submit and EAS metadata to help fill out all those forms.

Robin Heinze:

I know getting the store listing correct is a whole thing, but yeah, EAS submit to the app store is pretty new. It was in beta the last time I checked. Is it ready for primetime now?

Quin Jung:

So EAS submit definitely EAS metadata. The last I heard it does work, but we only have support for it for iOS, so not for the Google Play stores, but end to end you're able to chain a bill job with a submission, so you can just run a command and it'll build your app and it'll just submit it to the stores.

Robin Heinze:

Super useful. And I think App Center did something similar as well where you could take your binary and forward it to the store. So that's great. Mazda, is this something you've ever played around with the submit and the metadata?

Mazen Chami:

Yes. Last year's Chain React Up, I believe we went full EAS, this was kind of like when ES was still starting out and I'm pretty sure we used EAS metadata for the last push to the store, which was actually the Monday before the conference started on Wednesday, getting involved, all that. Yeah.

Robin Heinze:

Awesome. So the other half of distribution is assuming you've gotten your app on people's devices, if you have a bug or something you want to change in the JavaScript of your app, app Center provided something called Code Push, which is a way to change the JavaScript bundle without having to resubmit to the store. What's the expo replacement for Code Push?

Quin Jung:

Yeah, so I wouldn't exactly say it's a replacement, so they're all over the air updates, but

Robin Heinze:

There

Quin Jung:

Are some different concepts where I will say you are able to ship updates over the air. That's what we both have in common, but there are some foundational differences in Code Push and EAS update where, for example, I'm going on a tangent here, but Code Push has something called deployment targeting, which we don't quite have or that concept isn't quite there. In EAS update, we have a concept called Runtimes and fingerprints where we automatically detect whether the native layer is compatible with the update and if it is, then we ship it. So interesting, we both do over the air updates, but the way we go about it is slightly different.

Mazen Chami:

But I do like how with EAS updates, you have the, what do you call 'em, the profiles? Well, I assume they begin from your build process where you create, let's say you have a production profile, the one that goes to your store, but at the same time you have a, let's call it preview profile, which is being sent to your QA team, your internal team to the store. You have an update, you want to push it to your preview first, QA goes in tests, it confirms it, then you kind of push it to your production channel. So then it's in prod for your users without having to push out a store release. I think they're pretty much the same, just probably labeled and marketed differently. Right, so you're saying Code Push has the Build pipeline, whatever

Robin Heinze:

You call it, code Push has deployment,

Mazen Chami:

Deployment,

Robin Heinze:

Deployment keys, and you push to a specific deployment

Mazen Chami:

Key? Yeah. Yeah. I think you guys do it in a different concept, in my opinion. Personally I think that's a more, how do I say this, A more streamlined approach that you guys follow with the BUILD profiles, because I think that's a little more how we would follow the process. So it's straightforward, you need to push a over the air a bit to preview, boom preview validates it done, let's get it into production done wherein we merge it to Maine or even do that from Maine specifically if it's just a JavaScript update and it's something we actually toyed around with for the Chain React app. I keep mentioning that app because that was one that it's open source and we can reference to, and I'll put in the show notes, the pull request for over-the-air updates, but we had over-the-air updates ready to go and we built such a stellar app, we never had to use it.

Robin Heinze:

When you have an app that's being used over a two day period and you don't have time to go through an app store review process,

Mazen Chami:

No, they would be released a week after the conference. The videos would be out before you get the release out.

Robin Heinze:

I am still a little bit curious whether, so there's differences in how you approach over the air updates, but are there differences functionally for developers in what they're able to do and what they're able to accomplish?

Quin Jung:

So when Code Push went away, a lot of people went to us and they said, Hey, there's all these things that we expect to be done over the air update service. Can you guys do it? And for the most part, yes, as Mazen had said before, a lot of concepts we have, but they're called something different. So instead of the deployment key, we have something called the channel, and that's basically the environment that your build runs in. So all of that, it works very similarly. There are some niche cases though that don't quite map and in which case some people who really did rely on that in code push are a little bit sad. But what are some of those niche cases? I'm curious. Yeah, so in code push there's something called, I want to call it environment surfing. So for example, if you had a build that was in the staging environment in Code Push, there would be APIs that you can run to switch it over to a production environment from the client. So not from the server side, but running the build. You can on your

Robin Heinze:

Device, you can be like, I'm going to switch this to a different,

Mazen Chami:

Yeah, yeah. Whoa. It's almost like AB testing in a way.

Quin Jung:

Yeah,

Mazen Chami:

It gives you the ability to leverage AB testing

Quin Jung:

And it was a use case that we never thought would occur in production. So we do have this functionality in terms of development client builds where in development you can switch all these environments and stuff, but at the time we were like, dang, people are doing this. They're switching it at runtime from the client in a production environment. And so that's one thing that we were surprised to learn about and I'd say the past couple weeks we've been working to get that functionality on par to be able to switch that if people want it. It just wasn't something that had occurred to us at the time.

Robin Heinze:

People do some weird things. I'm always shocked at the things people rig up to do in their apps. So yeah. So you said it sounds like you guys are working on building some of these features that App Center folks were asking for.

Quin Jung:

So as of today, it is possible. We haven't released the docs for it, but as people start coming to us, we're like, oh dang, there is some niche functionalities that

Robin Heinze:

It's like the Starbucks secret menu right now

Quin Jung:

Or the internet secret

Robin Heinze:

Menu. Yeah, you got to know someone who can give you the deep. That's funny. Okay, so that was distribution including Code Bus. The last couple of things that App Center provides are diagnostics, a crash reporting and analytics. So can you talk a bit about what kind of options people have either in the expo ecosystem or otherwise for crash reporting and analytic?

Jed Bartausky:

Yeah,

Quin Jung:

So for crash reporting, when I think of that is the kind of product where if an error occurs, you can go to some kind of dashboard and be like, oh, this was my error, this was the Stack Trace, and not just the minified stack trace. You can actually see it map to right the actual with like,

Robin Heinze:

Yes, that's the worst when you go and you see the error, but you're like there's no stack trace that I can actually use.

Quin Jung:

Yeah, so I'd say on the server you can get away with that, but for mobile development you need to have that source map that takes that minified code and brings it back to the code that is actually readable, especially with Hermes. I will say we do not have a product like that for EAS, but the one that we do recommend is Century, and it's because we've been working with them for so many years, we collaborated with the Century React native guy, his name was Christophe Wooldridge. Yeah,

Robin Heinze:

We had him, we actually just had him on the show a couple weeks ago.

Quin Jung:

Very cool.

Robin Heinze:

Talking about Century and React native, they're a really great team and they're very React native. React native is a first class citizen to them, not just a like, oh, we need a rapper around our iOS SDK for React native. And we are big sent fans around here too.

Quin Jung:

Yeah, we collaborated with him last year with Evan Bacon and the attention to detail that they put into that repo is quite impressive. So for that reason is why we would recommend them because they've got really good integration with React native.

Robin Heinze:

Well, crash reporting is so complex, it totally makes sense that you want a service that's dedicated to that. And so I'm really glad that we have Sentry and that they have such a close partnership with Expo because you guys can do what you're really good at and they can do what they're really good at and we can have both. There's other options out there, obviously Crash Lytics, bug Snag, Datadog also all have solid React native SDKs. I'm using bugsnag on a client project right now. I've used Crashlytics in the past. So you have a lot of options for crash reporting. And I think anecdotally, I think most people out there were probably already using a lot of these other services for their crash reporting anyway and not necessarily app center. So I'm not seeing it as a big loss.

Quin Jung:

So I'd say one key thing to look for on how good their integration is with React native for crash analytics is whether there's source map uploads options for both your build and your over the air update. So I will say over the air update is one thing that is missed a lot in a lot of documentation and there needs to be a way to link that. Otherwise if you run it over the air update and you don't upload the source map for it, you're just going to get minified gibberish.

Robin Heinze:

Oh, I never thought about that. That's a really good point because it's a brand new JavaScript bottle, so you'd have to have brand new source maps for it. That makes so much sense. So Sent has support for over the years. Source map

Quin Jung:

Sent does, and I also took a look at bugsnag and Bugsnag definitely does as well. I don't know for sure if Datadog and Crashlytics have it, but yeah, that's just the two things to look for. Upload your source maps for build, which is usually done in the config plugins or the build steps, but also over there updates where there needs to be a way to upload that.

Mazen Chami:

It's a good call out,

Robin Heinze:

Really good tip. So if you're doing over-the-air updates, make sure that you choose a crash analytics provider that supports source maps for your OTA updates. Do you have anything else you want to add to that section? No, no, just that one thought. Thanks. Cool. I love it. So the last app center feature that we'll talk about is analytics, and that covers just insights about your app, how you users are using it, tracking events, what things they click on and what screens they go to. App Center provided analytics. Does Expo provide an analytics solution? Maybe there's a new one coming.

Quin Jung:

Yeah, so we have something called EAS insights. It's in beta mode right now. So the way I think of it is there's general analytics and incidental service specific analytics.

Quin Jung:

So for example, we have something called the expo insights package where if you install that, you'll get general analytics like what OS version are your users running app versions, how many users in general do you have? And then there's incidental insights. So for example, for EAS update, we do get stats when people ask what is my newest update? We do send some small statistic packages with that. So for example, we can figure out what the current updates people were running was whether they had failed installs and they had to roll back to the original update, how many times their app crashed. And I would call those incidental insights that we can use and together they can all put, we can get a bigger picture on what's happening.

Robin Heinze:

That seems really, really helpful because no, I mean knowing which OTA updates they installed, like, oh, have they installed the latest batch? Okay, well that's why it's failing. Or they installed the latest update and then they had to revert because it failed. Okay, well then that helps you pinpoint where the problem is. Yeah, so that seems really, so you said it's in

Quin Jung:

Beta? It's in beta. And from the update side where I personally want this to go is you get all this data from people who have had their apps crash and from other services that people have, and you can use it to paint a picture of was this update healthy? What are the state of these person's users? But once you have that data, you could expose an API to create actions, automatic actions of that data so people can have a plan to be like, oh, well if there were X amount of crashes or whatever, you just automatically take an action and that can be specified by the developer, but when you have enough of those, that becomes a very powerful thing.

Robin Heinze:

Oh yeah, that would be amazing. Oh, if there's 10 crashes with the new update, automatically revert them to the previous one or something like that.

Quin Jung:

And with any release, especially say if you have something like 20,000 people who've installed the app, there's always going to be some baseline percentage that have their app crash. But when you start noticing a higher rate where it's statistically significant, then you can have enough confidence to be like, oh, there was something wrong with this update in a way that wasn't wrong before four. Right.

Mazen Chami:

Those are the people usually running the old oss, old Android devices

Robin Heinze:

As a dev. I'm not satisfied until it's zero, but that's never happened.

Quin Jung:

Yeah, there's always going to be somebody with an old update or an old os. I feel like that's one of the rules of mobile computing. There's always going to be someone with an old app version, an old update or a crashing update.

Robin Heinze:

One of the backend devs on my current project is still running. He's running an an iPhone 11 with I don't remember what os, but it's old and I'm like, you're a developer, come on. Awesome. So does IS insights, is it all sort of passive insights or is there a way to do more intentional insights? I want to send an event when my user does this thing in the app?

Quin Jung:

Yeah, so in terms of intentional insights, we have something called the expo insights package where when it makes network requests, it is for the purpose of statistics for insights, whereas the passive insights are more for expo updates where especially since we have this open source protocol where we say, Hey, this is what we expect the update service to do, and people rely on the implementation of this protocol, which is expo updates package, and they run their self-hosted solutions on that as well. You can't just have network requests for the sole purpose of statistics, at least for expo updates. You can send them incidental to if somebody is wanting an update, you can extrapolate information from that. But for the expo updates package itself, you wouldn't want to be making these extraneous network requests in the future. Where we see this as to strike a balance is if somebody had both expo updates and the insights package, you could use the insights package to send more richer updates from the expo updates package so that it'd be expo insights that is responsible for sending those intentional network requests, but it would be because the user or the developer wanted it as opposed to just having export updates.

Quin Jung:

And you can see what we don't want is having somebody look over the network and be like, why are there all these insight requests? I didn't know this was a thing.

Robin Heinze:

Basically what happens when I open my network panel in Chrome on any website ever, I'm like, what

Quin Jung:

Are all these requests? Yeah, honestly, my pet peeve when you install a package and you're like, I want it to do X, it has one job, but it just sends a huge stream of network requests for insights and statistics, and if people don't want that, then you just don't send that. Versus if they had an actual insights package where it's more intentional,

Robin Heinze:

Seems like you'd at least be able to batch them somehow. So it's not just firing off a request every time they touch anything,

Quin Jung:

Which is when you say the batching why it's more an intentional thing when you use Expo Insights where it's kind of like the Datadog Stats demon where it's running in the background and it batches things and does it in an efficient way versus having all these other packages that kind of do their own stats. You can batch them all in one insights request if there was a specialized insights package.

Robin Heinze:

So that actually covers all of app center's main features. So it feels like Expo has quite a few tools that can help people move away from App Center. Obviously it's not a 100% one-to-one replacement, but there's quite a lot here for people to use because all this is happening. It seems like you're building a lot of new services and features. What's in the immediate future free as what can people expect the next few months to bring for EXPO and EAS?

Quin Jung:

Yeah, so I'd say in the next 30 days, we're going to be releasing something called workflows where as I was describing before, where you can have this YAML in your build that says like, Hey, run these test steps or these custom commands. So we're generalizing that where you cannot just run it for just builds or tests. But say if you wanted to automatically register people's devices, you could or run updates automatically and chain them however you wanted, you could. And when people look at that, I'd say the first thought that comes to mind, especially when I first looked at it, I just thought, oh, it's starting to look a lot like GitHub actions, the way it's declared and everything.

Robin Heinze:

Well, you first had workflows, I was like, sounds like

Quin Jung:

GitHub actions.

Robin Heinze:

Yeah,

Quin Jung:

Exactly. And so I'd say that is the next step for us to be able to run more custom jobs in ways that people in our ecosystem need. I'd say one differentiating factor is that for GitHub actions, what they really excel at is say it's integration with GitHub. So when you run a commit or open to pr, it's really easy to see all the jobs and all the artifacts that were associated with that.

Robin Heinze:

This is my big argument for GitHub actions over Jam's. Personal favorite is Circle ci, and we used it for a long time and he'll still get into a debate with you if he has his choice about CircleCI, but I can't get past how convenient GitHub actions is because a lot of the things you use CI for are related to when you push new commits or push open new pull requests, and it's so nice to have it tied so directly to your code.

Quin Jung:

And in Jam's defense, if you look at a commit, you could integrate Circle CI with that, but it is because of GitHub, like GitHub's website that allows you to see that link. But if you went to their CircleCI website, you'll see in chronological order all the jobs that were run. But if you look at a particular job, you'd be like, how did I kick this software? Did this come from

Robin Heinze:

CircleCI is really great, really powerful. It has cool things like getting into a command line where you can actually type around and see what is happening, like

Mazen Chami:

Shell into it, SSH into it,

Robin Heinze:

Which is really cool. And I think that's one of the reasons he likes it so much, and there's a lot more like concurrency features and things like that. But for 95% of what I do, I'm trying to run my tests against a PR and GitHub is way easier.

Quin Jung:

So I say a big thing for CICD is to make sense of the artifacts and the jobs that are produced. So GitHub action excels in that you can see everything that's associated with the commit. I'd say one gap that is there right now is if you cut a release, it's very difficult to see end to end all the artifacts that are associated with the release. So everything from going to the app store, all the builds and all the updates that are associated with say a branch cut or something,

Robin Heinze:

And

Quin Jung:

The state of that or the state of the state of what are the release candidates, what got approved and what made it to the different app stores. You could do that in GitHub, but it's not quite built for that in terms of a release management system. And that's kind of where we see the integration for our workflows shining.

Robin Heinze:

Interesting. So you're able to track an artifact through your pipeline and see, oh, did it pass? Did its, here's the artifacts from its maestro test run, and here it is in QA and staging and prod and et cetera. Is that

Quin Jung:

Yeah, yeah. And to be like, who qa? This, who approved this? If the ceo, the marketing guy wants to see the newest approved candidate, they can just scan in the QR code and there's a workflow for that to let that happen. But to see all the artifacts and all the flows as it relates to a branch cut or a release is something that we want to better support.

Robin Heinze:

Yeah. Yeah, it really seems like the best of GitHub actions and EAS kind of coming together. Yeah, right now it is a little bit disconnected. We will have our stuff running on GitHub and then we have our separate stuff in Expo, and it would be nice to have them come together. Unfortunately, we are quite out of time. This was a really, really great chat. I don't have a mom joke unfortunately. Moz, do you have a dad joke? Maybe we'll switch it up.

Mazen Chami:

Yes, I actually do have one.

Robin Heinze:

Go for it.

Mazen Chami:

And this is courtesy of Jamon, so double dad joke, how did the tooth cross the river?

Robin Heinze:

I don't know how

Mazen Chami:

On the tooth ferry.

Robin Heinze:

Oh my goodness.

Mazen Chami:

Until next time, folks.

Robin Heinze:

It took me a second. See, I think I appreciate your dad jokes more than jamon appreciates my mom jokes though. Jam's

Mazen Chami:

Always like love you do it. Until next time, bye.

Robin Heinze:

Yeah, that is it for this episode. Thank you so much, Quinn, for coming to talk to us about EAS and App Center. We will see you all next time.

Jed Bartausky:

Bye. Thank

Robin Heinze:

You for having me. Anytime

Jed Bartausky:

As always, thanks to our editor, Todd Werth, our assistant editor, Jed Bartausky, our marketing and episode release coordinator, Justin Huskey and our guest coordinator, Mazen Chami. Our producers and hosts are Jamon Holmgren, Robin Hines and Mazen Chami. Thanks to our sponsor, infinite Red. Check us out at infinite.red/radio. A special thanks to all of you listening today. Make sure to subscribe to React Native Radio on all the major podcasting platforms.