Feature Requests: Support for Matrix Builds in Codemagic for Parallel Build & Release

[paix26875]

Use case

I need to build and release multiple variants of my Flutter application, such as different flavors, branding variations, or environment-based builds (e.g., dev, staging, production).

Currently, Codemagic does not support matrix builds, which forces me to:

- Manually define separate workflows for each variant, leading to duplicate YAML code.
- Run builds sequentially, increasing the overall CI/CD duration.
- Use custom scripting or API-triggered workflows, which adds complexity and maintenance overhead.

If Codemagic supported matrix builds, I could define multiple build configurations dynamically, allowing them to be executed in parallel and improving CI/CD efficiency.

Idea

Introduce matrix builds in codemagic.yaml, allowing developers to specify multiple variants to be built and released concurrently.

Example: Matrix Build for Flutter Flavors


workflows:
  build-and-release:
    matrix:
      flavor: [dev, staging, production, clientA, clientB]
    environment:
      flutter: stable
    scripts:
      - name: Build APK
        script: flutter build apk --flavor $flavor
      - name: Build iOS
        script: flutter build ios --flavor $flavor
    publishing:
      google_play:
        credentials: $GCLOUD_SERVICE_ACCOUNT
        track: $flavor
      app_store:
        api_key: $APP_STORE_API_KEY


This setup would:
✅ Build and release all specified flavors in parallel, reducing overall pipeline time.
✅ Eliminate redundant workflow definitions, making configurations easier to maintain.
✅ Provide a scalable solution, not just for Flutter flavors but for any type of build variations.

Even if matrix builds support OS-level variations, my primary need is for building multiple variants of the same OS efficiently. This feature would significantly enhance Codemagic’s build and release automation, making it more suitable for applications requiring multiple variant releases.

[opanitch]

I'd prefer be able to define tasks to be performed in parallel that you can pass configurable VARs to like in Concourse. That could also solve your issue. Either way, more parallelization please!