Jed Bartausky:

Welcome back to another episode of the React Native Radio podcast. This is a crossover episode with React Universe on Air. Mazen joins Lu Cash from Call Stack and Quinn from Expo to talk about the retirement of App Center.

Łukasz Chludziński:

Hey everyone, welcome to React Universe on air. This is a crossover episode and I have a second host today from React Native Radio. Hello Mazen.

Mazen Chami:

Hey Ash, thanks for having us. How are you doing?

Łukasz Chludziński:

I'm doing great, I'm doing great. Thanks for doing this. This is a second year in a row when in the autumn, let's say we record crossover episode between our podcast and I'm really, really hyped for this one, especially because this is a big one. This is a big shift in React native community.

Mazen Chami:

Yeah, totally. I agree. And it's nice to kind of bring the two different podcasts together and have an episode React native is all about the community and kind of bringing our two communities together is great.

Łukasz Chludziński:

Yeah, yeah. So what are we discussing today?

Mazen Chami:

So we're talking about app centers, retirement and basically what to do next and how your businesses should handle them.

Łukasz Chludziński:

Yeah, yeah. So this was announced this year in March. I want to say they left us 12 months since March 24 till March 25. So we are around five months until the cutoff date and I was browsing through some different repositories here, code push specially, and yeah, they're just going to sunset everything. They're not accepting anymore PRS anymore feature requests, they're just sunsetting it and they basically say, get on with your lives. We are not going to support all of the features that you care about. So we've asked all of you dear listeners on Twitter or LinkedIn, what are the features that you care about from App center and we invited someone that you might be familiar with from company that you are definitely familiar with. So this is Queen from Exfo. Hello, how are you?

Quin Jung:

I'm doing well, thank you.

Łukasz Chludziński:

And yeah, we basically decided the three of us to have a discussion. This is not an interview, this is a discussion about, not about the future of Up Center that was already decided for us, but about the future of our products. How scared should we be, how prepared should we be for March and what are the alternatives for what people are using?

Mazen Chami:

Yeah, I think before we go in, I think for our listeners, Quinn, can you introduce yourself and tell us a little bit about yourself?

Quin Jung:

Yeah, for sure. So I've been working at Expo since the early days, so 2017, and this is back in the days where we all used to work in one small house in Palo Alto, but before that I used to work on AWS on the block storage services. But now at Expo I mostly work on the infra and server side. So in particular EAS update, which is our over the air update service.

Mazen Chami:

Makes sense now why you are our special guest on the episode.

Łukasz Chludziński:

Yeah, yeah, yeah. Spoiler alert, most of the things that you care about from UP center you can do in Expo and most of them and maybe all of them you can do better in Expo. So Expo is a default, a React native framework that is recommended for apps to use and it turns out that they have a lot of functionalities that can cover for app Center. So yeah. Queen, you mentioned over the year updates, and this is my assumption was before we recorded this episode, we're recording this episode and also the community feedback that we gather is that the most cared about feature of App center is Code Push, which is I think it's the first React native over the air update service. At the beginning it wasn't a part of App Center, it was a standalone product company, I don't really remember, but then Microsoft bought it, included it in app center and it was a really, really loved and used it still is.

Łukasz Chludziński:

It still is. And I have this anecdote right before React Universe Con September this year I was talking with the clients of Call Stack and they were asking me about what's up with this code push from up center, we use it, a lot of our clients use it. And they said, okay, so we are writing emails to Microsoft support email that they got on the up center, sunset setting page and all we get, basically all we get is we will get back to you when we know. So in early September, push the standout code push didn't exist. I think they opened sort standalone code push a few weeks ago at the beginning of October or something like that.

Quin Jung:

Yeah,

Mazen Chami:

That sounds about okay. Yeah, that's right.

Łukasz Chludziński:

And yeah, everyone knows what pushes. Basically you can update your app over the air

Mazen Chami:

Without pushing a store build, right? That's the important part because one thing as developers, our biggest I guess gripe with Apple specifically is the amount of time it takes to turn around and make a fix. So say you have something simple where you are changing text on your screen and you don't want to have to sit through two, three days potentially a week of apps or updates and sometimes we hate to say it, but depending on the reviewer, they find another issue with your app that you now have to go and fix and now all of a sudden you have this typo or your app's not working as expected. So over the air it gives you the ability to just essentially change that text immediately so that you can then focus on the more higher level issues that have to go through specifically like native

Łukasz Chludziński:

Code. And basically the native code you can change everything that's JavaScript and the native codes has to stay the same. So if you are interacting with some new library in your code push in your JS bundle, you have to release new native bundles. The native bundles are, so code push bundles are mapped to native bundles to native binaries. So yeah, a lot of people relied on this for years. A lot of our clients at Kohl Stack rely on this. And so there are two parts to this. So one part is you can finally have, you can have your standalone code, code push server. You can still use this or you can switch and use the alternatives. So maybe let's talk first about alternatives. Maybe let's give Queen some space and let's talk about expo updates.

Quin Jung:

Yeah, so our expo updates, our EES update is similar stuff to code Push. So people who are familiar with Code push, you'll have a deployment environment production and staging. We have a similar concept except we call it channels and people usually have a production and staging channel. Most of the main things like shipping your app over the air, we do very similar things. I'd say there are a couple main differences and one of the big differences we have, as you said W you said that there is a JavaScript part and it has to be compatible with the native part. And one of the big things that we've always is that it's really easy to push out a change where the JavaScript part is not compatible with the native part. So I'd say a big thing in EAS update that we've got is something called a fingerprint policy where we get a hash of all your native updates and make sure that whenever you create a JavaScript bundle that's actually compatible because bad things really happen when you push something that's incompatible.

Mazen Chami:

I think that's one major highlight to talk about your fingerprint hashing. I'm not exactly sure, I don't think App center or specifically code Push does that. So that's a good value add. So by going with this alternative, you're going with a different alternative plus one, right? You get a little bit more of a safety net along the lines. And then there's also something you said earlier Lukash about this is the recommended framework by meta. I think something I always mention on React native radio is the developer experience that Expo is putting out there based on everything that we heard from the community and internally at Infinite Red with our clients is code push and app center in general is very bulky and so many steps to use along the way while EAS is developer built for developers and the developer experience is second to none in that concept.

Łukasz Chludziński:

It's also that you get all in one, you have this great synergy within expo ecosystem within expo products, which going to bare bones react native project and using all of those different dependencies like code push, require you to go over different hoops and using different tools, different panels, different CLI in order to achieve basically the same thing. That said, many of our clients, enterprise clients that cost stack has, we don't use Expo for many reasons, but for historical reasons and for legacy reasons as well. And so we have that big setups that use code push, we have it instrumented so that we don't need fingerprint, we know what bundles to handle. And then for those kind of clients it might be difficult to go over the fence and start using alternatives from expo, like expo updates. Even though for vast majority of users it is recommended to just start using framework.

Łukasz Chludziński:

Some of the enterprise users will not, that's just live. And then for those kind of users, it's not an alternative, it's a lifeline in standalone code push, right? So Microsoft open source, the code push and I have some information from people at Cosack working at our own code push wrapper solution. So right now you can deploy your own code push server and this will work only on Azure from Microsoft because this was built with Azure in mind. So it's very bind it let's say on the implementation level to the service that you're using. What we are trying to do is to have it cloud agnostic so that you can run it on Google Cloud and AWS and wherever you want. So that's first. We are working on that right now. The second part is I've heard that they have published, so the CLI, the code CLI is a part of that repository of standalone code push and it's not accessible through MPM.

Łukasz Chludziński:

So you basically have to compile it and then install it and only then you can use it locally. But fun fact is you can still use that production CLI, you just have to provide it a different URL for the server. So that production CLI still works. We definitely will be working on this. We already have a fork, I'm not sure if it's published by the point this episode drops or not, but for code push to wrap up, stick around if you can just migrate to expo, basically it's a better developer experience. If you're starting a new project, definitely don't start with app center.

Mazen Chami:

A hundred

Łukasz Chludziński:

Percent,

Mazen Chami:

Yes.

Łukasz Chludziński:

Don't include app center in new projects and if you want to have just regular code push experience, look out for community support, basically the community support will come. We are already working on it. Ask call stack and yeah, we'll let you know how that goes.

Mazen Chami:

I also want to ask Quinn a question here actually. So based on all that we're talking about enterprise companies, let's stick with enterprise, right? If you're talking with a startup, expo recently mentioned that they're reducing their pricing and all that kind of stuff. So I think startups are all like, okay, yes we can buy into Expo, but the enterprise folks that are out there, usually they tend to do this stuff, stand their own servers and all that kind of stuff, which as a developer myself, I don't necessarily like it or see the value in it. Right? And you just mentioned luas, you have to bundle and essentially create your own CLI, even though it's already there, you have to maintain it right down the line. So Quinn, what would be your, how do I say this? What would be your feedback or what would you say to these enterprise companies from an EAS updates perspective? Like, hey, we have this product and this is why you should use it as an enterprise company instead of going down the formerly Microsoft endorsed product.

Quin Jung:

Yeah, so I would say that the fact that if you guys were making a fork on the client and the server for somebody who has to use the code push framework, you guys are the hero that they need honestly. So I guess the way I think of it is if you wanted to self-host your own update server, there's two ways I think about it. One is to use the open source version of expo updates and the other one is to use the now open source version of Code Push. So I'll speak to two of those and I'll start with the code push one. So there's the client side stuff and the server side stuff. So the client side stuff, I'd say the biggest amount of work that needs to be done is to make it compatible with the new React native architecture. And in addition, as new React native versions come out, having somebody maintain that. So that bit's important for the server at Ash, as you mentioned, code Push has understandably made it with the Azure blob storage, which makes a lot of sense if your entire pipeline was on Azure to begin with, but it's not such an easy sell if your entire stack was on GCP or AWS and having that storage be platform agnostic or at least having support for the other ones like the Google Cloud storage or S3 would be a big deal for people who wanted to host that server bit.

Quin Jung:

So for expo updates, there is

Łukasz Chludziński:

Also, maybe let me, sorry for interrupting, but maybe let me comment on the two things that you pointed out. Yeah, I completely forgot about the new architecture. I was browsing through code push repositories today and there are people requesting this as a feature and like I said, Microsoft is just rejecting everything. We are not adding new feature to this. This will be Sunset, you can fork and add it there, but there are ways of doing this. So basically the integral player allows you to still use code push with new architecture. I'm not sure if you need a patch, which I also saw on that issue. On that issue on GitHub, someone just created a patch. It's a few lines of code and basically they claim that it just work with this few lines of code. But definitely something that you said the community support will be crucial there because you have to support the client, the CLI and the server so that those are three standalone packages that needs to work alongside each other and they need to be maintained. Someone has to take that on. I'm not sure if it's us. I know that we are doing some experiments, but I'm not in the position. No one told me that we'll be supporting it forever and this will be our package all of the sudden. I dunno.

Łukasz Chludziński:

Thank you for mentioning that. You can run EAS update locally as well. You can have a standalone version of it. We had comment on X about this actually the question was what do you use from app center? How do you prepare for migration? Where are you migrating to? And someone said, we don't use App Center, we rely on expo and we are thinking about putting together a standalone expo updates instance. So please, sorry for interrupting, let us know how we can set that up.

Quin Jung:

Yeah, so it's an open source spec that the client or well our expo updates package client is implemented from as well as the ES update server. So it's like open source and you can take a look at it, but basically it's a spec that outlines when the client makes a request for the newest update. Here are the headers that have to be present and when the server responds, here are the headers that have to be present as well as the different HTP response codes and everything. So the expo updates client is an implantation of that and the ES updates server is implementation of that spec. So in theory, as long as you have a compliant server, expo updates would work. So what we've done is that we've also have a GitHub repository for a compliant barebone service so people can fork that repo and make their own compliant server and some people have done that, so as long as it conforms with the spec, you should be fine. We do maintain the client for the new architecture and as well as continuing moving forward with future React native versions. So as long as you maintain your own server, think you should be fine.

Łukasz Chludziński:

That is such a big thing as well, the compatibility with all the new React native versions because expo is always on top of the game, right? If the new React native comes out, you guys are two months forward, you are compatible with the newest React native and it might be hard for this kind of support in open source basically.

Mazen Chami:

Let's also keep in mind App Center, even though we're React native focused app center is not just React native, it's also iOS, Android, swift, Kotlin, objective C zarin,

Mazen Chami:

Yeah,

Mazen Chami:

IO Windows. I always forget that, right? I always think it's a React native product. We're always using Air, right?

Mazen Chami:

Yes.

Mazen Chami:

So speaking of community support, we don't know what would happen with it when it becomes fully open source. I mentioned the story to you both earlier, but I'll mention it on air for listeners if you've heard of the product Parse before. Parse was a really good, I believe it was MongoDB with, it was like serverless server functions. I don't remember, it's been a while since I've used it, but it was in one product to have your backend API requests and a database all in one. And for startups it was a great tool. It was like your, what you call now superb base and firebase type of stuff and it did it all for you. Startups loved it. Facebook bought it, everyone was like, oh perfect, now it was Facebook, then Facebook is going to maintain and take care of it. Well Facebook Sunset it opened a fork and had it open source and released it to the public to maintain and just walked away from it.

Mazen Chami:

Now at least App Center is giving you, they gave us close to a year, right? Facebook at that time did not. I think it was a quick turnaround and as startups, people were left hanging to dry and I remember trying to set it up on, what do you call it, on Amazon? And it took a while for a small startup to do it and eventually we did it and we were using it, but at the end of the day it seemed like a lot for a smaller company to have to maintain enterprise. Sure. But the point I'm getting at is with App Center, it's not just React native, there's potentially a larger community out there to maintain it, but keeping in mind if you're having zarin developers, native developers maintaining it for their cause, will the React native aspects of it fall behind? And at that point reaching for an alternative like EAS is a better solution because they are React native specific, right? But the code push was React native specific initially and then they eventually opened it up to others. As far as I remember. I could be wrong.

Łukasz Chludziński:

I don't think so in just native words it doesn't make sense to have JavaScript bundle.

Mazen Chami:

Yeah, but I think you can push other stuff

Łukasz Chludziński:

Maybe.

Mazen Chami:

Yeah, I'm not exactly sure. This is not really well researched. It was something I was just literally thinking of right now as Quinn was talking

Quin Jung:

This topic, if it interpret if it's interpreted code in theory be it could be used for over the air updates.

Łukasz Chludziński:

Yeah, welcome everyone to the two best React native shows on the planet. There we go. But yeah, so when I read through Microsoft Docs on app center and how they tell you to migrate, they are steering you towards the tools that are much more powerful usually from Microsoft umbrella, from Azure pipelines and all of that. But what I see between the lines there is App Center is such a specific use case and Expo is even more specific because it's only for React native but app Center in terms of build functionality, it could build only mobile applications. They are steering you towards the systems that can build the web applications for you and mobile application and all of that. Also from perspective of all of the features there are steering you towards those more powerful tools that can be embedded in multi-platform products and not only towards mobile products. So I think that's something that might have impacted the decision there. Why are we supporting this mobile only tool chain if we have so many other products that support that mobile spectrum but also support wider spectrum of different app categories basically. So how about we move on with our walkthrough walkthrough through app center?

Łukasz Chludziński:

So we talked about Code Push, this is definitely the biggest one. So what I'm looking at my notes here, what were the second most important issue there for our listeners? I believe it was build related. Yeah, I think Build and then releasing

Mazen Chami:

Distributing. Yeah,

Łukasz Chludziński:

Distributing, yeah was like two second place. So let's go through Build, right? So yeah, I think Build, again, when I looked at documentation from App Center was not free actually on Microsoft you had to pay for that and you had some machine power like Mac oss somewhere in Microsoft Cloud that allowed you to build it. And I guess if you are in this ecosystem of App Center, you already use Code Push, you might just as well just use build. It was simple to use, it did the job. What are the alternatives for that? Should we start with EAS?

Quin Jung:

Yeah, sure,

Łukasz Chludziński:

Yeah, yeah.

Quin Jung:

So to recap what you said, to my knowledge code push was free and not app center build. They probably did have a freemium model, but because yeah, the Mac runners are very expensive, it makes sense to be charging for that. So the alternative that we have is EAS build. A lot of people are probably familiar with that. When you run the build command in your project directory and you're taken to a website where it shows you all the build steps that go into creating your expo app or your expo binary. I'd say late last year though, we've made it more flexible so that it works not just for a React native app without expo framework, but in theory also this plain native builds. So all the build steps are specified now in a yaml and even for somebody who was just using a plain native app, in theory you could just remove all the React native, all the expo steps and if your app can be specified in a gym file and honestly you can run any arbitrary command, you could build your app on our servers. We've got

Łukasz Chludziński:

What about the XPO key in package json? Do you still have to have that?

Quin Jung:

So we do have configurations where we do rely on certain configuration files so that we're like, okay, this is your project, this is your account, this is how it relates to build. Yes, you would have to have I guess a project ID or I guess what you refer to as the expo key so that we can keep track of those configurations.

Łukasz Chludziński:

I think the big benefit for something like expo build is that you can run it in the cloud, and you don't have to correct me if I'm wrong, but I don't think you don't even have to have a Mac machine in order to just create for iOS. You can build in the cloud and you can submit to the Stars and you can just work on Linux or something.

Mazen Chami:

I know we believe we have a client, I'm trying to remember, we have a client that allows their developers to work on other machines like Windows and Linux like you mentioned. But what they'll do is they'll kick off the job to do the build on the server download and then use it that way within their simulator and code.

Quin Jung:

So I mean to build an iOS app or for the iOS platform, you have to have a Mac machine. There's no ways around it. And for people who have Windows machines, you can't really run Xcode build or whatever. So in that case it does make sense to run it in the cloud, but if you have a Mac machine, everything's open source, so there's no reason why you couldn't pass it in the local flag and have it run on your machine locally as well.

Łukasz Chludziński:

So yeah, the alternative for building, I'm not sure how many people actually build on app center. When I ask among our team leads for our clients and our clients, seems like no one from our clients was using this particular functionality even though we heavily rely on code push and what we basically do is just we use custom configuration on pipelines. We just built it ourself in the cloud infrastructure.

Mazen Chami:

It was the same for us. I think Code Push was actually I think the only feature from App Center that was used on any of our clients in the past. And like you said, for build, we built our own depending on clients' needs and whatever contract they may have had. There's other products like you could use Fastlane actually, which I believe ES build is built on top of. There's other CI CD tools that do building for you, right? There's Bit Rise, there's Code Magic, there's a bunch of different tools out there. I'm sure if you were to Google it a bunch would pop up, but those are the four or five that are coming to the top of my mind right now.

Łukasz Chludziński:

Yeah, Fastlane is such a versatile tool. It's a dependency for all of those others probably, but also you can use it standalone. You can do very magical thing with Fastlane and

Quin Jung:

I will say Fastlane is one of those things that is less painful running in CICD rather than having everybody distribute Fastlane on their own machine and running it because it's written in Ruby and I feel like Ruby is notoriously hard to get uniformly installed on everybody's machine. We've had a lot of pain points with it, so I feel like it's just one of those things that's just if you have the environment in CICD to do it, just run Fast Lane on CICD.

Łukasz Chludziński:

Yeah, yeah, yeah. I remember when I was writing some plugins for that. You have to have this gems and at BV version manager for Ruby as well.

Quin Jung:

Yeah, I think it's

Łukasz Chludziński:

R-B-N-R-V-M.

Mazen Chami:

Yeah, something like that. Something like that. RBNV or something like that. Yeah.

Łukasz Chludziński:

Okay. Yeah, so for building is also, not that I want to say not that needed from the service because you can build locally and you can update locally, you can just create builds locally and just distribute. But distributing is a bigger thing. I think distributing is such a crucial part of the whole product lifecycle workflow, like distributing internally to developers is distributing locally to your own QA and then distributing to better testers and then to production. There are a bunch of different steps and I didn't use distribute from App center as well. So yeah, maybe I will give Voice to Queen again to explain us how this system can work. Why is distributing such an important part.

Quin Jung:

Yeah, okay. When we say app distribution in the context that you say, I take it to mean how do we get our apps to people outside of Google Play before you submit it to testra? How do I get it to people outside of the app store before I submit it to TestFlight? And so we usually call that internal distribution and under the hood whatever product you're using, it could be app center, it could be us, but for Android it's fairly straightforward to do that, but for iOS there's a lot of code signing that goes on behind the scenes. So in terms of that, what you need to do is you have to register people's devices and you have to put it on something called an ad hoc profile. And what a lot of these services will do is that once they've built your app with that credential, they'll expose the QR code and it'll basically, it's really weird. It's called the iTunes Music Store Protocol. So into HTP or HTT PS, it's this IT MS protocol, but basically you scan that QR code on your phone and it will download that app outside of the app store or test flight.

Quin Jung:

We do have tooling to for many years now actually to make that very seamless, to register your device and to build those credentials and to expose that QR code. We do have that in their command line tools and I suspect that's probably how App Center did it as well. Their app distribution or anybody that uses that QR code, it's that mechanism.

Łukasz Chludziński:

Well, I don't know about the app center. Like I said, I haven't used this feature, but we've been using Firebase extensively, like Firebase distribution and yeah, this is basically the same thing. You have to register devices, you have to accept invite, maybe you even have to go through setting to accept some profile or something.

Mazen Chami:

Two things you have to accept the profile management that Firebase, so Firebase specifically what they gave you. You also need to make sure developer mode is on. I believe that was as of a more recent iOS version. I don't remember what version that was, but it was more recent in that sense. So those are the two things. Oh, and you provide your UDID if you were doing it the manual way rather than ES way of scanning a QR

Łukasz Chludziński:

Code. So yeah, I would propose that an alternative is definitely yes, submit for distribution and something like Firebase. I wonder if, I don't think Firebase can do store uploads for you. You can do it via Fast Lane obviously, but I'm not sure if you can do it via Firebase. Probably not. Probably not. Probably not.

Mazen Chami:

Yeah, I don't think so.

Łukasz Chludziński:

Yeah. Anything else to add to distributing bundles?

Quin Jung:

And I guess there's automated submission to the store, which is I guess also app distribution, but it's not internal and I'm sure App Center also had automation for that, which we also do as well. So when I think about it, it's just internal app distribution and then there's the external one, which both workflows are all automated, but in my mind they're just different.

Łukasz Chludziński:

So I want to recap what we went through to this point. So first we talked about code, push and alternatives. There's only one, there are two standalone code push and then ES update. Then we talked about building and distributing, which are also services that EAS support. And now I want to go to something that very few people actually mentioned in the LinkedIn post and in Twitter, their ex post, which is testing also one of the service from App center and then diagnostic and analytics, which is again, one of the least popular. Let's start with testing. So are there any alternatives on the expo site for testing?

Quin Jung:

Yeah, so late last year we had the ability so that you could specify all your build steps in a yaml, and we've extended that to include tests, so support for maestro tests and if you want to run it with a simulator, it can be specified. If you're talking about real devices, like something like AWS device farm, we don't have that in the context of CICD, but we do have that in terms of a development build where we have easy ways to get it on your real device for testing.

Łukasz Chludziński:

I guess in the app center way of things, it's about those real devices is about those device farms, and I think that one of the services they propose as an alternative is browser stack, which has it in its name. You can run all of the tests on different devices, on different browsers and yeah, this is something that I've seen on my client's projects that we use browser stack extensively, but it's not like it's under one roof, right? It's not like we can do as an app centers way of doing things. You have just one admin panel and you do all of the things there for BrowserStack, you have to upload the bundle to them, run some scripts and then get the results to your pipelines. So I guess probably you could do something similar with Expo and with the pipelines that you run there as well, right?

Quin Jung:

Yeah, so we're actually releasing this very shortly, but it's something called workflows where it is the pipelines you describe where you can just run. We have these jobs that say for example, if you want to register your device automatically or do testing or build, you can specify them all in a YAML and then chain them together, have the build run, then the test run, and then chain it to automatically submit to the store. But just automatic jobs that can be customizable is something that we are releasing really soon.

Łukasz Chludziński:

Yeah, yeah. Okay, cool. Thank you. Thanks for giving us a peek behind the curtain there. Yeah, but I guess like I said, UP center was such a narrow tool and they're expanding to just integrate with those bigger tools and you do the same thing. You expand to be able to integrate with external services as well.

Mazen Chami:

I've been personally starting to see a lot of shift when it comes to testing in qa, doing a lot of manual as opposed to using tools like these device farms doing a lot of manual testing where a QA team will purchase. It gets expensive over time, right? Purchase like their top three to five for each platform. The devices that are being used and manually go through all those tests and stuff like Maestro could come valuable, installing the app and then running a maestro yamo file like you mentioned Quinn, the workflows concept, but that seems to be a lot more, seems to be growing more in popularity these days and we're starting to see that with some of our clients too.

Łukasz Chludziński:

I see it differently, actually, I don't agree with this. On our end, it's all about shifting left and all about automating as much as possible. We still have a lot of manual get me wrong, but we want to make sure, and those device farms, it's not like we want to run on hundreds of different device categories like the different devices, different models, but it's used to have that so that you can, oh, this will be a tangent. We have foldable devices now.

Mazen Chami:

Yeah, unfortunately,

Łukasz Chludziński:

Yes. And usually most often, more often than not, you don't have different UI for those from your product side, from your design, and then few percent of your user base will have those kind of devices for some products and then you get bugs on them. So something like BrowserStack comes really handy then.

Mazen Chami:

And I think going back on my point, I see the value with the manual testing for those specific devices, but like you mentioned, the smaller percentage of the foldable, the other devices, it's always great to push them onto a device farm, get those statistics from that decisions. But for the higher end ones that are being used, 50%, I don't know what that percentage is, a high number, you probably say 25% or more. If that device, you might want an additional manual QA test on there to validate the experience. There's a lot of stuff that automation cannot pick up on that is always valuable to have in someone's hand to validate the user experience on. And that's kind of where my point was coming out. A lot of the clients want that as they're focusing more on the user experience aspects of their app.

Łukasz Chludziński:

Yeah, yeah, I agree. I agree.

Quin Jung:

Yeah, and it sounds like you need both automated device farms to get those really edge case models that Akasha is talking about, but also sanity check to be like, does my app work in the most basic sense? And you don't really want someone to be testing that every single time,

Łukasz Chludziński:

But

Quin Jung:

Also the more advanced QA steps definitely need to be done by humans.

Łukasz Chludziński:

And this is a great segue to the last section that we want to talk about, which is diagnostic analytics, which is that last step, which is the step that you want to have some kind of instrumentation so that you know how your app behaves at the end user experience. What's the end user experience like? To lean on your point, I saw a big shift recently in our products, a big focus on observability, on instrumenting the code so that things that you can't even notice when you manually or automatically QAing the app just spring out in your user hands. So when someone is using the app for two, three hours, maybe you will have some memory leak or something like that. It's really hard to find just doing the basic testing or different devices, different user paths can lead to unexpected bug, which you will just not automate for it or create the scenarios for.

Łukasz Chludziński:

So it is a big topic for me right now personally because I do that in my project and yeah, you could do that with app center tooling and something that they point to as an alternative is Datadog, and I've been using Datadog for some time now and let me tell you this is, it's a huge machine. What you can do in this tool is mind blowing. You can integrate metrics from different points in your whole system, not only from your mobile app, but combine mobile and web and backend into one observability panel, which when I first got to doing this was mind blowing for me and I'm not sure how robust app centers solution was, but on grounds like that, in order to stay competitive, in order to bring a lot of value for clients, this cannot be your second job almost. It has to be your first priority and this is what things like Datadog or I think Databricks gives you those specific observability tooling gives you whatever your thoughts on this.

Mazen Chami:

Even Sentry, right? Sentry has

Łukasz Chludziński:

Dedicat,

Mazen Chami:

Yeah, century for example, dedicated React native team. Christophe Wald was on React Native radio with Robin I believe, and they basically went over that they have a whole dedicated team just for React native and that's their full focus. So that's also a great aspect of it.

Quin Jung:

I'd see the best integration with React native I've seen is actually Century. So we've worked with them actually for a couple of years, Christophe Wooldridge and yeah, the way that they've gone about setting it up for React native and they've got this system called debug IDs. It's really solid. So I'd say the two key things when I look at whether something is well integrated with React Natives is how are they uploading the source maps for when you build the bundle, but also something that's often overlooked is for over the air updates because you need that source map and a lot of times it's overlooked. But yeah, the Century team has done a really good job of integrating that and making that super painless. I'd say I've also had experience with Datadog, not for mobile, but I will say Ash, to your point, Datadog does some crazy metrics aggregation. You can see the histograms and everything. We use it for our servers. I can't really speak to it for mobile, but yeah, Datadog has some crazy instrumentations as well.

Łukasz Chludziński:

Yeah, I didn't mention Sentry because it's been a while since I worked with it. I just work with whatever is actually on my client's stack right now and this is on what's my client's stack right now. But yeah, I remember working with Sentry and it's great. It's one of the Go-to solutions specifically for React native. Yeah, there are a bunch of other toolings as well. My point is this has to be your business in order for it to be good and yeah. Okay. I guess we went over, did we forget something? I don't think so. No, I think we're good. I think we got it all. Yeah,

Łukasz Chludziński:

So for wrap up, we started this episode saying How scared should you be because Up Center is going to be that soon for some of the tools. You shouldn't be that scared for Code Push specifically, you would be able to use your existing integration with just standalone server or you can easily, I would say I looked at the docs easily migrate to expo updates for some of the things that you've actually spent time instrumenting your app for things like, yeah, let's say diagnostics, right? For things that have specific APIs. You don't need me saying this. You are probably already migrating to something else, to something more robust because if you have a lot of instrumentation, you have to rewrite some of it. What would you guys say for build and distribute for pipelines and all of those kind of workflows?

Quin Jung:

I'm a little bit biased as we're coming out with that, so I would definitely say us, but I will leave that to you guys.

Łukasz Chludziński:

No, I mean, I'm not saying what should people migrate to? I'm saying when should they start migrating how they should think about migration.

Quin Jung:

I'd say in general, I've done a couple migrations myself, the sooner the better because I feel like not everything is one-to-one, the closest one-to-one services I've seen is maybe GCS and S3, but I feel like everything else, there's always quirks of a different product that you don't really foresee, or if you're using a really niche case that isn't really supported in the other platform, you find that out when you migrate and if you do it too late, you might not have enough time, which is, yeah, especially with hard deadlines, it's a thing, so doing it early is better so you can find out the issues before.

Mazen Chami:

I totally agree with Quinn. I think if at this point you're not at least researching the alternatives out there and making your decision, and if you're an enterprise company, you probably need to be in contract negotiations with Sentry Datadog, all these other products that we've talked about, right? If you're not, at least at that stage right now, I think you're a little bit behind because last thing you need is Microsoft to press that shutdown button and all of a sudden everything is broken and you can't push anything to your stores. You can't access your analytics, your devices, your testing devices. So start researching at least and hopefully come January 1st, PR is up for starting to migrate a weight at all this stuff. We mentioned a lot of good products out there that I shouldn't be new to most people in the React native ecosystem.

Łukasz Chludziński:

And Martin, you know what, if someone is already behind, they can look at Infinite Red or Call Stack.

Mazen Chami:

Absolutely.

Łukasz Chludziński:

Both of these companies are really well-versed in helping you out, so reach out to us and yeah, we can help you out migrate from up center to whatever tooling is best for you.

Mazen Chami:

Exactly.

Łukasz Chludziński:

Expo will probably be best for most of the products, but there are edge cases there that we can help you navigate.

Mazen Chami:

This would not be the first migration we've had to do for both companies, so you're absolutely right there.

Łukasz Chludziński:

Yeah. Matson, I think our crossover episode is ending right now. I want to thank you so much for doing this with me. Thank you for having me, for being a guest.

Quin Jung:

Thanks for having me.

Łukasz Chludziński:

And yeah, see you soon on both feeds, react Native Radio and React Universe owner.

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.