Feature Flags

How flags work

Feature flags are fetched as part of the bootstrap snapshot when the SDK initialises. They are cached locally and evaluated entirely client-side — no network call is made when you check a flag at runtime.

Flags are updated in the background on a configurable polling interval. Changes made in the dashboard reach your users within one polling cycle — default 60 seconds.

Check a flag

// Simple boolean check
final showNewUI = Koolbase.flags['new_checkout'] == true;

// In a widget
Widget build(BuildContext context) {
  if (Koolbase.flags['new_onboarding'] == true) {
    return const NewOnboardingFlow();
  }
  return const LegacyOnboardingFlow();
}

Get all flags

// Get the full flag map
final flags = Koolbase.flags;

// Iterate all flags
flags.forEach((key, value) {
  print('$key: $value');
});

// Check with a default fallback
final isEnabled = Koolbase.flags['feature_name'] ?? false;

Percentage rollouts

From the dashboard, set a rollout percentage on any flag — e.g. 25% means only 25% of your users see the flag as enabled. Bucketing is deterministic based on a hash of the device identifier, so a user always gets the same result across sessions.

To gradually roll out a feature: start at 5%, monitor for errors, then increase to 25%, 50%, 100%. To roll back, set the flag to 0% or toggle it off.

Kill switch pattern

Wrap any risky feature in a flag so you can disable it instantly if something goes wrong in production — no hotfix or App Store submission required:

// Wrap risky features in a flag
Future<void> processPayment(PaymentDetails details) async {
  if (Koolbase.flags['new_payment_flow'] != true) {
    // Fall back to the old flow
    return legacyProcessPayment(details);
  }

  // New payment flow
  return newProcessPayment(details);
}

Creating flags in the dashboard