Firebase Remote Config gives teams a controlled way to change app behavior without tying every adjustment to a new release. This guide provides a repeatable workflow for defining parameters, setting safe defaults, fetching and activating values, targeting audiences, staging rollouts, validating results, and rolling back a faulty configuration.
Overview
Remote Config is most useful when the application already contains the code needed to support a behavior, but the product team needs to control that behavior remotely. Typical examples include enabling a new screen, changing a content limit, adjusting a timeout, changing promotional copy, or exposing a feature to a limited audience.
A Remote Config parameter does not replace application logic. The client still needs to define what happens for each value, provide a local fallback, and handle unavailable or malformed configuration safely. Treat each parameter as part of your app’s interface: give it a clear name, document its accepted values, and decide what the safest default should be before publishing it.
A practical release flow looks like this:
- Define the parameter and its contract.
- Add an in-app default for offline, first-run, and fetch-failure cases.
- Read the value through the platform’s Remote Config SDK.
- Fetch and activate according to the app’s startup and release requirements.
- Test the default and remotely supplied values.
- Target a narrow audience before expanding the rollout.
- Monitor behavior and revert the value if the change causes harm.
Keep configuration separate from secrets. Remote Config values can be delivered to clients, so do not use it for private keys, credentials, authorization decisions, or data that must remain confidential. Enforce access control with Firebase Authentication, backend checks, and Firebase Security Rules where appropriate. For a broader review of client and backend boundaries, see the Firebase Security Rules Testing Guide.
Checklist by scenario
Before creating a feature flag
- Write down the user-visible behavior controlled by the flag.
- Decide whether the flag is a release switch, experiment variable, operational safeguard, or long-term setting.
- Choose a safe default that works when the app cannot contact Firebase.
- Define an owner and an expected removal date for temporary flags.
- Confirm that the code path is shipped before enabling the flag remotely.
Use a boolean for a simple on/off decision, a number for bounded tuning, and a string only when the possible values are documented and validated in code. Avoid placing multiple unrelated decisions in one parameter; separate flags are easier to test and roll back.
Parameter-naming reference
| Pattern | Example | Use |
|---|---|---|
feature_<area>_enabled | feature_checkout_v2_enabled | Boolean release switch |
experiment_<name>_variant | experiment_search_variant | Named experiment branch |
limit_<area>_<metric> | limit_upload_mb | Numeric product or operational limit |
copy_<screen>_<key> | copy_paywall_headline | Remote text with a documented fallback |
ops_<service>_<setting> | ops_feed_page_size | Operational tuning value |
Choose one naming convention and apply it consistently across platforms. Names should describe intent, not implementation details that may become obsolete.
For a new feature rollout
- Ship the feature code with the flag disabled by default.
- Verify that the disabled path is complete, not merely hidden behind a UI condition.
- Set the Remote Config value for an internal test group or controlled audience.
- Check startup, navigation, analytics, error handling, and offline behavior.
- Increase exposure in deliberate stages rather than changing directly from zero to everyone.
- Record the configuration version, audience definition, test result, and owner.
For an experiment
Separate experiment assignment from experiment measurement. A Remote Config condition can expose a value to an audience, but your analytics implementation still needs to record which variant a user saw and which outcome occurred. Define the primary success measure, guardrail metrics, audience exclusions, and stopping criteria before activating the experiment.
Feature-flag decision matrix
| Need | Recommended approach | Important control |
|---|---|---|
| Hide unfinished code | Boolean flag with a disabled local default | Remove the flag after the release is stable |
| Gradual exposure | Condition-based audience or staged rollout | Monitor errors and business guardrails |
| Compare variants | Explicit variant parameter | Log assignment and outcome consistently |
| Emergency mitigation | Operational flag with a conservative fallback | Test the fallback before an incident |
| Permanent user preference | Persisted account or device setting | Do not use Remote Config as the source of truth |
For fetch and activation
Define when the app should fetch configuration and when new values should become active. Fetching at startup may provide fresh behavior but can add latency or depend on network availability. Fetching later can protect startup performance but may delay a rollout. Activation should be deliberate: applying a new value during a sensitive flow can produce inconsistent screens or user experiences.
Use the current Firebase SDK documentation for the exact method names and platform-specific behavior. In general, your implementation should distinguish among local defaults, previously activated values, a successful fetch, and a failed or throttled fetch. Test each state rather than assuming that every launch receives the latest template.
What to double-check
Defaults and value validation
Every parameter should have a local default that allows the app to remain usable. Validate numeric ranges, accepted enum values, URL formats, and text length before applying a remote value. If validation fails, use the known-safe default and log enough context to diagnose the problem without exposing user data.
Conditions and targeting
Review the order and scope of conditions before publishing. Confirm whether targeting is based on platform, app version, geography, audience membership, user properties, or another supported signal. Check that the test device or account actually qualifies. A condition that looks correct in the console can still produce an unexpected result when the client has stale values, missing analytics data, or a different app environment.
Environment separation
Keep development, staging, and production configuration distinguishable. Verify the Firebase project, bundle identifier or application identifier, and release build before changing a value. A short pre-publish check can prevent a test configuration from being applied to production or a production setting from being mistaken for a staging result.
Observability and rollback
Connect rollout decisions to the monitoring tools already used by the team. Crashlytics can help identify whether a newly enabled path is associated with crashes, while application analytics and logs can reveal performance or conversion changes. The Firebase Crashlytics Triage Guide is useful when a configuration change needs to be connected to a reproducible failure.
Before expanding an audience, confirm that the previous value can be restored quickly. Write down the rollback value and the person authorized to make the change. A rollback plan is incomplete if it depends on shipping a new app build.
Common mistakes
- Using Remote Config for secrets: Client-delivered values should be treated as discoverable. Keep credentials and security decisions on trusted backend systems.
- Forgetting the default path: Offline launches, first installs, cache misses, and failed fetches are normal states. They should not create a broken screen.
- Activating values at an unsafe time: A mid-session change can leave related screens using different assumptions. Choose activation points that the product can tolerate.
- Leaving temporary flags indefinitely: Every flag adds branches to the codebase and test matrix. Track removal work as part of the feature release.
- Changing several parameters without a record: Bundled changes make diagnosis and rollback harder. Record what changed, why, when, and for whom.
- Assuming a console update is immediate everywhere: Clients may not fetch or activate a new value at the same time. Test the expected propagation and document any relevant delay.
- Measuring only crashes: A rollout can reduce performance, alter engagement, or create support issues without producing a crash. Include product and operational signals.
When to revisit
Review this workflow before every significant feature launch, experiment, seasonal campaign, or operational change. Revisit it after Firebase SDK updates, changes to supported targeting capabilities, a new app architecture, or a change in how analytics audiences are defined. Platform and console workflows can evolve, so confirm method names, fetch behavior, limits, and targeting options against the current Firebase documentation before relying on a detail in production.
Use this release checklist before publishing a value:
- The parameter has a documented type, purpose, owner, and removal or review date.
- The app includes a tested local default and validates the remote value.
- The code is present in the target build and both enabled and disabled paths work.
- The intended Firebase project and application environment are confirmed.
- Conditions, audience exclusions, and test accounts have been checked.
- Fetch and activation behavior has been tested for online and offline states.
- Analytics, logs, Crashlytics, or other monitoring can identify rollout impact.
- The rollback value, decision owner, and communication path are documented.
Remote Config is safest when treated as a controlled deployment tool rather than a shortcut around release engineering. Pair small changes with explicit defaults, observable outcomes, and a short-lived flag lifecycle. For the surrounding deployment process, see the Firebase CI/CD and Deployment Guide.
