Question 1

How do you release a Flutter app to the stores?

Accepted Answer

The sequence: (1) configuration — flavour and environment values, with the API endpoint passed via --dart-define; (2) versioning — the version and build number in pubspec.yaml, with the build number incremented for every upload; (3) signing — a keystore on Android, a certificate and provisioning profile on iOS, both kept out of the repo; (4) build — flutter build appbundle for Android, flutter build ipa for iOS; (5) upload — Play Console or App Store Connect, starting with an internal test track. I would raise the security point myself: --dart-define values live inside the binary, so real secrets stay on the backend.

Question 2

Why do you use flavours?

Accepted Answer

The main reason is practical: dev, staging and production can be installed side by side because each has its own application id. That is a real difference for a tester — you no longer uninstall production to check staging. The second benefit: each variant has its own name and icon, so accidentally testing against a production build becomes far less likely. Configuration — API endpoint, analytics key, log level — attaches to the flavour instead of accumulating if (isProduction) checks in code. One caveat: a flavour is a configuration mechanism, not a security one — secrets are still inside the binary.

Question 3

How would you set up CI/CD for a Flutter project?

Accepted Answer

I would split it into two speed tiers. On every PR, the fast checks: flutter analyze, flutter test (unit and widget) and a format check — a few minutes, so developer flow is not blocked. After merge or nightly: integration tests (which need an emulator), building artifacts, and automatic upload to an internal test track. On the release side: automatic version and build-number bumps, signing keys supplied as secrets, and changelog generation. I would also track artifact size — watching APK/IPA size and alerting on a jump is genuinely useful, because dependency-driven growth otherwise gets noticed far too late.

Question 4

Can behaviour differ between a debug and a release build?

Accepted Answer

Yes, and it is a genuine source of bugs. The differences: (1) assertions run only in debug — putting logic inside an assert silently disappears in release; (2) optimisation and tree shaking remove unused code, which can break reflection-like dynamic calls; (3) timing — release is faster, so race conditions hidden in debug can surface; (4) logging — debug prints are gone. The practical consequence: a release build must be verified on a real device; "it worked in debug" does not count as tested.

Concern	Android	iOS
Release artifact	App Bundle (`.aab`), recommended for the store	An IPA archive
Signing	A keystore plus `key.properties`, kept out of the repo	A certificate plus a provisioning profile
Configuration	`build.gradle` product flavours	Xcode schemes and configurations
Size reduction	`--split-per-abi` or App Bundle	The App Store thins the app itself

Build, flavours and release

📚 Sources and documentation