Flutter Runtime Environments

A tested cold-start pattern for selecting API and native-backed service configuration before a Flutter application renders its first frame.

Why this exists

Changing an API URL is not enough when an application also uses Firebase Auth, push notifications, social login, analytics, or crash reporting. Those services must agree on one environment, and many must initialize exactly once during startup.

This example demonstrates:

• one typed source for API and service configuration,
• loading persisted state before runApp,
• a production-safe default when switching is disabled,
• build-controlled access to the environment selector,
• a full-restart contract for native-backed services,
• unit and widget tests for startup ordering and persistence.

Run

The default build is locked to production:

flutter run

Enable the selector for a controlled QA build:

flutter run --dart-define=ALLOW_ENVIRONMENT_SWITCH=true

After saving a different environment, fully close and reopen the application. The next launch reads the selection before initializing service adapters.

Verify

dart format --output=none --set-exit-if-changed .
flutter analyze
flutter test
flutter build web --dart-define=ALLOW_ENVIRONMENT_SWITCH=true

Firebase and native configuration

The project uses a service adapter rather than shipping credentials. Native service boundaries documents the exact point where Firebase.initializeApp(options: ...) belongs and explains why Google Sign-In, Apple Sign-In, APNs, URL schemes, and Android resources still need native preparation.

This repository contains no production identifiers, signing material, or proprietary application code.

License

MIT