A Complete Guide to Flutter CI/CD for iOS, Android and Web

Reading Time: 23 minutes

We all know that, Flutter CI CD (or any other mobile app CI CD) is about the last thing you want to think about, just behind writing tests.

But, like it or not, Flutter Continuous Integration makes your workflow, and your apps, so much better that using it is actually less of a hassle than not doing it.

This is because ignoring it costs hundreds of hours of pain in the form of chasing bugs, rollbacks, and even hours spent in meetings trying to explain to the stakeholders why everything just went sideways. And no, Flutter people, you can’t get out of this because in Flutter, CI CD is just as important as it is anywhere else.

Continuous Integration for mobile apps used to mean throwing your mobile app code into the same CI CD solution you used for your backend, but Continuous Integration for mobile has become a thing in its own right. When we say “Continuous Integration for Mobile Apps”, we’re not just talking about Flutter CI CD with GitHub Actions or Jenkins. We’re talking about specialized CI CD solutions for many ways of developing mobile apps:

• Android (Java/Kotlin)
• iOS (Objective-C/Swift)
• Flutter
• React Native
• Even low-code solutions like Smartface

Regardless of which one you’re doing, you can’t just reuse the same CI CD pipeline you use everywhere else and expect it to work as well as a dedicated mobile CI CD pipeline.

Earlier in this blog, we went over 5 differences between CI CD in web/backend, and CI CD in mobile applications, so you can understand how important is is to not treat them the same way: https://appcircle.io/blog/5-differences-between-mobile-web-backend-ci-cd/

 

 

What exactly is CI/CD, anyway?

CI CD is a philosophy, a way of doing things, that makes your life easier. It stands for Continuous Integration, and depending on whether you give it permission to Deploy your app automatically, the CD could stand for “Continuous Delivery” or “Continuous Deployment”.

CI CD solutions allow you to catch problems faster, while they’re still relatively easy to fix. It runs your tests in the background, where you don’t have to think about them. Sticking to the principles inherent to every CI CD Solution will help keep your repository up to date, just in case the worst happens and the magic smoke leaks out of your laptop. It also makes it easy to roll back when things go wrong, and the fastest way to keep the customer happy is roll it back to what you were running yesterday.

In general, actually using mobile CI CD day in and day out comes down to consistently doing a few simple things:

• Commit, push and merge small chunks of code often.
• Include tests in your app so the CI machine will run them for you.
• Don’t ignore your emails (or Slack). Email or Slack is how the CI machine contacts you to tell you something went wrong (unless you’re staring at the build log for fun, since you don’t actually need to sit there and stare at it).
• If you’re not allowing the pipeline to deploy automatically, then after a successful build you would send the finished files (called artifacts) to wherever you need them. If you’re using Continuous Delivery, sending it to managers, testers, stakeholders or the app stores is taken care of for you. However, note that most developers aren’t comfortable having a new version pushed to the app stores automatically. They prefer to check it themselves, first.

When you’re using a cloud-based CI CD, here’s the way it actually works for mobile apps:

• You push to your code repository.
• The CI system starts a new virtual machine instance, and installs all needed software such as Flutter, Java, or whatever else you need for developing mobile apps on your platform of choice. (This is one of the primary differences of mobile CI/CD. There are so many strict requirements that you need a special build environment for your app, e.g. iOS apps can only be built on a Mac.)
• The build agent then pulls your current version.
• Your build agent then goes through the workflow you told it to, one step at a time. (Workflows are discussed in the next section).
• Usually tests are run and, assuming they pass, the binary is built. If the tests don’t pass you’ll be notified, and the app won’t be built since building after tests fail would be a waste of time.
• You and anyone else you put on a list (e.g. your manager or testers) can get notified when the process is complete, and whether it passed or failed.

There are two parts to all this, Continuous Integration and Continuous Delivery/Deployment.

 

Flutter Continuous Integration and Workflows

Continuous Integration (or CI for short) is an automated way of building every time you push code to your repository and Appcircle has put a lot of thought and effort into making our  Flutter Continuous Integration as easy as possible. CI CD solutions are ideally enhanced with workflows. Workflows allow you to add or remove automated steps that happen before or after your build, so you can automate things like:

• Automatically running tests from Flutter’s test folder.
• Signing an Android APK with a keystore.
• Installing iOS Certificates and Provisioning Profiles.
• Creating an Android Dependency Report.
• Building Flutter for Web. (Cross-platform output is possible from a single Flutter project.)

 

Continuous Delivery/Deployment for Mobile Apps

Continuous Delivery (or CD for short), is the automated “delivery” of the application with environment deployment (e.g. a development or production variant), code signing, versioning and sharing the successfully built releases with the related users (e.g. testers). But what does “delivery” in continuous delivery mean?

For mobile apps, where binary files are the only means of deploying apps, the concept of “delivery” is especially relevant.

It means that the Continuous Integration machine “delivered” all of the “artifact” you’ll need in order to “deploy“ your app to the next step. So, what’s the next step?

What’s next is going to depend on you. What do you usually do with the finished APK or IPA binary? Well, do that!

You might send it to testers who will ensure the app meets all of the requirements laid out in those meetings (you thought were never going to end). Or maybe you’ll deploy it to testers who hook it up to live data and see if they can break it. Then again, maybe you’ve done that in the past and now have enough confidence that you just deploy the artifacts straight to the app stores.

Did you notice something all these have in common? They’re all getting “deployed”. So why is this stage called Continuous Delivery and not Continuous Deployment?

Because if you do it the above way then the artifacts get deployed by a human, and therefore the process is not continuous. If you let the machine automatically deploy the artifacts then it becomes continuous, which is how we get “Continuous Deployment”.

In other words, with Continuous Delivery you do the deploying, in Continuous Deployment the deploying is just the last step in the workflow. You can even have the finished binary uploaded to the app stores, automatically keeping your app update.

But what if I don’t want to send it to the app stores yet?

That’s fine, you can make different workflows for each branch. All you do then is make sure you don’t merge and push to the branch that goes to the app stores until you’re ready.

 

But what are the benefits of Mobile CI CD, what’s in it for a developer?

Higher productivity and lower costs

First and foremost, CI/CD solutions give you higher productivity that comes with any automation. Just as in manufacturing, you can automate the repetitive process (application builds) with automated workers (CI CD solutions). This enables the developers to focus on things that can’t be automated… like sitting in meetings.

Keep an eye on this blog, because Appcircle is researching ways to automate Zoom meetings too, by using cardboard replicas that look just like developers. Our engineering team has been testing the idea for several months…

Faster release cycles

Running a build takes a lot of time. So much time, in fact, that some developers who do their builds manually, on their local machine, suffer from “let me add this one more line” syndrome. What happens is the developer has an idea they want to get in, but if they start a build now it’s going to be a long time before they can get back to coding. So, they just add “one more line”. But then they notice something, or think of something, or get told something… and one line turns into another and another.

Pretty soon, that next push has five hours of work crammed into it, and when it all goes wrong you’re going to be crawling through five hours of code trying to figure out what you just messed up.

Do you really want to be doing that on a Friday?

At 4:30?

If you’re using a mobile CI CD solution like Appcircle, you get used to the idea of pushing even the smallest of code changes because you don’t have to worry about being stuck waiting for a build to finish. It’s all taken care of somewhere far away, on some VM in the cloud.

This means you can get right back to that great idea you just had… the one the stakeholders are going to hate.

Faster feedback/response

With faster release cycles with smaller changes, it becomes possible to pinpoint the exact source of error when an issue identified. This is especially important in larger teams where code conflicts may cause significant issues.

Just as the name implies, the code is integrated continuously without any manual handoff, making sure that all pieces fit perfectly and identify any unfit pieces to be reworked before it is too late.

Increased coding discipline

Every pull request commit builds before it’s merged, and then there is the automated unit testing and code reviews after every push. This results in code that been inspected more more thoroughly by the time you release it.

Early warnings

With every single change being tested as part of the workflow, issues can be identified faster, while they’re smaller. This means less code to dig through in order to find what went wrong.

This can be especially important on a Friday afternoon.

Better visibility

This means two things for you. First, you and anyone else you include will be notified any time something goes wrong. You could even choose to be notified when things go right, but that tends to quickly lead to notification fatigue.

The other thing it means is that you have a lot of data in the build logs that you might not have had access to in the past. That data makes it a lot easier to track down what’s going on, and spot trends to help you see things you otherwise might have missed.

The complexities of delivery are handled for you

This is especially important in multi-platform apps, where you have to worry about more than one process of building, signing, distributing and installing an app. Each development discipline has its own set of complexities and the mobile apps are no exception. By automating all of these, you’re freed up to spend more time coding.

 

Why not just use Jenkins for Mobile CI CD?

Jenkins is a general-purpose CI CD solution, but you may be wondering if you should use it for you Mobile CI CD. Jenkins is one of the most popular tools for DevOps, but Mobile CI CD tends to be better off with specialized tools that meet the unique needs of mobile apps.

How could Jenkins be used for Mobile CI/CD?

Jenkins works with a lot of different tech stacks, but it’s not specialized for any of them. In the case of an unusual situation like Mobile CI CD, it requires a lot of complicated configuration, you need to know all of the many different plug-ins to set up a full pipeline, and then there’s the time you need to spend managing the whole thing.

Jenkins can solve the most common problems, but falls short in anything that requires precision without additional tools.

Just one example is that with Jenkins you don’t get any storage for previous builds and artifacts. This is something you get out of the box with just about any decent Mobile CI CD solution.

Is it possible to use Jenkins for Mobile CI/CD and be productive?

When we hear this, the first thing we think is, “they’re asking the wrong question”. It’s not a question of it it’s possible to create your Mobile CI CD with Jenkins, the right question is, “Is it worth my time to use Jenkins for my Mobile CI CD?”

Using Jenkins for Mobile CI CD isn’t easy, it takes a lot of time to set up and even more time to maintain; and you do your own maintenance, without any official support. And don’t forget you’ll have to deal with build environment issues, such the specialized requirements you need to meet in order to build iOS apps. Mobile stacks also have a lot more controls, rules and standards that are constantly being changed by Apple and Google… someone has to maintain all of that.

With iOS, the builds have to be done on a Mac and if you have multiple builds it becomes difficult to isolate them or create queues. Also, don’t forget Scaling. Scaling the Jenkins instance is easy, but scaling build environments is a lot harder and requires specialist knowledge when working with Macs.

A special case for Mobile CI/CD

Mobile CI CD is usually handled by the developers because of the unique knowledge required, but with the advent of specialized Mobile CI CD solutions all of this can now be handed off to someone else, freeing up your developers to… well… develop.

Appcircle was designed form the ground up to be a dedicated Mobile CI CD solution that makes Mobile CI CD accessible to everyone by providing all the specific features needed in a way that’s quick and easy to set up. The maintenance of the pipeline, including managing compliance with Google Play Store and Apple’s App Store’s rules, is all handled for you. For smaller teams and individual developers this is all hosted in the cloud, but for an Enterprise situation everything is put on-site in order to keep the CI CD solution within the company’s secure Intranet.

 

Setting Up Flutter CI CD with Github and Appcircle

When setting up Flutter CI CD in Appcircle, there are three main points of automation to consider:

• Auto Build: Builds new pushes or similar triggers automatically.
• Auto Distribute: Deploys new binaries automatically to the Appcircle Distribute module, where you can use it with the online mobile device simulator/emulator or share with the testers.
• Auto Dend: Sends new versions of the apps automatically to the selected testers and testing groups.

For Flutter CI CD, Appcircle’s approach has been to make it as consistent as possible with the processes of setting up CI CD for native Android, iOS, plus React Native and Smartface.

 

Setting Up Your Account

Most of the setup is self-explanatory and similar to what you’ve done many times in other places. The one difference is how to set up 2FA with Appcircle, which we’ve made as easy as possible.

The first thing to do is create a new build profile. Once you log in, click the hammer on the left or, alternatively, where it says build in the middle of the page. That will take you to the below screen, where you click “Add New” on the upper-right.

Since the security of your source code and your app is of utmost importance, Appcircle supports logging in with 2-factor authentication.

You can set up your account’s 2FA in a few extremely simple steps:

• Sign in.
• Go to: https://auth.appcircle.io/auth/realms/appcircle/account/totp

• Scan the QR Code with your device.
• Go to the link.
• Save the key to your 2FA app of choice.
• Go back to your Authenticator page in Appcircle.
• Add your device name (that’s the bottom field).
• Add the current 6-digit 2FA code in the “One-time code” field.
• Click save before the 6 digit code changes in your 2FA app.

 

Create The Build Profile

Now that your account is ready, taken care of, it’s time to get started on the build profile. Go ahead and click “Add New” in the upper right.

 

Now name your build profile, select your target platform and be sure to pick Flutter as your source code type.

 

Binding to a GitHub Repository You Own

It’s time to bind your repo to your build profile. Keep in mind, if you do not own the repo and only have access to it as a team member or member of an organization, then you’ll need to bind via SSH. This is covered in the section after this one.

This very simple procedure will work for any repo you own, public or private. First, just click on Github on this screen.

 

Github will ask you to install and authorize our app. You can authorize only one repo or the entire account. You’ll want to remember if you only authorize a single repo, because it’s easy to forget and then get frustrated later when it doesn’t work while trying to bind a different repo.

 

After authorizing, you’ll automatically be sent back to this popup, where you can choose which repo you want to bind to this build profile.

You’re done.

No, really. You’re done. It’s that easy.

 

Binding to a Github Repo You Don’t Own, via SSH

To use Flutter CI CD with Github with a private repo when you’re a team or organization member (but not the owner of the repo), you’ll want to click on “Connect via SSH” instead of Github.

You’ll then see a screen like this:

This requires a few steps but don’t worry, we’ll walk you through them with clear, easy to follow steps.

You need to add your SSH public key here, we’ll show you how to make one in just a moment, but you need to know there’s a trick to using keys here. The trick is your key cannot be encrypted with a password. If the second line of your public key says “ENCRYPTED”, then it has a password and it’s not going to work.

If you need a new key, here’s how you can do it:

1. 1. Open your command line app of choice and navigate to where you want the keys.
      • Tip: You can create them anywhere and then move them after they’re created. If you’re using Windows, don’t make yourself crazy trying to cd through 20 different folders. Just make the keys on the desktop and then cut & paste them in Explorer. It’s a lot easier.
   2. The command you want to use is “ssh-keygen -t rsa -b 4096 -f appcircle-ssh -m PEM”. If you’re familiar with ssh-keygen then be sure to leave the -P argument out!
   3. When you hit enter, you might be asked to supply a password, even if you left the -P argument out. Don’t do it, it’s a trap! Just hit enter (twice if it asks again) and you’ll get two files. The private key is “appcircle-ssh”, and the public one is “appcircle-ssh.pub”.
      • Your OS might try to claim the .pub extension belongs to a word processor or slides program, such as Powerpoint. Just ignore that, it’s harmless.
      • Double check that your public key doesn’t say ENCRYPTED.

If you’re not familiar with Appcircle then you might want to go through the rest of the configuration and come back here. The reason is that the rest of the things you need to do for SSH setup are going to have you going into some configuration screens and those are covered below, starting with “Configuration Tab Settings”. Though, if you think you want to try finishing SSH first then we tried to make it easy for you.

1. Next, enable Auto Build in the Config tab.
2. Go here: https://github.com/settings/keys
3. Once there, click “New SSH Key” and paste in your public key text, that is where you put your public key (the one with the “pub” extension).
4. Now go into your repo’s settings on Github and choose “Webhooks”, in the left-side menu and add a webhook.
5. Back in Appcircle, go to the “three dots menu” for the build profile you want to bind and choose “Webhook URL”. Copy it with the little orange button in the popup.
6. Back in Github, you’re going to want to do a few things.
   1. Paste your Webhook URL into the “Payload URL” field.
   2. You have to change the default “Content type” to be “application/json” (the red arrow in the image below). If you leave it at the default, your trigger won’t work.
   3. Leave SSL Verification on.
   4. Choose your event type(s). Most of the time it’s going to be just the push.
   5. Ensure it’s set to active.

Now your repo is bound and Auto Build on push is all set!

 

Start to Configure Your New Build Profile

You may have seen a little of this if you set up SSH, but don’t skip it because there’s more we didn’t cover yet.

Click somewhere on your build profile’s box (but not the three dots) to get into your new profile.

 

You should see a list of commits for the chosen branch. If you haven’t been making any commits then  you should be starting to do so to get started with healthy CI CD habits and for automated builds.

You can have different setups for each branch (if you have more than one), so make sure you select the branch you want before clicking on the config button, in the upper-right.

 

In the build configuration, there are four tabs across the top. Config, Signing, Distribution and Event Variables. Looking at Config, there are four items we’re primarily concerned with.

• Build mode is typically going to be debug or release, but you can also create a profile build.
• Additional arguments are for the things you would put after “flutter run”, if you were building your app from the command line. This would include things like “–no-sound-null-safety”, which can be important since (as of this writing) some important packages have still not been refactored to be null safe.
• For Android, your output type is going to be Apk or Aab, depending on your needs. If your Flutter project is being built as an iOS app, you’ll see a button called “Fetch Details”, which will try to automatically populate these fields for you.
• Last, if you want your builds to be triggered on push then you’re going to need to ensure Auto Build is turned on.

 

Auto Build Settings

Speaking of Auto Build, there are three ways you can trigger one:

• Auto build on every push: Appcircle will start building your application whenever you push a commit to your Git repository. For the specified branches, your project will be built automatically with the selected workflow.
• Auto build pull/merge requests: Appcircle will start building your application whenever you initiate a pull request or merge request from the source branch(es) to the target branch. The build will be done with the pull/merge result using the selected workflow. This allows testing the PR/MR result before the actual approval of the request.
• Selective auto build with specific tags: Appcircle will start building your application with the selected workflow whenever you perform a push with certain tags to your Git repository. Your project will be built automatically only if the push has the tags you specify or you can specify a wildcard tag to build all tagged pushes. This allows build scenarios like building only specific pushes that has the “release” in the tag.

 

Creating a New Keystore/Signing Certificate or Using Your Own

The procedure for iOS Signing Certificates is similar to creating a keystore, which we’ll go over here.

Before we take a look at the Signing tab, we need to make sure we have a keystore to use with it. To do that, we go over to the left-hand side of the page and click the Signing Identities button. It looks like a certificate, and is the first icon under the hammer in the left margin.

When you’re releasing to Android, be sure to select Android Keystores on the left because, when there’s nothing in the main windows, iOS and Android look the same. It’s easy to accidentally hit Add New without changing to Android Keystores first, and this will cause you to go to a page for iOS. If you have a keystore then you can upload it here, otherwise Appcircle can make you one.

 

You know what to do here… Just please don’t use “password” for your password. And you might consider not naming your alias “alias”, either. It might take some for this process to finish, so now is probably a good time to refill your coffee mug.

 

For iOS, things are as simple and you don’t even need a Mac to generate iOS certificates for your mobile CI CD pipeline. You can directly get certificates from App Store Connect or create them from scratch using a certificate signing request or upload a readily available certificate bundle.

 

If you ever need to know more about signing identities, you can find help in our documentation on iOS Certificates and Provisioning Profiles, and Android Keystore Management.

 

Signing Your App

Once finished head back over to your build configuration but, this time, click on the “Signing” tab. You should see the name of your keystore/certificate in the list.

 

The Distribution Tab

The third tab is Distribution. This is where you’ll specify if you want links to your finished files (called artifacts) to be automatically sent out to a list of people you specify. This is often used to send updates to testers, but you could send it to anyone. You can find more about how to create distribution profiles here.

Also, once you have your first build up and released on the app stores, then you can set your Flutter CI CD pipeline to automatically deploy each new version to the app stores. You have to put the first one up manually, but we can handle the rest for you.

 

Environment Variables

Environment variables give you the ability to extend your build configuration, and are used much like a Map in Dart. They have a key and value, but in this case the value is secret. You can define them manually to be used globally, in all of your builds.

Yes, this is where you would put your secret keys. There are some Appcircle variables (read only), plus you can add your own custom variables to export during the build process or use in custom build scripts.

 

You can also group environment variables, making it easier to customize your builds with preset groups of additional parameters.

 

Next is testing. You are using testing, right?

 

Set Up Testing and Many Other CI CD Operations With Workflows

On Appcircle, when you want to set up testing for your Flutter CI CD you’re going to want to come out of the build screen and click on the orange button with the three dots, then choose workflows from the drop-down menu.

 

We have two kinds of workflows available to us, Push and PR. For this article, we’re going to take a look at the Default Push Workflow but the steps are the same for both.

 

Here you can see what your current workflow is, but you can’t change anything. In order to edit it, you have to click the big, orange edit button at the bottom of the page (you’d be amazed how many people don’t notice it).

 

How to Edit Your Workflows

The way you use this is actually pretty simple. On the left is your current workflow. The red – indicates the step is in your workflow already and you can remove it. On the right are the available workflow steps that are appropriate for your source code type and target build, but don’t worry if you don’t see what you need because there’s one workflow step that cures anything that bothers you.

It’s called “Custom Script”.

You can do almost anything with a custom script, and if you have trouble using it then you can check our easy to read (really, it is) documentation here, or you can talk directly to our customer support team in the Appcircle Slack.

To use the editor, all you have to do is drag the step you want from the right and drop it where you want on the left.

 

Go ahead and grab “Flutter Test” from the right, and drop it between “Flutter Install” and “Flutter Build for Android” on the left.

This will cause your Flutter CI CD pipeline to run the test in your source code’s test folder, the same way they would run if you ran them locally from the command line or the IDE.

Be sure to save…

 

To Run or Not To Run…

It doesn’t make any sense to build if the tests fail, so let’s go into Flutter Test’s settings (click the chevron on the right).

 

Double-check that “Continue with the next step even if this one fails” is gray. This will prevent you from being billed for a build if your tests fail, since it makes no sense to get billed for build time if your build isn’t going to build.

Say that 3x fast…

 

Time to push…

When you push, you should see grey and white stripes on your commit listing, like this:

 

The system will then start a new VM for your Flutter CI CD pipeline and install all the needed software to run your tests and build your app. If you click on it, you’ll see the build log, shown below.

 

It’s very important to remember to keep your local Flutter SDK up to date because your Flutter CI CD pipeline is going to install the newest version of Flutter every time a new VM is created. If you don’t keep your local install up to date, then your builds are going to fail because you’re writing your code with an old version of the Flutter SDK, when the VM is running the newest release.

If anything goes wrong with your build, or your tests, you’ll see the error in red, demonstrated below. You can also be notified in email or, if you set it up, in Slack.

 

If everything goes well, your workflow will complete and your files (also known as your artifacts) will be ready for download and distribution!

 

So, where are my built binaries?

Appcircle will build your Android applications as APK or ABB files so that you can use them directly or upload to Google Play (as explained in the next section).

iOS applications are built in IPA file format if they are configured to be signed. Then depending on the iOS certificate used, you can share the app with the testers or send it to App Store Connect.

To download or distribute your builds, go to build profile and click on the builds tab to see your past builds. Click on the actions icon of the build you want to download or distribute.

 

Distribute Your Mobile App for Testing

After the build is successfully done and a signed iOS or Android app is generated, you can send the file to testers to let them download, install on their devices and run the application. This process can be fully automatic with auto build, auto distribute and auto send configured.

If you want to share a specific version manually, go to the Appcircle Distribute module and find the profile created for your app. Under here, you will see your past builds if they were deployed.

Click on the Share with Testers button and select the testing groups you created previously that needs to receive this version of your application. Alternatively, you can enter email addresses of the testers here to send them the application regardless of the testing groups.

You can also add a message to testers including testing instructions and release notes.

 

Test Your Mobile App in the In-Browser Emulator/Simulator

Throughout the article, we keep emphasizing the importance of testing and Appcircle allows you to test your Flutter iOS apps (or Android apps for that matter) right in your browser. You can run your app in a variety of mobile devices. You can make sure that the app works fine in different OS versions and screen sizes.

If you set a distribution profile in the distribution configuration, you can deploy your app and share it with the testers or preview them right in your browser in the online Android emulator or the iOS Simulator. (Please note that this does not use the Flutter run command.)

In the Distribute module, click on the selected profile, select your OS on the top left and then select a version. To run that version in the online emulator, just press the “Preview on Device” button on the top right. (Your app must support the x86 architecture for this feature to work.)

 

How to Send Your Flutter App to App Store and Google Play?

With Appcircle, you can deploy your app to Google Play Console and App Store Connect without a Mac and any other third party tools. You can even automate store uploads.

To upload apps to Google Play Console and App Store Connect, the primary prerequisite is to set the Android Package Name and iOS Bundle ID same as the destination app listing. Once you build your app with an iOS distribution certificate and as an AAB file for Android, you can send it to the Appcircle Store Submit module.

To send apps from Appcircle, you need to provide a Google Developer API key for Android and App Store Connect API key for iOS. To add a key, go to My Organization and press the “Add New” button (or the “Manage” button first if you have saved keys) next to the related item under the Connections section.

 

Once you deploy the binary from the build or the distribute module to the store upload module, the binary will be available in the related store submission profile. The profile name and icon is automatically fetched from the latest binary and the profile is automatically matched with the Android Package Name and iOS Bundle ID

There are three actions available for each version in the version list. The first action displays a screen where you can initiate the store upload to the specified destination. The second action allows you to view the logs of the latest upload of that binary and the third action allows you to delete that version.

 

If everything goes well, your app will be ready for prime time in the app stores!

It is a breeze to have your app deployed from code to the store automatically without any third party tools. Configure your app once and leave everything else to Appcircle for any type of mobile apps, not just Flutter.

 

Don’t forget, we’re here to help if you run into problems. You can find us in the support channel of the Appcircle Slack, so come on by and say hello.

 

That’s it! That’s how you can do Flutter CI CD with Github, using the easiest Flutter CI CD solution around. Appcircle!

With Appcircle, you can automate the full lifecycle of your mobile app with continuous integration, continuous delivery, and continuous testing.