Force Update in Flutter (Part 6): Firebase Remote Config

Force Update series: 1. Why you need it · 2. Upgrader · 3. Remote config intro · 4. force_update_helper · 5. GitHub Gist · 6. Firebase Remote Config · 7. Dart Shelf API

If the app already uses Firebase, Remote Config is my default home for required_version. Free tier, console UI, conditions, and no Gist rate limits.

Why Remote Config fits force update

• Change behavior without a store release
• In-app defaults so offline first-launch still has a value
• Optional conditions (platform, app version, audiences)
• Pairs cleanly with Analytics / Crashlytics you may already ship

Dashboard setup

1. Firebase console → Remote Config
2. Add parameter: required_version (String), default 1.0.0
3. Publish changes

For multi-flavor apps, use separate Firebase projects or RC conditions so staging can force-update without touching production.

Packages

flutter pub add firebase_core firebase_remote_config firebase_analytics

Initialize Firebase before reading config (same as any Firebase app).

Provider / service sketch

Future<FirebaseRemoteConfig> initRemoteConfig() async {
  final remoteConfig = FirebaseRemoteConfig.instance;

  await remoteConfig.setConfigSettings(RemoteConfigSettings(
    fetchTimeout: const Duration(seconds: 10),
    // Production: hours. Debug: minutes so you can test.
    minimumFetchInterval: kDebugMode
        ? const Duration(minutes: 5)
        : const Duration(hours: 1),
  ));

  await remoteConfig.setDefaults(const {
    'required_version': '1.0.0',
  });

  try {
    await remoteConfig.fetchAndActivate();
  } catch (e, st) {
    // log to Crashlytics; keep defaults / last activate
  }

  return remoteConfig;
}

Future<String> fetchRequiredVersion() async {
  final remoteConfig = FirebaseRemoteConfig.instance;
  return remoteConfig.getString('required_version');
}

Wire into force_update_helper:

ForceUpdateClient(
  fetchRequiredVersion: fetchRequiredVersion,
  iosAppStoreId: Env.appStoreId,
);

Fetch intervals (do not surprise yourself)

Firebase documents a default minimum fetch interval (historically 12 hours in some setups). If you raise required_version in the console and the app "does nothing," you are probably throttled.

• Debug: short interval or minimumFetchInterval: Duration.zero only in debug
• Release: 1 hour is a reasonable compromise for force-update urgency vs battery/network
• After a critical publish you can temporarily lower interval, ship a build, then raise it again

Testing without publishing a bad floor

1. Install a build with version 1.0.0
2. Set RC required_version to 2.0.0 → hard prompt expected
3. Set back to 1.0.0 → app opens
4. Confirm offline: defaults / last activated values still make sense

Never set production required_version above what stores actually serve.

Flavors and environments

Flavor	Firebase project	required_version purpose
dev	project-dev	Break things freely
stg	project-stg	QA force-update drills
prod	project-prod	Real users

Do not share one RC namespace for prod + experimental kill switches without conditions.

Summary

• Remote Config = production-grade home for required_version
• Always setDefaults + handle fetch failure
• Debug with short fetch intervals; release with sane throttling
• Next level of control: your own backend endpoint

← Previous Part 5: GitHub Gist
Next → Part 7: Dart Shelf API