With phase 1 nearing completion, it was time to get the build process into a CI pipeline, this was something that was key for me working at Wyzetalk as we are unable to do that with some of the legacy products. Initially, I looked at codemagic, but from a costing aspect, it would not have been feasible especially when all our Web Apps where already being deployed through Azure Pipelines.
There was not too much info available online as to how to get it to work, specifically iOS, and that which I did find, did not work, so just in case anyone else has a tough time, here is what I ended up doing.
To work around some of the issues I was facing, I needed to add FastLane into the pipeline, which was how I had been doing the deployments up until now.
Using the available tooling for getting iOS built was not easy to figure out at all and in the end, I was never able to work out how to resolve the last (I presume) issue with signing the archive.
The android tool worked, the only issue I had was that it could only build for a single architecture, and I was not using
aab for this project, and building a standalone 32b APK resulted in upload failures as it did not pass 64b requirements.
The android tools worked right off the bat, but for me, a big limitation was the inability to build multiple
— split-per-abi) and at this stage moving over to
AAB is not an option. This meant I was only able to push up the 64-bit APK as the 32 bit naturally failed the 64-bit check.
For a quick overview, which covers purely the pipeline here is my YAML file, however, a few other code changes were made as well to facilitate these steps.
The first step was simply to install FastLane, which was done using the
brew install fastlane
I also had to ensure the
gem bundler was correctly setup, I included this in a separate
command-line script which makes it easier when debugging output.
gem install bundlerbundle update --bundlerbundle install
On the code side, I added a new lane* to
fastlane to ensure the provisioning profiles where there and up-to-date. Using a white-label app we use a profile per pipeline/client as it’s easier to manage, especially for the few that use their own store accounts. Fastlane is also capable of generating these for you from the command-line
*a lane is basically command line script group
desc "Update provisioning profile"
lane :profile do
These few steps use the built-in tooling which may need to be installed from the market place.
Install provisioning profile (as from the previous step)
Install the Apple Developer Certificate
Flutter Build (iOS)
This was where I had my most issues with the tooling, I could not work out how to get XCode to generate the archive (
ipa) so for that I used FastLane.
bundle exec fastlane ios ci
The App Store release tooling however works great and requires less config than I would have needed with Fastlane.
I also used Fastlane to build the android
apk’s, this way I could build all architectures, which is 3 in my case, with a single command.
$(FlutterToolPath)/flutter build apk --split-per-abi --build-number=$(buildNumber) --build-name=$(package.version)
Finally, using the Google Play — Release tool I simply provided the primary APK path as the 64bit one and under advanced options, you can pass a path
$(Build.SourcesDirectory)/build/app/outputs/apk/release/*.apk so that you can then push all 2 or 3 files generated files.
If you are however using
aab you can simply build that with the available tools.
I hope if you have made it this far you found it useful, the android steps are pretty straight forward, using Fastlane there is more of a “me” requirement other than something I think will generally be used, it is advisable to use the
aab rather, but managing multiple apps for multiple clients I feel may unnecessarily complicate the process especially seeing as we will need to update existing apps.