Deploying React Native Apps in the Cloud

Please welcome Praeten. Praeten. Let's get started. Welcome, Praeten.

Just to get started, a little bit about me. I'm a developer advocate for AppFlow. AppFlow is a platform for building cross-platform applications similar to React Native. But AppFlow works with all types of apps. So you can build Ionic apps, React Native apps, Swift apps, Kotlin apps. So it's really built for any type of development. But it works really well with cross-platforms specifically, which is why we're going to be talking about React Native apps today. You can feel free to connect with me on Twitter and GitHub. My username is at Cecilia Creates. You can also feel free to email me, Cecilia at ionic.io.

My background is actually in web development. I was a web developer, I also previously worked at Cypress, which is a testing framework and RePlay, which is a debugging tool. Both are open source dev tools just like Ionic. So I really have a passion for open source dev tools and working with those, and working with developers. So as we go along, if you end up with any testing or debugging questions, I can probably help with those as well.

So, yeah, that will leave me. Like I said, we can keep things casual today as we go through the agenda. So the first thing that we're going to do is we're going to make sure that we're all set up with the apps that we need to build. So we'll talk about the setup and the prerequisites that we'll need. As I go through the prerequisites, if you don't have all the accounts, that's okay. You can still get something from this presentation, and we'll also be sharing the slides and all the resources that you can take those with you and work on your own apps if you don't have everything that you need today.

Then we're going to get started with debug builds. So debug builds are kind of quick and easy ways to quickly build your app for debugging purposes. After that, we'll probably take a little bit of a break, and we'll see how we're doing on time. And then we'll go into native cloud builds. So that's how you can build your application for iOS and Android natively, using the cloud service Outflow. And then we'll also walk through an app store deployment. So we're going to be deploying to... We have a couple of options. I have Google Play internal test tracks, and we also have iOS test flight. So depending on what you prefer, I'm probably going to go with test flight, because most people prefer to do iOS. So we'll get started with that, and I'll share the instructions for the other platform as well.

So yeah, so let's get started with our setup. So ideally, you already have a git repo of a react native app with no existing CICD infrastructure. If you do not, I'm going to go ahead and share a repo in the chat that you can fork. And this is just an initial react-native-vanilla react-native-cli kind of app. That initial commit, I just made sure that automatic signing was enabled in Xcode and, you know, kind of, like, made a little bit of change to, like, the text in the background. So it's a really, you know, very out-of-the-box basic app that—if you need one to use. And so you can go ahead and fork this and use this for building. Later on, you will need to update the bundle identifiers, and we'll talk about that as we go through if you use this one. So I'll give a few minutes for people to get that set up, if they need to, if they need to fork, as I walk through the rest of the prerequisites. So you will also need Xcode and Android Studio. Now, you need these, if you want to actually go through the process of generating, like, your— well, yeah, your sign, certificate, and everything, to get to, like, the native build part. That's because you will need to use Xcode and Android Studio to generate the signing credentials, for the most part. You can get away with it. There's some other, like, paths that you can use to get your signing credentials.

But Xcode and Android Studio is the easiest way. So if you don't have those installed on your machine, let me know. I'm happy to share some instructions for how you can generate those credentials in a different way. We may just not cover that together.

And we'll also be creating an AppFlow account as part of the workshop today. It's a free account. It comes with native iOS and Android builds to get you started. And then we will also, if you would like to go through the process of connecting and actually deploying to the App stores, you do need an Apple developer account. If you want to create any kind of iOS build outside of simulator builds, an Apple developer account, there is a cost associated with it. It's like $99 per year. So again, I can demonstrate all of this functionality without you having to walk through it. And I'll share those resources. You may, for example, have a company account that you would use at work, but you don't want to use it today. And so that's something that I can just walk through and share the screen for. You'll also need an App Store Connect account. If you want to deploy to TestFlight, into the App store. Those are two separate accounts, Apple Developer Account and App Store Connect, but they are joined by the same App ID, Apple Store ID. And then you also, there's a Google Play Console account if you want to be able to deploy to Google Play for test track deployment.

We'll go ahead and then start get started with with debug build. So I want to talk about debug build. What I'm referring to is that there's specific build types, when you come and it comes to native applications. When you're building for the web, like you just have a build and maybe you have like a test build or a staging build, and then you have a production build. But you kind of decide that yourself as a developer when you're deploying your application. For mobile applications, there are very specific build types that you need to choose. And we talked about build types for Android, we have debug and release builds. Debug is essentially a quick build. It doesn't have to be fully configured that you can then share with like your testers, internal stakeholders. Release builds are required for deploying to Google Play. On the iOS side, when I'm talking about debug builds, I'm really referring to a simulator build. So a simulator build can run on a simulator, it does not need to be signed, which makes it easier to build to get right out of the gate within a build. You also have development builds which can be run on device, typically locally that one that's connected to your computer. And then you have ad hoc app store and enterprise builds, which are used for kind of distributing to other users. So I'm talking about the debug builds, I'm primarily referring to Android debug builds. But you can also think of simulator builds as a debug build.

The first thing that we'll do is make sure that we have our GitHub repo set up. Does anyone need more time to get a fork or a repo ready to go? Feel free to just raise your hand or pop in the chat if you need some more time.

Ok, cool. Alright, so we're going to go to this, I'll pop this in the chat. It's just, um, nxio.com. And we're going to go ahead and create an account. This will allow us to walk through the process of deploying our applications and creating Cloud data builds. So just click this, like, get started free button. Um, it's going to prompt you to create an account. Ah, it's a free account. Don't need to put in a credit card or anything like that, you can get started with free apps. So, I'll give a couple minutes here, you can either create an account with GitHub if you like, or you can create an account with an email and password. And then, uh, once you have created an account, um, you will, you'll end up at a dashboard. It kind of looks like this, um, I have a lot of apps in there already because I'm using my account, ah, but yours will, you'll be able to kind of see a sidebar here and you'll have some blocks, um, in the middle here, with, um, with a kind of like a welcome message. This is our AppFlow dashboard. The AppFlow dashboard essentially is where you're, uh, we'll import your apps and you can initiate builds.

You can initiate deployments to app stores. The first, next thing that we need to do is connect our app to AppFlow. So those, you'll see a new icon here, a little button drop down, and you're going to click import existing apps. Uh, you can give your app a name. So if you want to do like React Summit workshop, you'll select your mobile architecture. And so we're going to give this a name here, in this case, it's going to be React native. And then you'll select your apps, get host. So I'm already logged in and connected here. Um, but if not, you'll want to click connect in order to log into your GitHub account. Yep. And then, you know, as you get, once you get to the screen, you'll select the repository and that will automatically pull in your application. You'll know that it's successful because you'll be able to see your commits. So once everyone has is able to see their commits in app flow, well, um, we'll go ahead and move forward. Correct. Yes, that's a really good question. Leon, thank you for that. Yeah. Yeah. So you're just going to select the entire project because we're importing a react native project. Um, you were able to build cross-platform from the same repo. So again, uh, react summit workshop, redacted native. And the repo that I'm importing is this app flow RN vanilla, which is the corresponds to my get hub repo. And as you can see, it's the entire react native project that includes both the Android and the iOS sub folders. But Appflow was going to figure that out for us when we go to build. Okay. And then once you see some commits, um, feel free to thumbs up. I know that a few of you are just following along, but I'll give you a few more minutes here to, um, to get this set up. All right. All right. So that's, um, we're looking good here. I'll go ahead and move on. I'll go ahead and move on. So now that we have our app imported, I'm going to get a kind of a tour of this Appflow dashboard and talk through some of these concepts around. Like cloud native builds. So we have our commits that get pulled in from each of these commits, we could initiate a build. And when I'm referring to a build, I'm referring to iOS and Android builds. Right. And so typically when you're building cross platform, you have one code base and you may have different configurations, but ultimately you're deploying the same exact app, the same version to iOS and Android. So when we talk about initiating a build from a commit, we're taking the latest version of our code base. So in this case, like I updated my background style about an hour ago. And we're saying we want to build for either iOS or Android. So when we're talking about debug builds, that's going to, we're going to choose the build type. So this is the new build screen in app flow. We've selected a commit of our code base in order to initiate a build. From here, we can select either iOS or Android. I'm going to go ahead and start with an Android debug build. Here, we're going to select our build stack. And I just always leave this to latest. When I'm talking about a build stack, what I'm referring to is all the dependencies that need to be installed in the environment before we can proceed with the build. So if you've ever done this manually, I know, um, we know we're talking about doing this kind of in CI-CD.

You have to install your build stack, uh, making sure that you have the correct version of the Android SDK. Um, if you're building for iOS, making sure that you have the correct version of Xcode and Cocoapods installed in your environment. Um, you may also need to install a certain version of node. So all of this is managed in Aflo via the build stack and our team updates these per, um, frequently in order to ensure that we're up to date with the latest requirements for the app stores.

Uh, so for example, Android, if you are not using a high enough version of the Android SDK, then you can get delisted from app stores because there's that creates security risk. So we continually update the build stacks for you. Um, if you do need a specific version, like say, for example, your app is only compatible with an older version of node, then you can select an older version and see what's included in that build stack. Uh, but for the most part, I just use the latest build stack.

Uh, and then the next is you're going to choose your build type though. Uh, you can choose for Android, a debug or a release builds. We'll go ahead and select. Now I mentioned that you may have different configurations for your app for apps for iOS, Android or iOS. Uh, this is where you can use custom environments or ad hoc environments in order to apply certain key value pairs to the build itself. So say, for example, for your debug builds, uh, you wanted to change the bundle name because it's for a specific team, uh, you could pass through this environment variable at build time as an ad hoc environment in order to update that for this particular build. You could also create an environment that can be saved and then used over and over again. So if you have, for example, a test API, and then a production API end point, and you want to save those, you could have your test environment, you have like, you know, your API endpoint and your value. And you save that and you apply that for every test build. And then you have a prod environment with your environment variables, with your prod API endpoint, you save that, that can be stored within App Load and then applied to certain builds. So in this case, we're just going to do an Android debug build, nothing special. We're just going to go ahead and kick off that build.

So as that's running, I'm going to talk through a couple of different concepts here around this test devices. So I mentioned earlier about iOS simulator builds. So a simulator is a type of virtual test device. So for test devices, you have the option of virtual and real devices for virtual. So here on this slide, you have simulators for iOS and what's called emulators for Android. There's a couple of little differences between the two, but ultimately, they're both replicating a real device on your computer. So it pops up. You can kind of interact with it. We'll take a look at one here in a minute. These do come pre-installed with Xcode and Android Studio. So you don't need to configure them, but you don't necessarily need to install them separately. They can be used to run automated tests in CICD. So because they come pre-installed in Xcode and Android Studio, you could essentially launch them in your CICD environments. You could run a and you can run tests on them. Ultimately, though, as you'll see, what's different between web and mobile is that in the web world we have a lot of automated testing. You know, it's pretty much a given that you're going to have automated testing and you want to maybe have like a minimal amount of manual testing. In mobile development, that's kind of flipped on its head. You have a lot of manual testing, mostly on real devices. So device EUIDs, you do have to register for those for iOS to run your app on real devices. You can do that by connecting to Xcode or adding those devices in the Apple developer program. You don't have to worry about that for Android. And you also can use real devices to run automated tests in CICD by using what's called like a real device farm. So things like AWS device farms, Sauce Labs. You can upload your application to these device farms and then run an automated test on real devices in the cloud. So today we're going to be focusing on on both types of devices. I'm going to show kind of running an Android app on an actual device. But we'll also be taking a look at simulators as well. OK, so I'm going to go ahead and pull up actually here this build from a little bit earlier. So this is an iOS build and it is a simulator build. And what this is once the build has been completed in App Flow, we have our build log.

I can see the build ID that was used the platform. I can see the build ID that was used the platform. Yes, so you can. Good question, Jerry, thank you for that. So by default, the build stack includes those versions of NPM or Yarn, you can either choose a newer build stack if you don't see that version that you need, or you can also manipulate the install command to include installations of additional packages. So we will go ahead and run like the install command and then you can use that in order to install a different dependency in your environment.

So there's a default build stack, but if you do need to install a different package manager or a different version, you can also do that as part of the run itself. Yeah, great question. So going back to the build log here, you can see the build log. You can also see all the information about the build itself, like what build stack was used, what commit triggered it, who triggered it, you can rerun it if you run into any issues. And here you can also download the artifacts. So you can download the Xarchive and you can download the appfile. So anybody who has access to the account can come in and download the bundle itself. This is going to open up the zip file and I'm going to grab this here and you can hear how we have like my little app here. So I'm going to pull up my simulator now. So I'm opening up my simulator, which again comes pre-installed in Xcode and letting that start up. And so this is what I say when I'm talking about a simulator, it's essentially like a fake phone on your computer and you can interact with it the same way that you would like an iPhone 14 Pro, which I personally do not have. So it's kind of nice to be able to see one but at least you know in a simulated environment. And you can see I have kind of my little demo apps in here that I've been dragging over but I'm going to go ahead and drag over the app file and that's into the simulator and that's going to go ahead and install it once that's installed then I can go ahead and open it and boom I can see my app. So again this is like a very simple like boilerplate application just so as we can kind of build but that's how you can run on a simulator. You essentially just drag the apk I'm sorry you drag the app file over for Android it's apks and you're able to interact with it on the simulator. If I hadn't worked going on in this app I'd be able to click around and work with that.

Now let's take a look at our Android build here. So for our Android build again this is our debug build we're going to have our aab and our apk. These are the artifacts associated with an Android build. In app flow you'll see you have this kind of like QR code that pops up. So if you wanted to run this on a real device you can actually scan that QR code with an Android device and open it up on your phone. So I'm going to go ahead and do that now. Sometimes I run into issues because I have a curved screen so my phone doesn't love the QR code on it. Yeah let me try. I'm just going to move this to my other window where I have a flat screen. And I'm going to go ahead and click on the QR code that pops up. The URL what that does is it essentially just takes me to a an AWS like an S3 bucket where the APK is installed. It's going to ask like do you want to download. Hopefully you can see that. Let me just check my camera. Yes okay. So it's going to say like do you want to download? Yes or no? So you're going to go ahead and download that. Then you can open it. It's going to ask you you know to bypass the security feature. So if you're obviously only do this with like apps that you're that you know the code base for. And then that's going to go ahead and pull it up on the Android device and you can see and interact with your app on an actual device as well. So we'll go ahead and here we can see our Android debug build is complete. So I can actually do this again with our newest version. So I don't know if you can tell but this old version has kind of a weird styling thing in the background there's like a strange line here. So that's the older version that I had. I'm going to go ahead and update to the newest version by again scanning the QR code on my flat screen. I thought a curved screen looks cool when I got it but it's giving me issues. And then again it'll just take a couple seconds in order to download and install that file and I'll be able to see the updated version. Yep so yep we'll go ahead yes please, download, open, update.

So it'll update the app to the newest version. I'll open it and there we go I have my newest version of my app here on my phone. So it makes it easy for you to be able to you know interact with your app on a real device as well as in a virtual environment.

So yeah so is anybody able to kind of kick off an android build and go through that an android debug build and go through that process so far? If you have any questions or issues just let me know.

Okay yeah so I see some questions. Yeah so the types of machines that are being used it so we just that depends on the build stack here so we don't have like the newest m1 machines I will say that we're using get lab runners but yeah it is a an intel processor and you can see all of our build stacks in our docs so this is where we'll have like this certain stack version and what versions of mac os and everything that are being used.

Default over wifi or internet? Yeah so yeah so the first time it's very slow. I I agree, that's just because if we don't have caching until the second time we go through. So it has to install all the dependencies the first time and then as you have subsequent builds it should be faster because everything has been as is kind of being cached in the same way.

Oh yeah, awesome. So it's running on the android emulator, you may still see some weird style stuff going on. I thought I had fixed that but I didn't. So and then yeah so it may still be running for you because it is the first time that you're running this. I just thinking to look at Leon's question here, can you also debug over Wi-Fi the internet my usbc port is kind of broken so it randomly disconnects if I move it slightly. Yeah so when you scan the qr code exactly you don't have to worry about your phone being connected to your actual machine. That's something that I run into with my iPhone for example, if it's not trusted it may disconnect or I have to like give it permission if I connect it to the actual machine. So when once you actually have the apk it can be deployed to like if you needed to share it with somebody anybody can download that file and then once you have installed it on the machine you no longer need to be connected. So you can install it on your phone or you can also like send it to somebody and then they can download it on their phone and then once it's installed in the phone then you don't necessarily need to have your device connected anymore which is different than when it's connected to Android studio. So it's because when you're running it in Android studio, you have like a live debug build taking place it's almost like with React Native. How you have to start the server and you're running against the dev server like in web right. Once you have compiled that debug build though and you've installed it on the phone then you're no longer connected to anything. It's not like a dev version it's actually the compiled native binary. So you don't have to be online you don't have to be connected to your dev machine you can send it to anybody else and they can install it and run it. So that's kind of the flexibility of using a cloud build and not using a local dev build all right.

So we talked about test devices, we talked about the build types as well. So just a couple of notes on as we kind of go into the next section. I know some people's builds are probably still running. I would not recommend starting an iOS simulator build because that will take a long time and use up quite a bit of credits. So if you've done that please cancel it. Just just do it that way we can kind of keep things moving here. And so the next thing that we're going to talk about, I do want to make sure we get a chance to take a quick break before we get into that, but is going to be code signing. So I'm actually going to bring up a different screen here. We talk about code signing. So this is a some slide that I will share as well about shipping React Native apps. So code signing is required for all types of Android, yeah, for all types of iOS builds, except for simulator builds. And it's also required for Android release builds. I know Leon has mentioned code signing before. Has anybody else had to go through this process? Feel free to thumbs up in the chat or raise your hand, React. Have you ever had to deal with code signing an app before.

Okay, cool. So this is probably new for a lot of you then. So code signing essentially means that you are generating a signed bundle of your application. So that debug build process we just went through, we didn't have any signing credentials. You did it based off my code. We didn't need to like connect any type of account to our Android studio. It was just a build. When you generate a signed bundle, what you're saying is that you're authorizing who is the person that has created that bundle, you're stating that you are authorized to do so. And by signing the bundle it's certifying that the bundle has not been modified from the time that it was created to the time that it's been deployed. So it's a requirement from Android and iOS for security reasons. It's ensuring that you are the one who is allowed to create this app and no third parties have interfered with it or done anything malicious with it.

So the code sign-in process requires credentials because of this because you need to be able to say, yes, I am who I am. I am authorized to create this build. On the Android side, the credential that you'll use is called an upload key. It is stored inside of what's called a key store file, but that is generated in Android Studio. You can also generate it in KeyTool. It's like a CLI tool in order to generate credentials, but I think Android Studio is easier so that's what I'll be showing.

So for Android, you just need the one upload key in order to generate your signed bundle. So that kind of signed version of what we just did. On the iOS side, you'll need two credentials. You need a signing certificate. A signing certificate validates your identity and that you're authorized to create the signed bundle. A provisioning profile is kind of a collection of all of the information that you need to generate the signed bundle. So it includes which signing certificate is being used. It includes which devices the application can run on. It includes the app ID and it also includes a name and to generate the signing of the signed bundle. So for iOS, you need both credentials in order to generate a signed bundle and they need to be inside your environment when you build your application.

So if you're building locally, in Android Studio, you can generate a APK, and Android will walk you through the process of doing this and you can do that on your machine. But if you want to do this in the cloud or share this across teams or you don't want one to run your build, that's where it's more important to know what's happening under the hood with that key. I know we talked about EIS before, but I think in EIS it's a generate credentials, like a command that you can run. It creates the key for you and stores it in its servers. So this is what's happening under the hood, it's actually creating this key store file. We'll also talk about I'm going to skip through this here.

So for iOS, there's something called automatic signing that you enable in Xcode. You want to make sure this is enabled. What this does is it allows Xcode to manage your signing assets for you. So you'll need to connect your Apple Developer account to Xcode, and then it'll create your signing certificates and devices that you connect in Xcode, and it creates your app IDs, manages your provisioning profiles. You'll actually keep this checked even though we're going to be using app flow because that's what allows app flow in order to manage the signing credentials for you. But again, we're going to walk through the process of generating your signing certificate and your provisioning profile so that it can be in the environment within Apple that needs to be in order to create your builds.

Okay. So to show you what that looks like in app flow, I'm going to actually put to a different app here. And I'm going to show you what it looks like once it's been completed, and then we'll walk through the process together. So this is another kind of just like React Native app that I have in app flow. And under build signing certificates, here is where I have uploaded my signing credentials to use for my cloud builds. I have a development credential. And then I have my production credential. So I mentioned that for iOS, there's a development build that you can do in order to kind of run on a device in dev development mode. So I've uploaded my certificate and my provisioning profile files here, and now Apple has access to them to apply automatically whenever I create a build. The same thing for my release, I have my distribution profile, and my certificate, as well on the Android side I have my keystore file. That means when I go to create release builds, production builds, like this one, I can't, in order to deploy to the App Store, those are going to be stored in App Flow, I don't have to worry about manually installing them in my environment. Because if you do want to manually install in your environment, this is kind of what that process looks like.

This is an example of a GitHub action for an Android debug build. I'm configuring my build stack at this step. I'm installing my dependencies. Here I'm bundling my app and then I'm running the debug build command using Gradle. And then I'm uploading my build artifact. So, this is kind of replicating what we just did in App Flow but in GitHub Actions. If you want to do a sign bundle, you do have to update the signing config in your build.gradle file in order to instead grab environment variables that are stored in GitHub Actions and get using secrets. You also need to debug or decode the key store file in order to install it in the environment. You have to do the same thing for iOS.

You have to do the same thing for iOS. So, these are the docs from GitHub Actions for installing your certificate on Mac OS runners. So, as you can see, you have to store the build certificate and the provisioning profile as a base64 encoded file. Then you need to create temporary paths to store those files. You import them from your certificate. I'm sorry, from your secrets. Then you need to install them in those temporary paths and then make sure that they're applied to the correct paths in order to ensure those are in environment. So, by uploading into Appflow, we're abstracting this part away.

Yeah, so I'll be sharing the slides. In fact, I can even pop them in the chat right now. So, the slides that I'm showing you here, it's the Shipping React Native slides that are on the Resources page. So, I can go ahead and share these slides with you. Let's see, View Only Link, copy. So, I'll pop that in the chat right now, so if you want to follow along. And then again, this Shipping React Native app slides, that will link out to the more detailed slides here, as well. All right. So, let's go ahead, and now we're going to go through the process of generating our signing keys. Does anyone want to take a break before we do that or still ready to keep going forward? Maybe thumbs up if you're okay to keep going forward. Everyone looking good? Okay. Cool. All right. So, like I said, I think the easiest way to generate your upload key for Android is in Android Studio. So, we'll go ahead and open up Android Studio. And we're going to let that open. And I'm going to go ahead and open the project here. So, again, you can use key tool, which is a CLI command tool. But I think that's a little bit more complex. You have to kind of use the RSA commands. Just to show you what that looks like. It is going to be in the slides here. Let's see. Yeah. So, if you are using key tool, it's going to be oh, I don't have the slides for key tool. I'll share those later. I'll make sure to share those out. Let me pull that up here, actually. I can actually cover that in my talk. So, if you're using key tool, this is what that looks like. It's a CLI command that you run and you pass through some commands. So, I'll make sure to share those out as well. But for Android Studio, we're going to go ahead and open that up here. We have our project open. So, you should have been able to select that. Now, mine was in the recent. Now, if yours wasn't. If you can't see it, you can just click open and then go to where it's stored. And in that case, you're actually going to select the Android part of it. So, see how my path is React Native tests slash Android. So, when you go to open it in Android Studio, you are going to go ahead and select the Android and it'll kind of have that here.

So, when you go to open it in Android Studio, you are going to go ahead and select the Android and it'll kind of have that here. So, Android and that's what you open. I'm going to go ahead and just open it from my commitment here. Any questions getting that open in Android Studio?

Okay. What we'll do then is we're going to go to build and we're going to generate sign bundles and we're going to pick which one of you is that? Let's see.. Android SDK Java. Okay, yes, so is it saying that it can't find your like Japan Home or your Android SDK version because that's something that comes up and you haven't, yeah, okay. All right. And it happens if you haven't configured your local environment, you have to set that variable in your batch. But okay, it's it. Yeah. So if you know how to fix that, we'll go ahead and move forward. But yeah, so we'll go into build and then generate Sign Bundle APK. And again, this is going to be like kind of the side we looked at earlier. So Android app bundle, this is the default now going forward for app store builds. And then we're going to click next. And then here where it says keystore path, this is how you're going to generate your keystore file. So you're going to click Create new. And you're going to select your path. I like to keep a keystores file. And then I'm going to just store that in here for now and click Save.

Oh. Keystores. And save as. We're going to call this app flow React Native Vanilla, just to match up with that here. And save that. And so that's going to save it to the path that you saved it to, your keystore. You're going to need to set a password and confirm your keystore password. And you're going to want to make sure that you note this somewhere. Save it one password if you're just doing it at the workshop, write it down. But you'll set a password. I'm going to write it down, because I'll immediately forget it. I have no short term memory whatsoever. And then you'll also set an alias. So I'm going to do App Flow or App Native Manila. And then you also set a key password as well. It can be the same. You'll set the validity, which is essentially like an expiration date for the keystore. And then here's where you're filling out your certificate information. Remember, the keystore and the purpose of the key is to say, I am who I am. And this is who is creating the signbundle. So you have to do your interior information here. Oh, yeah. So, developer relations. Ionic. I'm in Atlanta. I'm in Georgia. And I have U.S. to my country code. So, once you've selected all this information, again, make sure to note your alias, your keystore password and your key password.

They can be the same. You'll go ahead and save that. Then I'm gonna go ahead and click next. Ah, okay. I apologize. I messed up. Let's go back. So, under the keystore path, I forgot to put the file extension. I apologize. This is my fault. I haven't done this in a minute. Okay. So, we need to set an extension of.keystore or.jks. We'll go ahead and do this. This time it's AppFlow Reactor Vanilla.keystore. Next. Okay. So, create new. It's a super case AppFlow Vanilla.jks. Okay. There we go. So, I apologize for that confusion. So, it's going to be—based on the name of your key store,.jks, which is the key store file type. You can also do.keystore, but.jks is kind of the default one. And so, again, you're going to do your passwords, your p-alias, and then your certificate information. Okay, so now when I go to my Kiestorz. You can also go through this using terminal, but my AppFlow vanilla jks file is here. Okay, so I'll give you a few minutes. Let me know if you have any questions. I apologize for that confusion there. All right, so I also did add these code signing React native app slides. So that goes into more detail on how to generate via the Keytool command. So if you wanted to get into more details into how to use Keytool instead of Android Studio, that has all of the commands that you'll need as well. So, alright, so once you have your jks file, looks like we have some thumbs up. Awesome, thank you everyone. We're going to go ahead and go into build and then signing certificates. So, I'm going to do this along with you here. We'll click add certificate. And I'm going to go ahead and name this release. And I'm going to select Android. So I'm gonna go ahead and browse for my key store file, which should be, yeah, recent places, key stores and my app flow react native vanilla jks, then it's going to ask me for my key store password. So my key alias, which is this and my key password. And then we'll add our certificate. And so now we have our key store, stored right in app flow, and we have access to it now to create release fields. That's correct. Yes, exactly. So no matter what provider that you're using, even if you're using GitHub actions, right, so I kind of showed that GitHub actions example earlier. That GitHub actions example had nothing to do with app flow. Like if you're building it yourself, you need to generate that key store file in order to make sure that it's in your environment. The only time that even and, as you could see, you still have to do that even when you're building an Android studio.

So even locally, you still need to generate the app flow itself. So even locally, you still need to generate the key store file. The reason we kind of created it and we bailed out because we're not going to build it locally or building it in the cloud. But the same thing, if you check out the bitrise docs or CircleCI docs, it's going to ask you for the key store file, the passwords and the alias. Great question. And that's, unfortunately, but that's why you do need to have Android Studio and Xcode on your machine to generate. So for Xcode, for iOS, you can generate credentials within Apple Developer Program, which is what we'll talk about here in a second. But even then, you need to add a certificate request file, which is what allows you to interface with the Apple Developer Program. All right. So, is everyone able to get that updated into Android? I'm sorry, into AppFlow? Okay, awesome. Let's talk iOS. So, as I mentioned, for iOS, you're going to need both a signing certificate and a provisioning profile. So, you will need to be set up within your Apple Developer Program in order to generate the Provisioning Profile. So, this is the Apple Developer Program. It's developer.apple.com. I'm using our organization one here today. So, I'll go ahead and walk through. I kind of figure you may not have your own account, but I'll show you what the process looks like. Also, these slides that I'm sharing out, for the Shipping React Native apps, has screenshots for how to generate all of this as well. First thing we're going to need to generate is a sign in certificate. I think this is easiest to do in Xcode. Again, there is a more detailed process that you can go through, which is in that code signing app slides, if you wanted to use the manual process, using a certificate request. But we're going to make our lives easy for ourselves and go ahead and use Xcode. First I'm going to quit Android Studio just to save my computer from having to run everything at once. I'm going to go ahead and open up Xcode. Come on, you got this. Got a lot running right now. Okay, here we go. Okay. Opening back up Xcode, Apple React Native Vanilla. Again, as you can see, I'm in the iOS folder. We're going to open that up. All right. So I was just in here, so it's already open. Just so you can see how I got here. Whenever you click on the application here on the side, it's going to initially open up the project explorer. You may be set to general here. By the way, this is where you also update the display name and your bundle identifier. So this is where you'd update the bundle identifier for your iOS app. It does have to be unique for you to be able to deploy it for Android and iOS to the app stores. You try and upload for... And it's not unique, it's going to give you trouble. That's where you update that. But under signing and capabilities, here is where you'll see the automatically managed signing. It should be checked. And then you also should select your team. So the team does have to be selected in order to generate signing credentials. So initially once that's set up and you don't have to worry about it again, but just like automatically managed signing, you'll select your team and you just make sure that your bundle identifier has been updated to something that's unique. So that's the process of kind of just initial configuration. Let's talk about how you actually generate the credentials in order to get them into your cloud environment.

Because again, once I'm doing this locally, everything kind of happens in Xcode. But no matter what provider I'm using, if I want to build in the cloud, I'm going to need these credentials. So we're actually going to go to Xcode and then settings. And then we're going to click on this account tab, it may just bring it up automatically. But here's where you're going to see your Apple IDs that are connected as well as any like source control accounts if you're connected to GitHub, for example.

So the Apple ID that I'm using is my ionic ID. And I can see my teams here. I have personal team, and then I have my organization team. And there's a manage certificates button here. So the master tickets is how I can create new signing certificates. So I click on this little drop down here. And because this is my personal team, I can only create a development certificate. So if I have a manage team here, this is where I can see my existing certificates and also create a new development or distribution certificates. So a note on the difference, a development certificate is going to be for development builds. That's if you're doing a development build to be able to go locally to be able to just put it like on a couple of devices. A distribution bill certificate is what's required in order to build for app stores. So if you're doing, you know, app store bill, that's what you're going to need the distribution certificate type. I'm not going to make any new ones because I already have some on here. But once you do create that, you can right click and select export certificate and that will allow you to save it as a name and then give it a password. You want the password and again, you need to make sure that you note it down somewhere. So you'll save it as a name and then you'll give it a password. Once you do that, then I'll go to my key stores. I never saved recent here. Okay. And so here is where you'll see the certificate, it's going to be a P-12 file. So I have my Development Certificate and I have my Distribution Certificate and those are both P-12 files that get exported. So again, if it's easier for you to see it this way as well, you're saving it as your Distribution's certificate name and you're giving it a secure password. If anybody has any questions or is anybody able, not able to generate that science certificate, just give me a thumbs up whenever y'all are ready to move on.

Okay, awesome. And just to confirm, are any of you actually walking to walk through the next process in the Apple Developer program? If not, I'll kind of go through it pretty quick.

Okay, yeah, so I'll just run through that pretty quickly. So in fact, I'll probably just do it here. So this is the Apple Developer program. Here's where you can see, I gotta log in. It logged me out. Okay, so you know what I'm just gonna do this using the slides, rather than going through the process of logging it again. So Apple Developer program here is where you have all your certificates, identifiers, devices, profiles, keys, services. As you notice, I had my team connected in Xcode. So everything is being synced up as I go through.

So what I do is under profiles, I'm gonna hit this little plus icon, and that's gonna walk me through the process of creating a new provisioning profile. First thing that you're gonna do is select the type. Again, if you're doing a development, it's going to be iOS app development here. If you're going distribution, it's going to be App Store. Then you're gonna select your App ID. So the App ID is registered within Apple Developer Program as well. Chances are you only have like one or two App IDs. We have a time because we use it for all of our apps that we're pushing and testing. But you select your App ID. You have 183 App IDs, that is probably not the case for you. Then you're going to select the Certificates associated with your app ID. Then you're going to select the Certificates associated with this provisioning profile. So if you're doing a development provisioning profile, you can have multiple signing certificates associated with it. But if you're doing a distribution provisioning profile, you're going to select one distribution certificate that's associated with your signing team. Then you're going to select any devices. Now this is only required if you're doing development or ad hoc releases. Development and ad hoc releases require you to have specific UUIDs registered. For App Store distribution releases, you're not going to have to go through this step. Finally, you're going to review, and you're going to save it. And then once that has been saved, it's going to be a.mobile-provision file. So again, going into my Key Stores, I can see here, I've gone through this process before, and I have, for my ReactiveNativeTest app for example, I have a mobile-provision file that gets generated. And so, oh, actually, I'm sorry. That's not saved in my Key Store. I saved it somewhere else because I downloaded it from ADP. But anyway, once I've generated that, that's what gets uploaded into App Glow. So again, just to kind of walk you through what's already been done. Since a lot of you probably aren't doing this yourself during this part, this is the certificate, the P12 file that's been uploaded, and it'll automatically pull in this information. But it is going to ask you for that password. So, the password that you created when you exported your application, you're going to want to put that here, and that's why it's important to note it somewhere safe. Same thing with your provisioning profile, it's going to be this.mobile provision file, and see how it kind of pulls your bundle ID? That's why you need to have a unique bundle identifier. So this is like your team ID and it's the bundle identifier that's set in Xcode. So it does need to be unique and it needs to be set in order for you to be able to do that build. So, once we have that then we're able to do apps store builds, are able to do release builds for Android, and get that set up. A couple of things that I wanted to note just kind of in this process here is I talked a little bit about app versioning, but I want to dig into this a little bit more. So, I showed you in Xcode already, where to update that build string in Xcode. You also need to make sure that each new build that you're doing, you update the version number. There's an easy way to do this in App Flow actually, using a tool called Trapeze, which will auto-match whatever your build ID is to your version number, so that you always have a new version and it's always tied to your build and App Flow. On the Android side, there's actually a couple of different places that you need to update it, there's multiple files. If you're using Expo, you can pass this through to your app.json, and you can just set the package name for Android and the bundle name for iOS, and it'll update it into your native files because you don't have access to your native files.

For vanilla apps, you know, you're going to want to update the application ID, and you also need to set your SDK versions. So these are the minimum target and maximum versions of Android Studio that correspond to your build. I just wanted to make sure that I note that and keep that in mind, because if you don't update that, again, it needs to be unique, it needs to be updated in multiple spots within React Native Apps. And then we talked about code signing and now we're ready to talk about App Store deployments.

Alright. And so to such, I don't believe any, some of y'all have worked on using an App Store's apps that have been deployed to Apps Store but haven't actually owned that process yourself. So I'm going to go through a couple of notes here, just talking about what this process looks like. So when we talk about updating, uploading to App Stores, you don't actually just like upload and then push it to the store immediately. Like it does, that really doesn't happen. As I mentioned, there's a manual, a lot of manual testing that takes place before you get to that point. So for Google Play, you know, you do have to have a Google Play console account. It's like $25 to get set up. And it's a one-time fee. For Apple, you have Apps Store Connect, which is a different URL than an Apple developer program, but they're kind of tied to your Apple ID. And then you're going to be uploading to primarily with, or it's like, initially it was called Test Tracks. So for Test Tracks, on the Android side, within Google Play, you have three test tracks. You have internal testing, which allows you to upload the app and share it with up to 100 people. So this is good for your QA teams, internal stakeholders, it allows you to deploy, and you set those people in advance by email address. After that, you have alpha or closed testing, which allows you to share with a wider group. Your app has to be configured and ready at this point for internal testing. It doesn't have to be fully configured yet. And then finally, you have, what's called beta, or open testing. At this point, your app is in the app store, so it should be fully ready for users. But it's marked beta so it's with the understanding that it's still in that testing phase. On the iOS side, you have what are called ad hoc builds. I may have mentioned this before in the build types. But this allows you to distribute to up to 100 test devices per year. So, not user based, but device based. And you do have to register those EU IDs. So, what may be a better option is using TestFlight. So, TestFlight is built in to App Store Connect. It allows you, again, to kind of create a list of email addresses that you can share out. People download an app called TestFlight onto their phone. And then from within TestFlight, they're able to access that kind of those beta versions of those test builds of your app. You can also use a link, like a, you know, like a sent link to share those out as well. The nice thing about TestFlight is that there's built-in tools in order to provide feedback from your testers so they can submit screenshots, bug reports, et cetera. So on the iOS side, typically you're gonna be using TestFlight over Ad Hoc builds. So we're gonna walk through the process of setting up. So for, we'll start with Google with Android. So when starting with the Google Play Console, you're gonna have kind of all your apps, we have apps existing, you probably won't, but you're gonna go through the process of creating an app. You're gonna give it an app name. So, you know, React Summit workshop. This is how your app will appear on Google Play. You're gonna create like your app. You select if it's an app or a game, if it's free or paid, and you have to kind of do some declarations here. And then you're gonna go ahead and create your app. Once you do that, it's going to give you a really, really big list of questions that you have to fill out. It takes a long time, it's very complex. I can actually show you what this looks like in maybe an existing, another one here. So for example, this is the questionnaire.

So there's 11 sections that you need to complete regarding what kind of access the app is gonna request your data. If you have ads, your target audience, whether it's intended for children or not. You have to go through all these questions before you can start internal testing. Once you've completed that, then your app is ready for internal testing, and you can go ahead and create your internal testing track. So I have that here under internal testing, and here I can see my testers. So up to a hundred testers can join internal tests, and this is done using lists. So you create an email list and you add people, you can also upload a CSV file. I have a very, very exclusive list called Facilia, and it's just me, I'm the only one who can test my apps. But, once you have created the testers list and you deploy releases here, you'll be able to see that like right now, the version 1.0 is available to testers and you can see what the version code is, you can see what Android devices it's supported on based on the target SDK and anything that's in the app. And then, if you wanted to, you could also promote the release to either closed testing, open testing, which is that beta testing I was referring to or production. So, this is this place where you do your initial round of testing, then you'll move on to open testing or to close testing and then open testing. And then finally, it's actually ready to be released on the Google Play store. Any questions on Google Play testing tracks or releases?

So, quick note about App Store Connect then. So, actually, the next thing I wanna talk about is quickly before I do this, is how you go ahead and get your destination set up in App Flow. So, under deploy, we have destinations. And this is where you connect your Google Play and your Test Flight.

So, when you select it, you're going to be connecting it based using what's called a JSON key file for Android. So, you give it a name, it's gonna be Google Play, here's where you select the track type. So, here's where you're select whether you're deploying to your internal, alpha, beta or production. So, I have it set to internal by default, but you could have one for each and then you could deploy them individually or you can promote that release right in Google Play.

Thanks, Leon. Thanks for being here. Here's also where you'll list your package name, your publishing format, and then you'll upload your JSON key file. Your JSON key file is created under your Google ID. And so, what that part looks like, just because I've already done this process before, so, I don't wanna create a new one. But, your JSON key file is created under Google Play Console and then your API access. You're gonna essentially create a service account. And that's going to allow you to export a JSON key file. This JSON key file, that allows you to then be able, for us to be able to interact with your Google Play account. And that's how we actually deploy to Google Play on your behalf.

So, on the Apple App Store side, it's a little bit different. We're not using the JSON key file. Instead, you're setting your Apple ID, an app specific password, your App ID, and then a Team ID. And again, what that looks like in the dashboard itself. Here we have our Apple ID, an app specific password, our App ID, and then our Team ID. In order to create an app specific password, you'll sign in to Apple ID. It is Apple ID.apple.com. You'll sign in. I'm just gonna sign in quickly off screen. And then I can show you what that part looks like. Logs you out so quickly, I was just logged in. Security. Two-Factor Authentication. Okay, so, once you are logged in, this app-specific passwords, this is where you'll generate an app-specific password. That is then gonna be passed through here under your app-specific password. Your Apple ID is just like your email address for your Apple ID. Your app ID comes from App Store Connect. So, that is going to be in App Store Connect under your app itself. Got to log in again. Give me one second here. All right, so in App Store Connect, under your app information, this is where you're gonna see your Apple app ID, so that's what you're going to set there. So, we have our Apple ID, our app-specific password, our app ID, and then our team ID, which is available in your Apple Developer account under Membership Details. And the nice thing is too is like all of these are links here, so when you go to add the destination, you can click on this and it'll take you right to your Member Details and it'll give you that team ID once you're logged in. So once those have been added, then we can start our deployments to our App Stores. What we can do is we can take any of our release builds. So here, for example, is a Android release build. And once we've completed that, we can go ahead and deploy this binary. We select our Google Play internal and we can go ahead and click Deploy. That is going to kick off an upload to Google Play Internal. We can also do this all automatically, like from a single flow, just kind of walking through each individual step. Once that's completed, what that looks like in Google Play is, again, if I go here to my React Native app, it's going to upload that newest version under my internal testing. And then under my test flight, the same thing will happen.

And then under my test flight, the same thing will happen. App Store Connect, test flight. I'll see the latest version pop up here once I make my deployment.

Okay, so, okay, so here's the thing. So this is why this is actually kind of helpful to see. So this fail to upload Play Store failed because our APK specifies a version code that has already been used. So I mentioned earlier that the bundle identifier needs to be unique, and so does the version code as well. Each new build needs to have a new version ID. So this can be really tedious to do manually, right? Because we're pushing commits, we're pushing commits, and then we're ready to do an upload. So the best thing that you can actually do is to automat increment the build number, as I mentioned before, based on what's happening in the build ID in AppFlow. So how can we do that? Let's take a look at automatically configuring our build number. So this is using a tool called trapeze. One second. So trapeze is a free open source tool for configuring your mobile applications. So what we have is a YAML file. This is a ci.yaml file that we've named where we're essentially saying, at the time that we run this file, override the iOS build number and the Android version code with the CI build number environment variable that we're pulling from our CICD. So most CICD providers, pretty much all of them will expose an environment variable that is called a build number. And that corresponds to the build number in your CICD. What then happens is as part of our package.json scripts, we'll have like a CI configure command that we can run. In Appflow, Appflow will automatically kind of detect your trapeze. But we'll run trapeze, then we'll run that CI.yaml file passing through a Forts and Android or an iOS build. And then when that takes place, we'll grab that CI build number and we'll override it with the build number in the version code. So if we have this in our application in our code base, we don't have to manually update our version number every time that we create a new build. It'll automatically update. And the best part is automatically correspond to that log. So if something breaks or some issue happens, we can immediately tie that release back to a specific build and go look at the build log and see what's happening there.

So, once we have successfully been able to deploy to our appstores, and we're able to kind of go through that testing process. I showed you how to promote to a release and test flight in AppStore Connect. You know, this is ready to submit. You also are able to set up all of your app store information here. So what this will do is that you'll allow you to prepare your app for submission. This is where you'll update your previews, your screenshots, your promotional text, your description, your keywords, your URLs, everything that you need for your app store listing. Then once that's ready, it's a little bit different because instead of promoting to release like you do in Google Play, you're going to add for review. Now, Google Play and App Store both have a review process. The terminology is just a little bit different. So you add for review and that will go ahead and get it into the app review process. So once it's in app review, you can see it here and then you can see the status of the review process so far. Submitting your app to the app stores is not instantaneous. The official answer from Apple is it can take up to a week or more, which is like a very scientific number. It's really difficult to work with that. So understanding some of the reasons why apps get rejected or need to be resubmitted can be really helpful in ensuring that you have a smooth release process. So let's take a look at some of those reasons. So these are the most common reasons why your app store can be rejected for Apple App Store. Google Play also does have its own review process, but most people I talk to, and most in my experience has been that Apple is more tedious or more difficult to get accepted. Pretty much everybody gets rejected the first. Yes, recently I was at an event, and there was like hundreds of people, and I said, who here has been rejected from the Apple App Store, and almost everybody raised their hand. So understanding, so if it happens to you it's a rite of passage, but understanding some of these major reasons can help with limiting that process. So crashes and bugs, making sure that your app is fully tested before you promote it for release. If there's any broken links or incomplete information or please holder images, that can immediately get you rejected. The next two are privacy policy issues and unclear data access requests.

So I mentioned that you have to, in the Google Play side, you have to go through that big questionnaire. In iOS, you need to specifically state each type of data request that you'll be making. So if you're requesting someone's location, access to their files or their photos, you need to explicitly state those and then also give a description that will pop up when you do make that request in order to explain to the user why you're requesting that data. If any of that is not configured correctly or unclear, then you can get rejected and have to resubmit.

Also, substandard UI. And the Apple Developer Docs actually give you some screenshot examples of what a substandard UI looks like. And this one makes me laugh because if we did that in the web world, like 60% of apps wouldn't be on the web if they could be rejected for a substandard UI. But that is a reason why you can be rejected.

The next one is static web content. So static web content does not mean that you cannot take existing web content and then turn it into a native application. What that means is that a native app should have a reason for existing. So if you take a blog, for example like a static web blog, and you try and turn that into a native application without adding any kind of native functionality to it, then that can get rejected because there's no reason for it to exist as an app. It can exist as a static website, right? So you can absolutely take existing web content and repurpose it. A lot of people do that, for example, with like ionic and capacitor apps. But it doesn't need to have a reason to exist as a native app.

And last but not least there's not enough lasting value. So this refers to both like niche apps that are very very specific in their use case, but then also time-based apps too. So if your app really only needs to exist for like a week or something, then you may have issues getting accepted into the app store because it's not going to be something that needs to exist on and on. That's why sometimes you'll see if you do have a very time-specific app, you'll see like services that then like for conference apps, for example, that then wrap it in a different type of service. So that is something where you need to think about like it does it need to exist in the app store or will it exist for a period of time and does it have lasting value.

Another thing to think about in terms of when you have releases is that you need to have ongoing support of your releases. So again, with web apps, once you have a new release and you push that out, everybody is on the same version of your app, barring any like feature flags or, A, B, testing. With mobile apps, that's not the case, right? So you have to think about backwards compatibility whenever you make changes. So you could download a version of the app and then never update it again and they still exist out there. So that's what we call like the long tail of app versions that you need to support. So whenever you make a change to your backend or an API or some third party service that you're using, you need to ensure that that will still work with any versions that are still out there. You do have what's called forced upgrades as a mechanism. So you might see this for like banking apps a lot, for example, where you go to login and it says, a new version is available, please update to continue and it takes you out to the app store, right? So you can force users to get on a newer version if you do have any breaking changes, but you wanna think about how that can impact the user experience, right? I mentioned earlier as well, that you need to have specific native dependencies that you're, you're supporting. So if you have an old version of your app and you haven't updated it in a while, you haven't needed to push in new changes, but a new SDK is required. Then you need to make sure that the app is rebuilt and republished with that new SDK version. So a couple things in order to keep in mind, as you, once you release a version, like it's out there and you need to be able to support that indefinitely. So a nice thing is that, again, you can kind of see all the versions that have been deployed in your deployment history and get a sense of like, what's been out there, what's the latest version for each deployment that takes place. You can also see the corresponding build number. You can see which commit it was tied to as well. So you have a sense of what the most recent version is that has been deployed. Again, you can also always this information in Apps Store, Connect or Google Play as well.

All right, so just covered testing tracks and App Store rejection reasons. So as I mentioned, I did share these slides out. I'm gonna go ahead and just share that link one more time in the chat as some resources here for you. So the resources that I'm sharing are the Apple documentation. We also have some Apple specific blog posts and we have the Ionic Resource Center, which includes some webinars and some more information. I am doing a webinar next Wednesday about how you can deploy to test devices but then also test on multiple devices automatically. So I'll be talking about that. We'll also be talking about a new feature coming to Appflow designed for simulator builds. And here is also a link to the slides for those shipping Rack Native app slides. So these are the slides that we're going through quite a few of them talking about the kind of the build process. And then I also am including the link to the code signing Rack Native app slides. So these slides, and just make sure that this is. These slides are very specific to the Rack Native code signing process.

These slides are very specific to the Rack Native code signing process. And this includes the instructions for if you wanna generate using KeyTool for Android Studio and then also on the iOS side, if you want to generate your certificate using the certificate assistance, this is outside of Xcode. So if you don't have Xcode on your machine, this is the way that you are able to create a new certificate. And it's a little more complex. And it has all the provisioning profile of screenshots and information as well as how you can have automated signing using the GitHub action that I mentioned. So all of that is here in the slides for you.

And then as a last note, we also do have a e-book about mobile CICD with AppFlow. This is a more high level concept driven e-book around the best practices for implementing a CICD pipeline. So if you're interested in that, the link is also there as well.

So, all right, great. Well, in the time that we have left, are there any questions that I can answer about anything that we covered today? Happy to kind of demo anything else and take a look at anything else as well.

Okay, so I personally have not used Microsoft App Center, but I have talked to people who have used it. So, it is similar in that, typically the use case that I see people use App Center for is for distribution. So they will upload their binaries in order to distribute to QA testers, the internal stakeholders, but it is very similar in that it does, you have the option to do cloud builds, you have the option to do uploads as well. I would say one of the differences is that app flow was initially designed for capacitor develop, for ionic and capacitor developers. So it's designed to be very user-friendly for web developers who are coming to mobile and coming to cross platform for the first time. So as you can see, like our GUI is pretty straightforward. It's like a form, it's like dropdowns, like drag and drop, trying to make it as simple as possible. That being said, the reason it's designed that way is because it's designed to do those two things really well. It's designed to do the cloud builds, the deploy, they upload to the app stores and then automations, as streamlined and simply as possible. So, different CI-CD tools that may have kind of more complexities but then also more like features that are built into it. So depending on what your use case is, if you do need like very specific types of workflows or if you need different, like different like configuration steps, then you may want a tool that is something that's more like YAML based or that has a more complex GUI. For example, a lot of people will ask like comparisons, like to Bitrise, and Bitrise has like 300 workflow steps and a workflow builder, but it becomes like, it's kind of just like more complex that way because of all the features that it has. So it just kind of depends on what your use case is. So, AppFlow, the GUI is designed to be very straightforward and simple. We do also have a CLI that you can integrate with existing CIC as well, but that's kind of my, what I heard from it.

Yeah, so it can be triggered from GitLab's CICD. So here I mentioned that we have a CLI. So our CloudCLI, essentially, like what you install it in your pipeline, it takes less than a second, I've done it myself before in GitHub Actions, and then you're able to interact with it in order to trigger builds and uploads. So this is a GitLab example, and I can pop this in the chat, but what you're essentially doing is you're just passing through your, like an Ionic Cloud, like an Appflow token, and then you're triggering your build. You're then deploying it up here to the App Store. Now, you're triggering this from a GitLab runner, but you're using our machines. So you don't have to have a Mac, you don't have to provision like a Mac hardware or Mac machine, you don't have to install any of those dependencies, because what you're doing is from the GitLab runner as part of an existing workflow, you're telling Appflow, hey, use this commit shaw, do a build of this build type, then me back the binary, that way I can do with it whatever I want. So for example, you can then upload it to Sauce Labs for testing, or you can just upload it to Microsoft App Center if you wanted to, or you can again then use the Appflow CLI to upload it to Test Flight or upload it to Google Play. So this is the GitLab example. I actually also built out an example for GitHub actions. So this is the GitHub actions version. Similar, it's just, you have your secrets, you have your token, your app ID, the type of signing sort that you want to use, and then like your destination. And you install the CLI. You're building it, again, this is all on Ubuntu, but you could be doing Mac builds, whatever it is that you want, you don't have to install your credentials. Everything is done on our servers. And then the AAB is being sent back. You don't even need to do that. You can also just trigger the upload using the build ID because again, everything is happening on Apple servers. But I personally like to upload the AAB and GitHub actions as well, so I have the artifact in both places, but that's optional. And then just also clarify, you mentioned GitLab CI CD specifically, but we also do support GitLab as a Git provider as well. So if you host not on GitHub but on GitLab you could do, basically we have GitHub, GitHub enterprise, GitLab, Bitbucket, Azure DevOps, and then something called Ionic Remote, but that's like if you don't have a Git provider, but we recommend having you have a Git provider. Good questions, right, well, like I said, if anything comes up please feel free to reach out to me. I am at Cecilia Creates on Twitter, GitHub, also it's just Cecilia at Ionic.io is my email. So if you have any feedback on AppFlow as you're running through it or checking it out, let us know. Yeah, the slides are published so they shouldn't go down. Awesome, well, thank you all for your participation, I hope this was helpful for you and yeah, let me know if you'll have any questions. And yeah, it's honestly like coming from a web background and learning mobile, it's a lot. So it'll take some time, you'll get rejected, it'll happen and it's just all part of the process.