Flutter App CI/CD using GitHub Actions

In modern Flutter development, CI/CD is no longer optional. Once it is set up properly:

• You no longer need to manually upload APK or IPA files
• App release time is significantly reduced
• Human errors during release are almost eliminated

In this article, we will explore the complete structure of using GitHub Actions to automatically upload a Flutter app to the Play Store and App Store.

What is CI/CD? (Simple Explanation)

CI (Continuous Integration) → Will automatically build + test after the developer pushes code to GitHub.

CD (Continuous Deployment / Delivery) → After a successful Build app will automatically upload to the store.

In Simple form: :- Code push → Build → Upload → Relax ☕️

Tools We Will Use

• Flutter
• GitHub Actions
• Fastlane
• Play Store Console
• App Store Connect

High Level Flow (One Look)

Developer
   ↓
GitHub (push main branch)
   ↓
GitHub Actions
   ↓
Flutter Build
   ↓
Fastlane
   ↓
Play Store / App Store

Project Folder Structure

flutter_project/
│
├── android/
├── ios/
├── lib/
│
├── fastlane/
│   ├── Fastfile
│   └── Appfile
│
├── .github/
│   └── workflows/
│       ├── android_release.yml
│       └── ios_release.yml
│
└── pubspec.yaml

👉 **.github/workflows** This forlder contains all the magic of GitHub Actions.

GitHub Secrets (Most Critical Part)

We wont set any Sensitive information inside code. For this GitHub provides Secrets. GOTO: GitHub Repo → Settings → Secrets and variables → Actions

We can organize the secrets like bellow, Android Secrets,

Secret Name                   Why needed
ANDROID_KEYSTORE_BASE64 App   signing
ANDROID_KEYSTORE_PASSWORD     Keystore unlock
ANDROID_KEY_ALIAS             Key identify
ANDROID_KEY_PASSWORD          Key password
PLAY_STORE_JSON_KEY           Play Store API access

The keystore file needs to be Base64 encoded and stored as a GitHub secret. iOS Secrets,

Secret Name                   Why needed
APP_STORE_CONNECT_API_KEY     App Store authentication
MATCH_PASSWORD                Certificate security
IOS_CERTIFICATE               Code signing

👉 iOS CI/CD always needs macOS runner।

Android CI/CD using GitHub Actions

.github/workflows/android_release.yml

name: Android Release

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: subosito/flutter-action@v2
        with:
          flutter-version: '3.22.0'

      - run: flutter pub get

      - run: flutter build appbundle

      - name: Upload to Play Store
        run: fastlane android release

on: push → main → Pipeline will start after code pushes to main branch.

ubuntu-latest → Android build can be done in Linux.

flutter build appbundle → Play Store requires .aab file

fastlane android release → Upload handled by Fastlane

iOS CI/CD using GitHub Actions

.github/workflows/ios_release.yml

name: iOS Release

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: macos-latest

    steps:
      - uses: actions/checkout@v4

      - uses: subosito/flutter-action@v2
        with:
          flutter-version: '3.22.0'

      - run: flutter pub get
      - run: flutter build ios --release --no-codesign

      - name: Upload to App Store
        run: fastlane ios release

Apple rules: iOS build must run on macOS GitHub provides macos-latest runner for this.

Fastlane Configuration (Heart of CI/CD)

fastlane/Fastfile

default_platform(:android)

platform :android do
  lane :release do
    upload_to_play_store(
      aab: "build/app/outputs/bundle/release/app-release.aab"
    )
  end
end

platform :ios do
  lane :release do
    build_app(
      scheme: "Runner"
    )
    upload_to_app_store
  end
end

So mainly, Lane = one automation task Android lane → upload .aab iOS lane → build + upload .ipa

Fastlane basically acts like: “Store upload expert robot”

App Versioning (Very Important)

pubspec.yaml

version: 1.0.4+5

• 1.0.4 → User visible version
• +5 → Internal build number

Full Release Process (Developer POV)

Code change git push origin main GitHub Action automatically runs Build success App uploaded to:

Play Store (Internal / Production)

App Store Connect

👉 No manual upload 👉 No APK drag-drop 👉 No stress

Common CI/CD Mistakes

❌ Build number not increased ❌ Wrong bundleId / applicationId ❌ Expired iOS certificate ❌ Keystore mismatch

These are the common issues where developers usually get stuck when setting up CI/CD for the first time. If you carefully recheck and fix these points, your CI/CD pipeline should run smoothly and reliably.

This article has been written in a very concise and easy-to-understand way. It is assumed that you have at least once or twice manually uploaded an app to the Play Store or App Store before.

Any confusion or something to ask, feel free to knock.