Todd Werth:

Welcome back to React Native Radio Podcast, brought to you by random house guest.com. It's like chat roulette, but for guests, episode three 14 announcing expo workflows with Jon Samp.

Mazen Chami:

Hey everyone, I'm Mazen and we're React Native Radio. As you can tell, I'm all alone today. Who knows where all my other co-hosts are. James's probably riding his tractor Robin watching Formula one reruns. Who knows? Anyways, I'm all alone. I'm kidding. We have an amazing episode lined up for you and we have a amazing guest on the show, Jon Samp. Jon Samp is the head of product at Expo. He has built multiple React native and expo apps over the years, including one at Code Academy that was featured on Apple's app of the day and another that helps people brew specialty coffee that he took to New York's coffee. That's very cool. Jon, welcome to the

Jon Samp:

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

Mazen Chami:

We're glad to have you. I really want to hear about this coffee specialty coffee app that you built.

Jon Samp:

Are you into specialty coffee?

Mazen Chami:

I dunno if I'd say specialty coffee, but I'm into coffee. Yes, I needed to keep me awake half the time, but yes.

Jon Samp:

Well, great. We should be friends, that's for sure.

Mazen Chami:

Yeah, that's awesome. Yeah, every year when we have our annual retreat, we do a coffee exchange. It's usually you bring local coffee from where you're at and we exchange it. I usually bring coffee from local roasters here in Durham and this year during the exchange I got coffee from Jamon. He was away in Hawaii and he got one from a local grower, I believe out in Hawaii. Haven't given it a try yet. And then Leon, who also works at Infinite Red, he brought some beans from South Korea for me to try too, so.

Jon Samp:

Well that sounds

Mazen Chami:

Awesome. Coffee nerds here. Yeah, yeah. Real quick before we get into the episode, what is your favorite bean?

Jon Samp:

Oh my gosh. Well, in terms of specialty coffee, I really love Onyx Roasters out of Arkansas and if I had to pick one pretty normal specialty coffee guy, I really like Ethiopian coffees natural processed if you're into that kind of thing. I'm very fruity, acidic.

Mazen Chami:

Yeah, that's usually what we do. Kind of our morning ritual over here. Awesome. So before we get into the topic, let's hear from our sponsor. 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 have been doing this for nearly a decade. If you're looking for React native expertise for your next project, hit us up at Infinite Red slash Radio. Don't forget to mention that you heard about us through the React Native Radio podcast. Alright, let's get into the topic without giving it away too much. I'm going to name our topic for today, expo workflows with Jon Amp, but before I go into a little bit what that is, Jon, tell us a little bit about yourself and your journey that led you to Expo and where you're at today.

Jon Samp:

Yeah, so I've had quite a journey with React Native and also with Expo in the past, like you mentioned before, I was working at Code Academy and trying to help people learn how to code and one day we were thinking we should really have an app that allows people to practice the stuff that they learn so that you can learn it better.

Jon Samp:

And the problem was I only know React and so I was like, well, I can't do that. But then someone introduced me to React Native and I started building an app and then I heard about Expo shortly thereafter and it was really fun. I loved working on React Native, it was so cool to be able to make genuine stuff with React native and I was like, this is so powerful. As I started working more with it, the app did pretty well and I loved the tools. I ended up reaching out to the expo team and talking with our CEO Charlie. He was like, wow, I have your app on my phone actually. And so we started talking more and I ended up joining the company. That's been almost five years since then. And so since then I've made a variety of apps. There's a coffee one. I made one for playing the Game of Scrabble.

Jon Samp:

That's awesome.

Jon Samp:

One thing I don't think is said enough about React Native is you can kind of make apps for fun. You do websites,

Jon Samp:

Which

Jon Samp:

You can't really do as well if you need to do both Kotlin and Swift and stuff like that. So it's just yeah, I find that really enjoyable.

Mazen Chami:

Totally, totally. Yeah, react native has an edge on all the others right now and we can go into all that, but I think we're preaching to the choir on this podcast anyways, so I think one cool thing about this recording when it comes out, expo SDK 52, which is technically still in beta, probably will be released shortly before this episode's released. That's come out and that's a huge release. Can you tell us a little bit about that?

Jon Samp:

Yeah, this is a massive release. Even if you look at the release schedule this year, it's been almost six months since we released the last SDK.

Jon Samp:

The reason for that is because of the new architecture. It is default in SDK 52 and turned on and it's pretty awesome. It speeds everything up and we've been trying to make sure that all of the libraries that you use work with SDK 52 and the new architecture, but it's not just that there's new expo video libraries, there's the expo camera libraries where we've made improvements to SQL and just so much stuff. I was actually tasked with making the image for SDK 52 and I was like, how do you do this? There's way too much stuff in here for me to focus on one topic.

Mazen Chami:

That's awesome. Yeah, I agree. There's a lot. I think our listeners should go and read the blog article that's probably been out by now for a while. A lot of good stuff in there and a lot of stuff that I think I'll be leveraging with my client at any point when it comes out. So let's actually get into the specifics of our topic expo workflows. Can you, without going too deep into it, what is workflows and why did you all choose to go down the rabbit hole of creating EAS workflows?

Jon Samp:

Well, yeah, maybe I can talk about how we got here and it's really been in a direction we've been going for a while. So we have services that help you take your project and make it into a production build for iOS and Android. We can also submit it for you to the store and we handle all of the credentials there. And then we can also do stuff like send Overthe air updates. So if there's a bug fix or something, you can get that out to your users quickly. One thing that we've noticed is especially with the build product, people will make a build and the thing that you want to do next is you want to submit it to the store. And people kept on asking for that and so we ended up kind of hard coding that into the EAS build command. And so now there's EAS build baes Auto Cement that just if a build succeeds it automatically submits it to the store. And this kind of opened up a rabbit hole of people asking us if we could allow them to do about a million other things. As you can imagine, I mean you work with other developers, everybody has their own release process.

Jon Samp:

I'm sure you understand this. Yes. So this got me really interested in what do people want and how do people want to automate the release process, especially around our tools. And so we talked with 50 people and 50 of our customers at the beginning of this year, and I just started asking them how do you take features that your developers are building and how do you get them out to your users? And as you can imagine, we got about 50 or even a hundred different replies to that, but people would say, okay, I make a build then I want to run an end-to-end test with Maestro, and if that succeeds, then I actually want to go and send that to our CEO to make sure that they understand what's going to go out to the app stores and then once they sign off on it, I want to submit it then. And you can imagine there's just a bunch of different variations of that. And so more and more we started realizing, okay, we need to make something that's a lot more flexible. We need to allow people to do more stuff than just make a build and then submit. That's one good use case, but now we've identified about 50 others.

Mazen Chami:

Totally, totally. Yeah, that's good. So this is your whole workflow post-development, getting into the stores and automating it and giving you that automation capability with EAS At the end of the day, ES does an amazing job with the developer experience right now. So I think adding onto that great developer experience takes it to a whole other level. Tell me a little bit more about workflows. Dig into, it sounds like A-C-I-C-D platform in general. What more is it? What does it give the users?

Jon Samp:

So EAS workflows is A-C-I-C-D service, but it's built for expo and react native apps. It helps you do specific things for getting your native apps out to your users. So other CICD services, you can write any code you'd like and it will run on their servers. We are a little more niche and refined than that, so we've got pre-packaged jobs that you can run and these help you do build submissions and updates. We also will help you do things like end-to-end tests with Maestro, so you don't have to set up a lot of code to get something like that to work.

Jon Samp:

And just like other CICD services, we've got conditionals on every single job and every single job has prerequisites that you can set so you can start automating a release process with your team. One of the things that customers told us a lot was they're using our Bold product, but they're also using something like GitHub actions for a bunch of stuff like, I don't know, running TSC running lint and running unit tests. And so the way they have it set up is you use GitHub actions to do all of that stuff and then you call to EAS build and then the GitHub action waits until the build is done and then they'll do something else with GitHub actions after. So they ended up having these two CICD processes with two different YAML configurations and it just becomes this mess. And so this will allow people, everything that you're doing with your app should be able to be done on EAS itself, so it should reduce the surface area of configuration that you need to do as a team.

Mazen Chami:

That's awesome. That's cool. So I do like the idea of these managed jobs that you're talking about. So with the maestro tests, I do leverage it currently on a client project that I have. It stays within GitHub actions. Can you tell us a little bit more about these pre-packaged jobs or managed jobs?

Jon Samp:

Yeah, so these pre-packaged jobs, I think a really good example is the maestro test one, which is for end-to-end tests. So we actually have specific workers and servers that are great for certain types of jobs. So if I make an Android build, we've got these things called C 3D machines that are very fast at creating Android builds. We just released those this year and they're like 40% faster than they used to be, which is kind of wild.

Jon Samp:

With that though, they lack the ability to spin up an Android emulator. So for the end-to-end test one, we're able to use a different type of machine that it's a little slower for Android build, but it allows nested virtualization, so allows the ability to have an Android emulator and then we're able to take the build from the first fast job and then run that on the second slower machine, but it has the ability it needs to actually run the end-to-end test. In addition, as part of these prepackaged jobs, we're able to look at the inputs of them and make decisions for you. So if you hand us an ID of a build that's Android, we'll just go figure out the correct machine for you. And the exciting part for us is as we get access to better machines, we're able to upgrade those for you without any intervention on your part. So when you use these, you can just expect these to get better over time.

Mazen Chami:

And I think for our listeners that aren't familiar with this, I'd recommend you take a look at it because when my client pretty much said, Hey, we want this whole flow of building maestro tests, confirm link TSC passed, and once it's done, go ahead and push a build out so that it's available and then push via Slack. Actually, I'm even going to go a level deeper via Slack message, our Slack instance, say, Hey, build is ready, click the link here and all that. It's great because all you have to do is like s slash maestro, I think it was es slash slack with your Slack ID of course some configuration, but with minimal configuration, I was able to get it done with a very small YAML file. So I like the idea of calling it prepackaged jobs. You guys really take the developer experience and kind of push it to the limits there, and that's great.

Jon Samp:

I'm glad to hear that you've found use out of those. We talked a lot about how we should name those and put those together. It's really cool that you're using them.

Mazen Chami:

Yeah, we're using them heavily and I do think that ability to keep 'em within GitHub actions or workflows here in the future is great for smaller clients and specifically startups that can't afford Maestro Cloud, for example, can't afford these larger prepaid enterprise tier services, but GitHub actions handle the jobs for them, so there's really no, it's a no-brainer for them at that point. So I've said GitHub actions a lot. Do we need GitHub actions anymore with workflows?

Jon Samp:

With workflows? Well, it depends what you're trying to get done.

Jon Samp:

Do you need GitHub actions? Probably there's probably things that you do that require a more generalized CICD, like GitHub actions. One thing I keep on telling people is you can think of workflows as this refined specialty tool for a specific purpose and for that purpose we want it to work really well. But for instance, workflows can't do everything that GitHub actions does right now. And I want to be really upfront about that because you shouldn't go into it thinking that it's a drop in replacement or something. The goal of it is to help you take your app, get it out to your users, and also get it reviewed through your team and to help your whole team work together. So we've got these prepackaged jobs. You can also run custom code, so it's not just limited to what we have provided for you already. However, we don't have access to all of the GitHub packages. I think in GitHub you can use uses and then say something like at PR comment and have it go comment on your pr, you could absolutely write that manually inside of EAS workflows, but that package, that's that shortcut doesn't exist at least yet in workflows. So

Jon Samp:

There might be some use cases where you'd want to pass the baton between them and use them together still

Mazen Chami:

So you can mix and match between GitHub actions and ES workflows at the end of the day.

Jon Samp:

Yeah, certainly.

Mazen Chami:

And you can trigger jobs from each other easily too. So you could start off with lint SC checks passes, alright, workflow, go ahead and do all this stuff for me, come back, actually need you to do something else and GI up actions. Okay, now let's go ahead and send our builds out, send our Slack messages out and all that kind of stuff. So baton passing does work, so it gives you the ability to kind of leverage both of them.

Jon Samp:

Yep.

Mazen Chami:

Awesome. And correct me if I'm wrong here, but this will all live on the, I guess it's expo dev dashboard,

Jon Samp:

Am I right? Yep, that's correct. Yeah. One of the things that's going to happen as you use this is you're going to start making builds, updates, submissions. Your whole team will do that. A lot of people are already doing that just with the CLA commands or with GitHub actions, but as you've got more artifacts, we are going to help you organize all of those for your team. That's really a big thing that we're going to be working on next year is helping organize all this information to make it really easy to know what is the development build that I should be using as a developer right now, what is on the app store and how is all that stuff going, how's it doing? Those are definitely things we want to

Mazen Chami:

Answer. Awesome, awesome. I now know a little bit about what ES workflows is and how it functions. How do I set it up? What's the difference?

Jon Samp:

So to set up an EAS workflow, it's very similar to GitHub actions or even CircleCI. All of this happens with YA yaml. So if you love yaml, you're going to feel right at home inside of your

Mazen Chami:

No complaints

Jon Samp:

Yet another markup language, right? Yeah,

Mazen Chami:

Exactly. So

Jon Samp:

I actually just learned what that meant. I spent my entire development career for the last eight years having no idea. I was like, oh,

Mazen Chami:

Markup. Yeah, you yet another markup language.

Jon Samp:

Yep. Anyway, so inside of your project you will create a directory called EISs slash workflows, and then inside of there you can drop a YAML file. Now I want this to be the most interesting radio show you've ever listened to. So we're about to talk about Yam ml. Yes. YAML Radio. So inside the YAML file, you can give it a name, you can give it a trigger when you push to GitHub or when you open up a pr, and then it's got a key for a list of jobs. And the list of jobs, like I said earlier, can have prerequisites, can have conditionals and can do all of this stuff like build, submit, update or do custom code that you write for it to do now to trigger

Mazen Chami:

These, and that's part of the prepackaged ones that you were mentioning earlier.

Jon Samp:

Those are the prepackaged ones, so you can drop all of those in and then can also write custom code as well.

Mazen Chami:

Cool.

Jon Samp:

Now to actually run these, there's going to be two ways to do it. And so one thing that other CI providers I find it difficult to do is when you're developing, you have to make the trigger of your workflow true. In order to get the workflow to kick off, I've got to push to GitHub. So if I've got something on main, you'll just see me writing testing 1, 2, 3 on main 15 times as I try to get the yaml correct. I think there are some ways you could probably run these in different ways, but anyway, that's just how I do it.

Mazen Chami:

That's how I did it the other day, so keep going. It was like try one, try two, it'll work this time. Nope. Trying again. Yep, yep. Yes. And even

Jon Samp:

Eventually

Mazen Chami:

It feels

Jon Samp:

Done and it feels so public to the rest of your team when you do that.

Mazen Chami:

Exactly.

Jon Samp:

Yeah. So one thing we're providing as well is A CLI that will be able to run these. So instead of having to push to Maine to get this to trigger, you could run EAS workflow, call and run and then give it your YAMA file,

Jon Samp:

And then you can also provide it with inputs like the branch name because you'd usually have the main branch name or maybe your PR branch name as an input to the workflow, which might affect some stuff like what update branch or something. And so you can run it from your command line, it's going to push it to our server and run it on the actual servers. It will run on so it's not running locally and it will run in the environment that you would expect it to run in production. So that should make it easier to develop these things without having to push a bunch of commits. It also, I don't know about you, I really like releasing stuff manually often, automating all that stuff is great depending on the team you're on, but I kind of like having a lot of control, so just being able to say workflow, run, release my iOS app whenever I feel it's ready, that's kind of nice.

Mazen Chami:

Yeah, yeah, I agree. That's cool. I have a note in here and I'd like to hear a little bit more about what you think and if you can give some background about it, but you mentioned in our prep about fingerprint hashing and checking. How does that exactly work within this workflow pipeline?

Jon Samp:

Oh yeah. So that's something that people have been asking us about for ages and people have been figuring out ways to do it themselves in some ways too, which has been really cool to see.

Jon Samp:

So pretty much if you're not that familiar with fingerprinting and updates, every single native build that you do has a certain surface level of APIs and we call this the fingerprint of it. And when you send an update to it, the update has to be compatible with all of those APIs. Otherwise the update or the metro bundle on top is not going to work. So we've got to make sure that both of those are compatible so that you can push updates out to not only your users, but to send preview updates to your team for stuff like PR reviews, stuff like that.

Jon Samp:

So one thing that we'll be able to do with workflows is we've got this new thing called fingerprint that we've been testing out, and it takes a fingerprint of every single build that you make and also all of your updates. And while in a workflow you can take the fingerprint of your current project and then you can see are there any for this particular fingerprint already made. And if there are, you can publish an update. And so if someone wanted to preview that in the development client, they could preview it within a minute or something, but if you've added a native dependency or change something on the native layer, it could kick off a development build which will take five or 10 minutes and then it could tell them to go download that. So just removes a lot of decisions you have to make and a lot of understanding of compatibility layers between the native side and the metro update side.

Mazen Chami:

Cool. Yeah, caching right there, caching out of the box for you so your builds, you don't have to wait those 30 minutes to get a build ready to validate the PR when all you did was change your PR template for example. It should be smart enough to kind of do that for you. And I think that's also a really cool thing to, I'm just thinking as you were talking, you were saying how it's basically caching and that's a cool thing where the workflow can potentially decide for you, am I going to do an over the air update versus am I going to do a full build and push to the store for you using the auto flag that you mentioned earlier to get that out there for you. So endless possibilities where you don't have to really think about it, it's essentially set up for you and that's pretty cool and all available in the ui. I love that.

Jon Samp:

Yep.

Mazen Chami:

That's great. This all sounds expensive and expo, you all released an article earlier that you were doing something opposite to the market where you were reducing your prices rather than increasing your prices, which I'm sure a lot of the customers appreciated. How does this work pricing wise? Is it free? Does it come with a cost? How does that work?

Jon Samp:

Yeah, as you mentioned earlier this year we actually lowered quite a bit of our prices. Mostly I personally, and I think all of us really care that we provide services that help people but don't try to price gouge them.

Jon Samp:

Obviously we're trying to run a business, so yeah, I'm going to recommend the things that we're working on and hope people will buy them, but we're also really cognizant that people want to self-host stuff. They want to run this stuff locally or do it in their own way without necessarily paying us or hosting it elsewhere. So that's been very important to us too. And so one kind of indication is if everyone wants to self-host and not use ours, we should really talk to them about price and be like, maybe our price is too high. That's kind of what happened earlier this year and we thought like, okay, cool. We need to lower this. It's not being useful enough for what we want to affect anyway. So with workflows, it is a paid product. The way that we're going to charge for this is when you make builds just like you do today, they're going to cost whatever builds do now.

Jon Samp:

So most builds are between one and $2 if you're using our medium sized worker, and it's going to be the exact same thing on workflows. It's just like running EAS build, except for now you'll run EAS workflow run. It's not getting replaced or anything like that, but the pricing will be the same there. Now we're also introducing these new custom jobs, and since we're running those on our servers, we would like to make sure we can keep those servers up. And so we'll be pricing that based on CI minutes. Now, one thing that's really interesting to me, and we almost never get to make this argument, which is we're never cheaper than other operations or other CDs or other services

Jon Samp:

Because we're often built on top of them and we're trying to provide different values like making things faster, easier, stuff like that. But with these custom jobs, we're actually going to be very competitive with other CICD services, and at least for iOS jobs, we're actually going to be a little bit cheaper than a service like GitHub actions. And we're also going to provide people with almost twice the cores on the machines, so the jobs are going to get done faster as well. So we're really happy that we've been able to figure out how to do that for those particular jobs, and it's really important to us we can make that kind of job really cheap because it's one of the core things that developers do on our service, and so we want it to be fast and cheap, and so I don't think it's going to be cheaper than anything you could do just by yourself if you wanted to code all of this. That is really not our overall goal, but hopefully you'll find some value in it and if you think it's way too expensive or way too cheap for some reason, you should definitely let me know. Definitely keeping our ears open on that.

Mazen Chami:

Yeah. Yeah, that's great. With the different solutions out there. And you mentioned price-wise, you all are competitive with them, which is great with all these solutions out there. CICD isn't something that came out 2025 this year. 2024, sorry, I'm already thinking of next year. It's been a long year. Yeah, right. I'm ready for 2025. No, CICD didn't just come out this year. It's been around for a while. So it's not necessarily you're reinventing the wheel, you're doing it the expo way. What is the value prop to a listener that is a big circle CI fan, big company, X, Y, Z fan? What is the value prop for them to pitch ES workflows to their employer?

Jon Samp:

There are two things I think of here. First, EAS workflows are going to be really fast for you to set up. We've already talked about the pre-packaged jobs. Those are a couple of lines and you can eliminate any calls to if you're running Fastlane or other stuff like that to coordinate your builds if you're not already using us. So it's definitely worth checking out. Now, as you said, we're not reinventing the wheel here really. We're trying to add a lot of ability to sequence and allow you to do more with what people are already doing with our current products for building and updating stuff like that. Where I think it's going to get interesting is stuff we're going to be working on in 2025 as you sort of accidentally mentioned and let that slip

Jon Samp:

Because

Jon Samp:

We think there could be a lot cooler stuff with CICD that I just haven't seen yet. This is stuff like pulling in your team to the CICD. This is done just a little bit with other services where you can get approvals, but we want to take that a lot further. So yeah, I don't know if I can talk about what we're thinking about doing next year and what we're working on and where we're going

Mazen Chami:

With this. We'll get to that.

Jon Samp:

Okay, we'll

Mazen Chami:

Get to that. Let's make sure our listeners don't our listeners to the whole episode and have to wait until the end for that. Got it. For that there. Right there. Okay, cool. Yeah, that's good to hear. You all are just trying to stay within the CICD, I guess you'd call it framework, have you, but also at the same time, giving the users the whole expo workflow, giving them shortcuts to eventually get to get to the end goal. That's great. Can I use workflows if I am not a full expo or EAS framework, right? Can I leverage workflows to help create my builds for me or do I have to use the EAS build command for that to work?

Jon Samp:

You could leverage workflows to run any command, but it's going to work best for you if you're using EAS build and you have an expo app, at least for now, I really don't want to over promise that you can go and I don't know, start building your other apps with this.

Mazen Chami:

Yeah, I mean you did mention it's pretty specialized. Exactly. And you mentioned you could create your own triggers and your own custom jobs, write your custom jobs. So it is possible, but it just, it's more efficient, I assume is probably the better phrasing here if you are an expo user. Awesome. Before we talk about the future, is there anything about workflows that you feel like we didn't cover that you'd like to talk about?

Jon Samp:

I think we talked about a lot of it. Yeah, we're really excited about this from early testing. People seem to be having a pretty good time with it, so we're just hoping that it continues to go well. And yeah, we're really trying to listen to how are people using this and how can we make it more useful for people? So if that's how you run stuff, how the YAML is structured. We've made a couple of improvements and changes there to other CD services, but it's a lot like the same YAML you would have for GitHub action, so it will look familiar to you or if people have feedback about the pricing or stuff like that. Yeah, we're always trying to listen and make changes and to iterate on that stuff.

Mazen Chami:

So it's not YAML 2.0 or anything.

Jon Samp:

It's called JSO.

Mazen Chami:

Yeah, there you go. I'm

Jon Samp:

Kidding. People will probably be like, oh my god.

Mazen Chami:

Yeah, everyone's signing up. Cool. So I guess, yeah, give us a sneak peek. What does the future hold for workflows right now? We've heard what's coming out today and what's happening, what's coming out in the future?

Jon Samp:

So going back to that original conversation at the beginning of the episode, talking to all of these customers, probably the most interesting thing that we kept on hearing was after people get done with making builds or doing stuff on servers, they then go and talk to their team and they need to get stuff from their team to the next step. And that's something that I just really haven't seen in A-C-I-C-D service, and that's something that we are uniquely positioned to solve or to help people do. And people kept on asking us, can you just do this for us? Can you just send that slack message you were talking about or can you make sure a couple of people approve of this? And then we'll move on to the next step of submitting it to the store. And so next year we're going to be really focused on making this work better for teams.

Jon Samp:

And this means if you add people to your team on expo, you can add them into groups like alpha or beta testers, and then inside the workflow you can say like, okay, notify all my alpha testers that there's a PR that they need to review. Then since we build the developer tools inside the development clients, all of those testers can open that up and then provide qualitative feedback. They can give thumbs up or thumbs downs, and that will be reported back to the workflows screen. And then once you get to a threshold, you could move on to the next step or not. Or you could maybe message someone that you got a bunch of thumbs downs or something and you need to go fix something.

Jon Samp:

To me, this is a way to make your team move faster. And just so interesting because in my past when I was working on apps like this, I would make changes. I'd want to get them out to the store, and then I would spend days at my company trying to get people to test it, to QA it, to get my CEO to look at it, and then it would be almost the next week before I could release it. So it didn't even really matter if I could push out over the air update in a minute or two. I really needed to get those people in the process. So we just kept on asking, why isn't your team part of that process? Why is CICD just in the cloud? Why is it not helping your team be more effective and to communicate faster and better? So that's the hope. You make a change, it goes out to all of the people that it needs to. You also get all of the logs from the tests as well, and given all of that information, it should be very easy for you to make a decision of, should we go to the app store with this, should our user see this? And then hopefully if something goes wrong after that, it's relatively easy to roll back.

Mazen Chami:

Yeah. Wow. I have a lot of questions on this. That is so cool. And I'm actually even just thinking about my current client project where we release the build. Yes, QA will go through it at some point, but before QA takes a look at it, product is also is notified and also taking a look at it and also preparing for when QA looks over, approves the ticket, say a ticket is add confetti on the screen when you tap this button, cool. That's usually my go-to QA is like, yep, I see confetti, I'm good. It goes to product, product looks at it and is not enough confetti. I guess in this scenario they can give you that qualitative feedback, not enough. Confetti is qualitative feedback right there, and they comes back to you and you're able to adjust it accordingly to get that pushed out. That is great because now you are, what's the phrasing here? You're keeping your feedback specific to that build, right? You're not overwhelmed by all the noise of, hold on, was this for build one or build two? Was this for beta build or my current production build? That's a great, that's awesome. Bring in non-developers into the development process. Huge fan of that. And I think that's something that we need to do a lot of

Jon Samp:

And kind of what you're referring to in the background is something that really drives me insane, which is having to bookkeep all of these different build IDs, all of these different branches and getting everybody to know which one they should be looking at. If there was a world we could live in where you just didn't have to organize and bookkeep all that stuff, I think that would be awesome. So that's also part of this too.

Mazen Chami:

Yeah, exactly. It's so much of that whole, you get a Slack message like, Hey, you put ticket 1, 2, 3 in testing and I'm testing it and I don't see it. Well, usually my first question is, what version are you on? It's like, alright, there's a new version out. Thank you. Anyways, I'm starting to go on a rant here. Sounds like you've got some

Jon Samp:

Frustration with some past

Mazen Chami:

Experiences. Well, this is going to help a lot. This is going to help a lot and I think a lot of our listeners, a lot of our clients, the whole idea of the workflow, the idea of getting the code on paper, the code in vs code or cursor down to getting it to the app store can be very complicated and almost like a roller coaster ride. Of course the smoothest part is when we're developing, but once it's out of our hands, that's when things go awol. But also that's where a lot of communication gaps tend to happen, and I think the idea of this workflow and the idea of keeping the qualitative feedback within the build and within the dashboard will help everyone's communication stay in line and stay siloed within it to avoid any gaps that might come out from it all. Does that all sound right to you?

Jon Samp:

Yeah, that's the dream and that's the hope. That's what we're building. Exactly. So really excited to build more of it and you'll definitely see more of that coming next year.

Mazen Chami:

Absolutely. Yeah, and I think this goes back a lot to stuff I've said on this episode and a lot of the different episodes at Expo, you all are really putting the developer experience at the top and you are really exceeding at it and fulfilling it, in my opinion, doing a very good job at it. And even with your beta products, I've used a lot of the beta stuff and loved it. So

Jon Samp:

Thanks.

Mazen Chami:

This is one that I will definitely be using and I'll definitely be pitching right after the recording and yeah, I love it.

Jon Samp:

Yeah. Thanks

Mazen Chami:

Jon. Thank you so much for coming on the show. Usually how I like to end off is where can people find you on socials?

Jon Samp:

So I'm over on Blue Sky and so you can find me over there. I'm at Jon Stamp Dev, that's J-O-N-S-A-M-P Dev. So yeah, come follow me and come chat. I'll be on there. It's great. Awesome.

Mazen Chami:

Yeah, I think I only follow you on Twitter. I'm still trying to catch up with the whole blue sky thing.

Jon Samp:

You got to come over. It's a React native app. It's expo

Mazen Chami:

It is, yeah. Yeah, it is. You got me there. Well, lemme just put it this way. I got over the weekend Friday for our listeners, this is Thursday, but last week, Friday I set up my account and then I didn't open it over the weekend. Monday I come in and I look at it, I'm like, why do I have 50 notifications on here? And I click into the folder and it was Blue Sky and I was like, oh, I guess this is where the fun is now. So everyone's over there now. Is it the same handle on Twitter?

Jon Samp:

Yep, also on Twitter as well.

Mazen Chami:

Awesome.

Jon Samp:

And then if you want to talk to me directly, we have the Discord for expo community developers, and so you can always join that. That's chat expo.dev. There's thousands of people there and the expo team is regularly in there and we're making an announcement. So if you aren't already in there, that's a really good resource to stay on top of everything that's happening and also to ask questions and to talk with people.

Mazen Chami:

Totally, totally. I can agree to that. I'm in that and very high signal. There's a lot of stuff happening over there. Cool. Well that's it for this episode. Robin usually ends it off with a mom joke, but I will give a dad joke to kind of give this off. So Jon, why don't vampires like working on software project teams,

Jon Samp:

Vampires, it's hard to sink your teeth into that one. Why?

Mazen Chami:

That's a very good answer. But no, that's because of all the stakeholders.

Jon Samp:

Ooh, that's good. I enjoy that. I really love dad jokes, so

Mazen Chami:

Awesome. That's credit to the current client project that I'm on. He's probably listening to this. He'll know who he is, so that's awesome. Thank you very much again, Jon for coming on and to our listeners, thank you all and hope to hear from you soon. Bye. See you

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.