Firebase Remote Config: what it is, parameters and how to manage remotely

What is Firebase Remote Config and how it works

Firebase Remote Config is a service that stores key-value pairs on the Firebase server side and delivers them to client devices on demand or on a schedule. Each parameter has a name (string), a value (string, number, boolean or JSON) and can be tied to conditions — rules that determine which value a particular user receives. Conditions can check the app version, device language, region, random percentage and many other attributes.

The Remote Config architecture is built on a push-pull model with pull priority. The client periodically requests current values from the server (by default every 12 hours). However, the developer can trigger immediate synchronization in code or through the Firebase console (the “Publish changes” button). After publishing changes, the server sends a push notification via Firebase Cloud Messaging, and the app, upon receiving it, can re-request the parameters.

Free tier Firebase Remote Config has no limits on the number of parameters or requests, which sets it apart from other Firebase services. The only limitation is that the response size must not exceed 800 KB (total for all parameters). This is more than enough for a typical scenario: most projects use 10–50 parameters, and their total volume rarely exceeds 100 KB.

How Remote Config determines which value to give to a user

The value selection mechanism is based on the priority of conditions. Each condition represents a rule (e.g., “iOS version > 15.0”). Remote Config checks conditions in order of their priority and returns the value of the first matching condition. If no condition matches, the default value is used. This mechanism allows you to create a hierarchy of rules: from the most specific to the most general.

Important: the order of conditions in the Firebase console matters. If two conditions can match one user simultaneously, the one higher in the list wins. It is recommended to place more specific conditions (e.g., for a specific app version) above general ones (e.g., “All iOS users”). Incorrect ordering can cause a targeted change to never be applied.

Caching and parameter time-to-live

By default Remote Config caches the values received from the server for 12 hours. This means that after publishing changes in the console, the app will see them no earlier than 12 hours later (or after the next explicit fetch call). The minimum caching time can be set via FirebaseRemoteConfigSettings(minimumFetchIntervalInSeconds: 3600) — for production, at least 1 hour is recommended to avoid excessive server requests and user data traffic.

For testing changes during development, use a minimum interval of 0 seconds: FirebaseRemoteConfigSettings(minimumFetchIntervalInSeconds: 0). In this mode, each fetch call will load current values from the server. It is important not to forget to revert to the production interval before release, otherwise every app launch will contact the server, increasing costs and battery consumption.

Parameters, conditions and user groups

A Remote Config parameter is a named variable that can take one of several values depending on conditions. Value types: string, number (double), boolean, JSON object (serialized string). JSON parameters are convenient for passing structured data without creating many separate parameters: for example, an object with app theme settings (primaryColor, backgroundColor, fontSize).

Conditions are logical rules that check user or device attributes: OS version (iOS, Android), app version, country, language, user audience (a property defined in code), random percentage (for A/B tests). Conditions can be combined using logical AND: for example, “app version >= 5.0” AND “country = Russia”. Each parameter can have an unlimited number of conditions, but in practice 2–5 are used.

For personalization, use user properties — attributes set in the application code via Firebase Analytics. For example, analytics.setUserProperty(“subscription_tier”, “premium”). Remote Config can check this property and deliver values specific to premium users. Personalization through Remote Config does not require creating conditions on the client side — all logic is concentrated in the cloud console.

User groups and segmentation

Remote Config supports two segmentation models: based on attributes (conditions) and based on Firebase Analytics properties (user properties). The first model is static: a condition checks a fixed attribute that does not change within a session or app version. The second model is dynamic: a property can be set at any time during app operation, allowing flexible user segmentation at runtime.

Important: to use user properties in Remote Config, Firebase Analytics must be integrated. This requirement stems from Remote Config receiving user data from the Analytics SDK. Without Analytics, Remote Config works only with device attributes (OS version, app version, country from IP). Personalization based on user behavior (e.g., “made 5 purchases”) is only available through Analytics.

Template Versioning

Remote Config template is the complete set of all parameters, conditions and their values. Firebase stores the template change history and allows rollback to any previous version within 90 days. Versioning is critically important: if after publishing changes an error is found (e.g., an incorrect parameter value breaks the UI), you can immediately rollback the template to a previous working version through the Firebase console.

Each template change (publication) creates a new version with a unique number. The Firebase console provides a change log with the time, user and description (if filled). It is recommended to always add a description to publications: “Enabled new feed for iOS 10% test group”. Without a description, in a month it will be impossible to remember what exactly was changed in version 42.

How to implement Remote Config in an application

Implementing Remote Config consists of three steps: initializing the SDK with settings (caching time), defining default parameters (values in case the server is unavailable) and the logic for applying the obtained values. Default parameters are a safety net in case the device cannot connect to Firebase (no internet, server unavailable). Without default values, the application will use null, which can lead to crashes.

Defining default values is done in two ways: programmatically via setDefaultsAsync or through an XML file. The programmatic approach is convenient for small projects: all values are set directly in code once at app startup. The file approach is preferable for projects with dozens of parameters: values are stored in resources and can be easily edited without recompilation. It is recommended to combine: basic settings in XML, and specific ones programmatically.

Asynchronicity is a key feature of the Remote Config SDK. The fetchAndActivate() method makes a request to the server in a background thread without blocking the UI. After loading completes, activation occurs — parameter values are updated in the application's memory. Use listeners or coroutines (in Android/Kotlin) to track completion. The user should not see UI “jumping” when parameters are updated — all changes should be applied smoothly.

Initialization with onComplete and listeners

On first launch, Remote Config SDK does not block application initialization. While synchronization is happening, the application uses default values. This means the user may see the old interface version on first launch, and after fetch completes — the new one. For critical parameters (e.g., serverUrl, on which operability depends), use synchronous activation with result waiting.

Recommended practice: display a loading screen with minimal delay if the application critically needs to get current parameters before displaying the first screen. On the loading screen, run fetchAndActivate with a 5-second timeout. If parameters are not loaded within 5 seconds, the application starts with default values. This prevents infinite waiting when there is no internet.

Working with JSON parameters

JSON parameters in Remote Config allow you to pass structured data as a single value. For example, a theme style object: {“primaryColor”: “#6200EE”, “borderRadius”: 8, “fontFamily”: “Roboto”}. On the client, JSON is parsed and applied to the UI. Advantages: one parameter instead of three, atomic update (all three fields update simultaneously), clean console. Disadvantage: difficulty reading in the Firebase console (JSON is displayed as a string).

Recommendation: use JSON parameters for groups of logically related values that are updated together (themes, screen configuration, network settings). For independent parameters (feature toggle, serverUrl), use separate string or boolean parameters — they are easier to read in the console and easier to track changes in template version history.

A/B testing with Remote Config

A/B testing is a built-in feature of Firebase Remote Config that allows you to split users into groups, set different parameter values for each group and measure the impact of changes on selected metrics. Unlike manual splitting through conditions with random_percent, integration with Firebase Analytics automatically collects statistics for each experimental group and shows the statistical significance of differences.

The A/B test process: the developer creates an experiment in the Firebase console (A/B Testing section), selects a Remote Config parameter, sets values for the control and test groups and defines the target metric (e.g., conversion rate or revenue). Firebase automatically distributes users to groups, collects data and after 2–4 weeks shows the result with p-value. The experiment can be stopped early if the result is conclusive.

Statistical significance is the key criterion for stopping an experiment. Firebase A/B Testing uses the Frequentist approach and shows p-value for each metric. The standard significance threshold is 0.05 (95% confidence probability). When this threshold is reached in favor of one of the groups, Firebase recommends stopping the experiment and applying the changes to all users. If significance is not reached after 4 weeks, the experiment is considered inconclusive.

Types of experiments

Firebase A/B Testing supports two types of experiments: classic A/B (comparison of two values of one parameter) and multivariate A/B/n (comparison of three or more values). Multivariate tests require more users to achieve statistical significance. It is recommended to use A/B/n only for parameters with 3–5 variants, where each variant is fundamentally different from the others.

Experiment duration depends on traffic volume: for apps with 1000 daily active users, the minimum duration is 2 weeks; for apps with 100,000 users, 3–5 days. Firebase automatically calculates the required time and warns if current traffic is insufficient to detect significant differences. Important: do not stop an experiment before the estimated time, even if the result seems obvious — this is the classic “peeking” error.

Metrics for A/B testing

Target metrics in Firebase A/B Testing are set based on Firebase Analytics events. Standard metrics are available: daily active users, revenue, conversion rate, retention, user engagement. You can also create a custom metric based on any Analytics event with additional parameters. For example, the metric “Percentage of users who reached the payment screen” is created from the screen_view event with the parameter screen_name = “payment”.

It is recommended to select one primary metric on which the decision about experiment success is based, and 2–3 secondary metrics for additional analysis. Selecting multiple primary metrics increases the risk of false positive results (multiple comparison problem). If the selected primary metric does not show a statistically significant improvement, the experiment is considered unsuccessful, even if secondary metrics improved.

Code examples for Remote Config in Kotlin

Let's look at Remote Config integration in an Android application in Kotlin. The examples include SDK initialization with custom caching time, retrieving parameters of different types, implementing an A/B condition on the client side and handling errors when the server is unavailable. All code runs in the main activity or Application class so that parameters are available from the very start of the application.

Before using, add the dependency: implementation(“com.google.firebase:firebase-config”) via Firebase BOM. Make sure Firebase Analytics is also connected, as Remote Config uses Analytics to pass user properties.

Initialization and retrieving parameters

The first example is basic Remote Config setup with a minimum fetch interval of 1 hour for production. The SDK is initialized in the Application class onCreate method. After fetchAndActivate, the value of the welcome_message parameter is checked, which can be changed remotely for the welcome screen.

class MainApp : Application() {

    override fun onCreate() {
        super.onCreate()
        val remoteConfig = Firebase.remoteConfig
        val settings = FirebaseRemoteConfigSettings.Builder()
            .setMinimumFetchIntervalInSeconds(3600)
            .build()

        remoteConfig.setConfigSettingsAsync(settings)
        remoteConfig.setDefaultsAsync(
            R.xml.remote_config_defaults
        )

        remoteConfig.fetchAndActivate()
            .addOnCompleteListener { task ->
                if (task.isSuccessful) {
                    val welcomeMsg = remoteConfig
                        .getString("welcome_message")
                    Log.d("RemoteConfig", welcomeMsg)
                }
            }
    }
}

In the example, setDefaultsAsync loads default values from the XML file res/xml/remote_config_defaults.xml. If fetch fails (no network, server unavailable), the application will use these values. The XML file contains the same parameter names as in the Firebase console: <entry key=“welcome_message”>Welcome!</entry>. It is recommended to always have default values for all Remote Config parameters.

Feature toggle with Remote Config

The second example is a feature toggle (feature flag). The new_checkout_enabled parameter is of boolean type. If true, the application shows the new checkout screen; if false, the old one. Feature toggle is the most popular Remote Config scenario: the change affects only one parameter, does not require logic modification and can be reverted instantly.

fun isFeatureEnabled(paramName: String): Boolean {
    return Firebase.remoteConfig
        .getBoolean(paramName)
}

// Usage in activity
if (isFeatureEnabled("new_checkout_enabled")) {
    navigateToNewCheckout()
} else {
    navigateToLegacyCheckout()
}

The isFeatureEnabled function encapsulates access to Remote Config and can be easily tested via mock. For feature toggles, it is recommended to use a naming convention: prefix feature_, ff_ or flag_ so that the parameter purpose is immediately clear in the Firebase console. Example: feature_new_onboarding, ff_dark_mode, flag_v3_api. Do not use flag parameters for enabling/disabling for more than 3 months — accumulation of dead flags complicates maintenance.

Retrieving JSON theme configuration

The third example is retrieving a JSON parameter with app theme settings. The app_theme parameter contains a JSON object with primaryColor, borderRadius and fontFamily. On the client, JSON is parsed using Gson or kotlinx.serialization, and the values are applied to the UI. This approach allows designers to change the app theme without developer involvement and without a release.

data class AppTheme(
    val primaryColor: String = "#6200EE",
    val borderRadius: Int = 8,
    val fontFamily: String = "Roboto"
)

fun getAppTheme(): AppTheme {
    val json = Firebase.remoteConfig
        .getString("app_theme")
    return Gson().fromJson(json, AppTheme::class.java)
}

Working with JSON requires care: if the JSON in the Firebase console is incorrect (e.g., a comma is missing), parsing will fail and the application will receive default values instead of the current theme. It is recommended to validate JSON strings before publication using a JSON validator. For production, add try-catch during parsing and log errors via Firebase Crashlytics.

Best practices and limitations

Firebase Remote Config is a powerful tool, but when used incorrectly it can lead to problems with performance, predictability of behavior and security. Let's look at key practices that will help avoid common mistakes when working with the service, and limitations to consider when designing application architecture.

Avoid sensitive data — Remote Config is not designed for storing secrets (API keys, tokens, passwords). All parameter values are accessible to client code and can be extracted from the application's memory. For confidential data, use Cloud Functions with server-side verification or Secret Manager. Store only public parameters in Remote Config: texts, flags, UI settings, public endpoint URLs.

Test every change before publishing to the entire audience. Use an A/B test or publish to a small percentage (1–5% of users) to verify that the new value does not cause crashes or break display. Remote Config does not have a staging environment — all changes are published to production immediately. The only way to safely publish is gradual rollout.

Platform limitations: maximum number of parameters — 2000 (for all types), maximum size of one value — 256 KB, total server response size — 800 KB. The number of user properties that can be used in Remote Config is limited to 25. The minimum fetch interval is 0 seconds (for debugging), but overuse can lead to exceeding the Cloud Functions quota (30,000 requests per minute per project).