Forem: Mambaur Roziq

Setting Up Flutter CI/CD with GitHub Actions and Firebase App Distribution Securely

Mambaur Roziq — Mon, 30 Jun 2025 04:02:28 +0000

Automating Flutter app build and distribution saves time, enforces consistency, and enables rapid delivery to testers and users. This guide will help you set up a secure Flutter CI/CD pipeline using GitHub Actions and Firebase App Distribution while keeping sensitive files like keystores and environment files out of your repository.

Why Automate Flutter CI/CD?

Building and distributing manually introduces inconsistency, human error, and repetitive overhead, especially when working in teams or maintaining frequent updates. By using CI/CD:

You automatically build release APK/AAB files on each push or pull request.
Builds are consistent across environments.
You can distribute builds to testers automatically via Firebase App Distribution.
You keep sensitive files secure and out of version control.

Files You Should Not Commit to Git

To keep your app secure, the following files should remain out of your repository:

.env files containing API keys or environment configurations.
android/app/upload-keystore.jks or any keystore used for signing.
android/key.properties containing keystore passwords and paths.
google-services.json and GoogleService-Info.plist (optional but recommended).

Managing Sensitive Files with GitHub Secrets

Since GitHub Actions cannot access files ignored by Git, we use GitHub Secrets and base64 encoding to handle these files securely during CI/CD.

To add GitHub Secrets for your Flutter CI/CD, go to your repository on GitHub, click Settings at the top, then select Secrets and variables in the left sidebar under the Security section. Choose the Actions tab and click New repository secret.

Storing `.env`

Copy your entire .env file content and save it under ENV_FILE in your GitHub Secrets.

In your workflow:

- name: Generate .env file
  run: |
    echo "${{ secrets.ENV_FILE }}" > .env

Handling `key.properties`

Save your key.properties content to a secret named KEY_PROPERTIES. Ensure the storeFile path matches where you will place your keystore during CI/CD. For example:

storePassword=your_store_password
keyPassword=your_key_password
keyAlias=your_key_alias
storeFile=your-keystore.jks

Generate it in your workflow:

- name: Generate key.properties
  run: |
    echo "${{ secrets.KEY_PROPERTIES }}" > android/key.properties

Managing the Keystore File

Since GitHub Secrets do not accept files, convert your keystore to base64 on your local machine:

base64 upload-keystore.jks > upload-keystore.jks.base64

Copy the output and save it in GitHub Secrets as KEYSTORE_BASE64.

In your workflow, decode it before the build step:

- name: Decode keystore
  run: |
    echo "${{ secrets.KEYSTORE_BASE64 }}" | base64 --decode > android/app/your-keystore.jks

Firebase Configuration

Generate a Firebase CI token using:

firebase login:ci

Store it in GitHub Secrets as FIREBASE_TOKEN.

Writing Your GitHub Actions Workflow

Create a workflow file, for example:

.github/workflows/flutter-firebase-distribution.yml

name: Build & Distribute Flutter App

on:
  workflow_dispatch:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  build:
    name: Build and distribute Android
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source
        uses: actions/checkout@v4

      - name: Set up Flutter
        uses: subosito/flutter-action@v2
        with:
          channel: stable

      - name: Generate .env file
        run: |
          echo "${{ secrets.ENV_FILE }}" > .env

      - name: Generate key.properties
        run: |
          echo "${{ secrets.KEY_PROPERTIES }}" > android/key.properties

      - name: Decode keystore
        run: |
          echo "${{ secrets.KEYSTORE_BASE64 }}" | base64 --decode > android/app/your-keystore.jks

      - name: Install dependencies
        run: flutter pub get

      - name: Build APK
        run: flutter build apk --release

      - name: Install Firebase CLI
        run: npm install -g firebase-tools

      - name: Upload to Firebase App Distribution
        run: |
          firebase appdistribution:distribute build/app/outputs/flutter-apk/app-release.apk \
            --app <App ID> \
            --release-notes "Automated build from GitHub Actions" \
            --groups "tester-group"
        env:
          FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}

This workflow automates building and distributing your Flutter app using GitHub Actions.

on defines when the workflow runs. Here, it triggers manually (workflow_dispatch), on every push to main, and when a pull request targets main.
jobs contains the tasks the workflow will run. Here, there is a single job named build.
build runs on ubuntu-latest and handles the Flutter build and distribution process.
steps are the tasks executed in order:

Checkout your repository code.
Set up Flutter using the stable channel.
Generate the .env and key.properties files from GitHub Secrets.
Decode your keystore for signing.
Install dependencies with flutter pub get.
Build a release APK.
Install the Firebase CLI.
Upload the APK to Firebase App Distribution for testers.

This workflow ensures that every push or pull request to main automatically builds your Flutter app and distributes it to your testers without manual intervention.

How to Start and Monitor Your Flutter CI/CD

To start your Flutter CI/CD pipeline, you can trigger the workflow automatically by pushing commits to the main branch or by creating or updating a pull request targeting main. You can also run it manually using the “Run workflow” button in the Actions tab on your GitHub repository, which uses workflow_dispatch.

Once triggered, GitHub Actions will automatically start building your Flutter app, following the steps defined in your workflow file. You can monitor the progress and logs of each step in real time by going to the Actions tab in your repository, selecting the running workflow, and expanding the job and steps to see detailed output for debugging or confirming successful builds and distribution. This allows you to ensure your Flutter app builds consistently and is distributed automatically without manual steps each time you update your code.

Summary

Setting up a secure Flutter CI/CD pipeline using GitHub Actions and Firebase App Distribution involves:

Keeping sensitive files out of your repository.
Managing secrets securely using GitHub Secrets and base64 encoding.
Automating build, test, and distribution processes.
Providing consistent, reliable builds to your testers automatically.
Once set up, you will save hours of manual work and ensure your Flutter app delivery process is robust, secure, and scalable.

Dio vs HTTP in Flutter: A Practical, Clear Comparison

Mambaur Roziq — Sat, 28 Jun 2025 05:47:23 +0000

When building Flutter applications that interact with APIs, two of the most commonly used packages are http and dio. Both allow you to perform HTTP requests and handle responses, but they serve different needs and offer different levels of flexibility and scalability depending on the complexity of your application.

This article will help you understand why you may want to use dio over http in Flutter, what benefits dio brings to real-world applications, and what trade-offs you should consider.

Understanding http in Flutter

The http package is a lightweight and minimalistic HTTP client for Flutter and Dart. It is straightforward to use for making GET, POST, PUT, and DELETE requests. However, it is a low-level package, providing only the basic building blocks for network communication without advanced features.

For example, fetching data from an API using http looks like this:

final response = await http.get(Uri.parse('https://api.example.com/data'));
if (response.statusCode == 200) {
  final data = jsonDecode(response.body);
  print(data);
}

You must manually handle JSON decoding, error management, and token handling. While this is acceptable for small, simple applications, it can lead to repetitive code and higher maintenance in more complex projects.

Understanding dio in Flutter

dio is a feature-rich HTTP client designed for scalability and ease of use in real-world Flutter applications. It comes with advanced capabilities out of the box, including automatic JSON decoding, request and response interceptors, file uploads and downloads with progress reporting, request cancellation, and flexible configuration options like base URLs and global headers.

Fetching the same data with dio looks like this:

final dio = Dio();
final response = await dio.get('https://api.example.com/data');
print(response.data);

Here, dio automatically decodes the JSON response, simplifying your code and reducing the risk of repetitive parsing logic scattered across your project.

Key Benefits of Using dio Over http

Automatic JSON Decoding

With http, you are responsible for decoding JSON from the response body manually using jsonDecode. dio, on the other hand, automatically decodes JSON responses and makes the data directly accessible, reducing boilerplate and potential decoding errors throughout your codebase.

import 'package:dio/dio.dart';

final dio = Dio();
final response = await dio.get('https://jsonplaceholder.typicode.com/posts/1');

print(response.data['title']);

Global Configuration Support

In dio, you can configure a base URL, default headers, connection and receive timeouts, and other settings globally. This removes the need to configure these settings in every request, ensuring consistency and reducing duplication in your networking code.

final dio = Dio(BaseOptions(
  baseUrl: 'https://api.example.com',
  connectTimeout: Duration(seconds: 10),
  headers: {'Authorization': 'Bearer YOUR_TOKEN'},
));

With http, such configurations need to be handled manually on each request, increasing boilerplate and potential inconsistencies in headers or timeouts across your requests.

Interceptors for Request and Response Handling

dio offers interceptors, which allow you to inspect, modify, or handle requests, responses, and errors globally before they reach your app logic. This is particularly useful for adding authentication tokens automatically, logging requests and responses for debugging, or handling specific status codes (such as redirecting users to a login page on 401 Unauthorized errors) without duplicating code.

While http does not have built-in support for interceptors, achieving similar functionality requires wrapping your request logic in custom methods, which increases complexity and reduces clarity.

final dio = Dio();

dio.interceptors.add(InterceptorsWrapper(
  onRequest: (options, handler) {
    options.headers['Authorization'] = 'Bearer token123';
    print('Requesting: ${options.uri}');
    return handler.next(options);
  },
  onResponse: (response, handler) {
    print('Received: ${response.statusCode}');
    return handler.next(response);
  },
  onError: (error, handler) {
    print('Error: ${error.message}');
    return handler.next(error);
  },
));

await dio.get('https://jsonplaceholder.typicode.com/posts/1');

Built-in Support for File Uploads

Uploading files with dio is straightforward using its FormData API, which simplifies multipart form uploads:

FormData formData = FormData.fromMap({
  'file': await MultipartFile.fromFile(file.path),
});
await dio.post('/upload', data: formData);

In contrast, using http for file uploads requires managing MultipartRequest, which is more verbose and less intuitive, especially when handling multiple files or fields.

Downloading Files with Progress Reporting

In applications where you need to download files and display download progress to users, dio offers built-in support for tracking progress during downloads. You can easily update progress indicators in your UI using the progress callback provided by dio.

Using http for downloading files requires handling streams manually, which can be complex and error-prone for beginners and increases the amount of code you need to maintain.

await dio.download(
  'https://speed.hetzner.de/100MB.bin',
  '/local/path/100MB.bin',
  onReceiveProgress: (received, total) {
    if (total != -1) {
      print('${(received / total * 100).toStringAsFixed(0)}% downloaded');
    }
  },
);

Request Cancellation

dio allows you to cancel an ongoing request using a CancelToken. This is particularly useful in Flutter apps where a user may navigate away from a screen before a request completes, allowing you to save resources and prevent unnecessary UI updates.

In contrast, http does not support canceling requests once they have been initiated, which can lead to wasted network calls and memory usage in your app.

CancelToken cancelToken = CancelToken();

dio.get(
  'https://jsonplaceholder.typicode.com/posts',
  cancelToken: cancelToken,
);

// To cancel:
cancelToken.cancel('Request cancelled by user.');

Error Handling with Structured Information

dio provides a structured DioError object that gives you detailed information about what went wrong in your request, including the error type, the request that caused the error, and any available response data. This enables more effective error handling and user feedback in your app.

http provides basic exception handling, and you often need to parse error responses manually to extract meaningful error information.

try {
  await dio.get('https://api.example.com/data');
} on DioError catch (e) {
  if (e.type == DioExceptionType.connectionTimeout) {
    print('Connection timed out');
  } else if (e.response?.statusCode == 404) {
    print('Data not found');
  } else {
    print('Other error: ${e.message}');
  }
}

Performance Considerations

The http package is slightly faster than dio in raw network calls because it has fewer abstractions and less overhead. However, in real-world applications, this difference is negligible, as the network latency itself dominates the total request time.

The trade-off of slightly lower raw performance with dio is often acceptable considering the significant gains in developer productivity, code maintainability, and scalability for larger applications.

When Should You Use `http`?

When you are building a small app with minimal API requests.
When you want a lightweight dependency with the smallest possible app size.
When you do not need advanced features like file uploads, downloads, interceptors, or cancellation.

When Should You Use `dio`?

When your app requires user authentication and token management across many requests.
When your app involves file uploads or downloads with progress reporting.
When you need structured, centralized error handling.
When you want scalable, clean network architecture for a project that will grow over time.
When you prefer automatic JSON decoding and global configuration to reduce repetitive code.

Final Thoughts

Choosing between http and dio in Flutter depends on your application's current and future needs. While http is an excellent choice for simple applications that only require a few API requests, dio provides a powerful, scalable, and developer-friendly solution for apps that require advanced networking capabilities and clean architecture.

If you are building a production-ready Flutter application that needs to handle complex API interactions, token management, file uploads, downloads with progress, or centralized error handling, using dio will make your code cleaner, easier to maintain, and more scalable as your app grows.

If you would like, I can also prepare a ready-to-use dio_service.dart structure to help you set up a clean, scalable networking layer in your Flutter project.