Skip to main content

Flutter Env

Overview​

Flutterのenvについてまとめているセクション。

Flutterプロジェクトにおける環境切り替え方法の歴史とベストプラクティス​

Flutterプロジェクトにおける 環境（dev / staging / prod）の切り替え方法の歴史と、Flutter 3.32.1 現在のベストプラクティス を以下に体系的にまとめます。

Flutterバージョン環境切り替え方法備考
〜3.16dart-define-from-file便利だが非公式動作あり
3.19以降--dart-define に一本化JSONファイルからの読み込みは制限あり
3.32.1 現在--dart-define + EnvConfig クラス + CI連携最も安定した構成

歴史 Flutterにおける環境分けの進化​

初期：コード分岐で手動対応（〜Flutter 2系）

  • bool kReleaseMode などで debug/release を切り替え。
  • main_dev.dart, main_prod.dart などエントリーポイントを分けて対応。
  • const 定数を書き換えて運用 → 誤配布リスクが高かった。

発展：--dart-define によるビルド時注入（Flutter 2.2〜）

  • flutter build や flutter run で --dart-define を渡す方式が主流に。
  • String.fromEnvironment() を使って、定数を切り替えられるように。
  • CI/CD連携が容易になり、ステージングの自動ビルドが普及。

モダン：dart-define-from-file の登場（Flutter 3.6〜3.16）

  • JSONファイルに環境定義をまとめられる拡張方式。
  • 複数の --dart-define を一括管理可能に。
  • ただし Flutter 3.19 以降では iOS/Androidでは無効 になったため注意が必要。
caution

廃止：Flutter 3.19での dart-define-from-file 制限
CLI上では動作するが、Android/iOSビルドでは反映されなくなった。
理由：内部の dart-define と仕様が一致していなかったため。

Flutter 3.32.1におけるベストプラクティス（2025年最新）​

Flutter 3.32.1 での安定運用に適した構成は次のとおり。

1. --dart-define によるビルドパラメータ注入​

各環境で異なる値（API URL、Feature Flagなど）をビルド時に明示する。

flutter run --dart-define=FLAVOR=staging --dart-define=API_URL=<https://stg.api.example.com>

const flavor = String.fromEnvironment('FLAVOR');
const apiUrl = String.fromEnvironment('API_URL');

2. EnvConfig クラスによる整理​

class EnvConfig {
  final String name;
  final String apiBaseUrl;

  const EnvConfig._(this.name, this.apiBaseUrl);

  static EnvConfig fromFlavor(String flavor) {
    switch (flavor) {
      case 'dev':
        return EnvConfig._('dev', '<https://dev.api.example.com>');
      case 'staging':
        return EnvConfig._('stg', '<https://stg.api.example.com>');
      case 'prod':
        return EnvConfig._('prd', '<https://api.example.com>');
      default:
        throw Exception('Unknown flavor');
    }
  }
}

3. flavor-specific entry point（任意）​

複雑な初期化が必要な場合は main_dev.dart などで分岐。

flutter run -t lib/main_staging.dart --dart-define=FLAVOR=staging

4. ネイティブ側との連携（Flavors）​

Androidは build.gradle にて productFlavors を設定し、パッケージ名・アイコン・アプリ名を切り替え。

productFlavors {
    dev {
        applicationIdSuffix ".dev"
    }
    staging {
        applicationIdSuffix ".stg"
    }
    prod {
        // 本番
    }
}

iOSはXcodeの「Scheme」「Build Configuration」「xcconfig」で環境を分離。

運用上のTips​

項目推奨手法
複数環境管理make や melos でビルドスクリプト作成
CI/CD連携GitHub Actions や Bitrise で --dart-define を使い分け
.envファイル的な使い方env.yaml や .env.dart のようなローカル定義を使う（ただしGit管理しない）

はい、Flutterで--dart-defineとenviedパッケージを組み合わせて環境変数を管理する方法について解説している日本語の記事がいくつかあります。 

⸻

🔐 enviedパッケージの概要

enviedは、Flutterアプリケーションで環境変数を安全に管理するためのパッケージです。 .envファイルに定義した環境変数をビルド時にDartコードに埋め込むことで、ランタイムでのファイル読み込みを不要にし、セキュリティを向上させます。 また、obfuscate: trueオプションを使用することで、生成されるコード内の値を難読化できます。 

⸻

⚙️ --dart-defineとの組み合わせ

--dart-defineは、Flutterのビルド時に環境変数を注入するためのオプションです。 これを使用することで、異なるビルド環境（開発、ステージング、本番など）ごとに異なる設定を適用できます。 enviedと組み合わせることで、以下のような構成が可能です： 

  1. .envファイルを作成し、環境ごとの変数を定義
  2. enviedを使用して、.envファイルからDartコードを自動生成
  3. ビルド時に--dart-defineを使用して、必要な環境変数を注入 

この組み合わせにより、環境ごとの設定を安全かつ効率的に管理できます。()

⸻

📚 参考記事 • AichiLogでは、enviedパッケージを使用して環境変数を安全に管理する方法を詳しく解説しています。 .envファイルの作成から、Dartコードの自動生成、環境変数の使用方法まで、ステップバイステップで説明されています。   • TechTechMediaでは、APIキーなどの秘匿情報をenviedで安全に管理する方法について紹介しています。 obfuscate: trueオプションを使用した難読化の方法や、ビルド時の設定についても触れられています。 

⸻

これらの記事を参考にすることで、Flutterアプリケーションでの環境変数管理をより安全かつ効率的に行うことができます。 

Last updated on