Walk me through a Flutter CI/CD pipeline for Play Store and TestFlight

WHAT THIS TESTS: The interviewer wants to see if you can design a production-grade CI/CD pipeline for a cross-platform mobile framework. This means understanding that Flutter builds are not platform-agnostic once you leave the Dart layer. You need to show you know how Android release builds require keystores and Google Play signing, while iOS requires certificates, provisioning profiles, and App Store Connect authentication. They also care about pipeline efficiency, secret management, and whether you understand the difference between internal testing tracks and production releases.

A GOOD ANSWER COVERS: First, trigger and environment setup. Mention using workflow triggers on main branch merges or tags, and injecting secrets like the Play Store service account JSON, App Store Connect API key, and code signing materials via encrypted repository secrets or a secret manager. Second, the test stage. Run flutter analyze, flutter test for unit and widget tests, and optionally integration tests on emulators or simulators. Third, parallel build stages. For Android, build an AAB using flutter build appbundle with release signing configured via key.properties or environment variables. For iOS, build an IPA using flutter build ipa which requires Xcode certificates and provisioning profiles installed in the runner, often via a tool like fastlane match or Codemagic's built-in signing. Fourth, deployment stages. Upload the AAB to the Google Play Internal Testing track using the Play Console API or fastlane supply. Upload the IPA to TestFlight using the App Store Connect API or fastlane pilot. Fifth, post-deploy verification. Mention checking build status, distributing to tester groups, and tagging releases.

COMMON WRONG ANSWERS: A major red flag is suggesting manual drag-and-drop uploads to the stores after the pipeline builds the binaries. Another is proposing to build debug APKs instead of signed release AABs for Google Play, or ignoring that iOS requires a Mac environment and cannot be built on a standard Linux runner. Candidates also stumble by storing signing keys in the repository or hardcoding credentials in workflow files. Saying you would use the same build command for both platforms without platform-specific blocks shows shallow experience.

LIKELY FOLLOW-UPS: The interviewer might ask how you would handle rollout percentages, phased releases, or automatic promotions from internal testing to production. They could probe rollback strategies, which on mobile means submitting a new build rather than reverting artifacts. Expect questions about managing versioning and build numbers automatically, perhaps by reading pubspec.yaml and committing incremented versions back to the repository. They might also ask about pipeline cost optimization, such as whether to use M1 Mac runners for iOS only and Linux runners for Android, or how to cache Flutter SDK and Gradle dependencies between runs.

ONE CONCRETE EXAMPLE: Using GitHub Actions, you would define a job that runs on ubuntu-latest for Android and macos-latest for iOS. The Android job checks out code, sets up Flutter with the stable channel, runs flutter test, then flutter build appbundle. It uses a base64-encoded keystore stored as a GitHub secret, decodes it at runtime, and passes the path to the build command. The resulting appbundle is uploaded to Google Play Internal Sharing or the Internal Test track via the google-github-actions/deploy-play-release action using a service account JSON. The iOS job runs in parallel on macos-latest, installs the Apple certificate and provisioning profile from secrets, runs flutter build ipa, then uses fastlane pilot or the App Store Connect API to push the IPA to TestFlight. Both jobs use artifact caching for the Flutter pub cache and Gradle wrapper to keep build times under roughly eight to twelve minutes.