Remote Config: dynamic parameters for mobile apps without resubmission

You have a critical bug in your app: authorization is broken on iOS 17.2. The fix is ready in code, but the build goes through review for 2 days, and App Store takes another day. Dynamic Config disables the problematic feature in 10 minutes without a release. We've implemented it in 20+ projects with up to 10 million users: from fintech to marketplaces. In practice, a config service cuts reaction time for urgent changes from 3 days to 10 minutes — 432 times faster. Savings on hotfixes reach 90%, and release cycle costs are reduced by 30%. For example, in a project with 5 million users, proper configuration saved significant emergency fix expenses.

Remote Config delivers configuration parameters to a mobile app without updates via App Store or Google Play. Unlike Feature Toggles, which control turning features on/off, dynamic configuration handles numeric, string, and JSON parameters. For instance, a Feature Toggle enables a new feed algorithm, while Remote Config sets the number of posts (5, 10, 15) and text length. Our experience ensures you avoid typical pitfalls: exceeding the Firebase quota (10,000 fetches/day), incorrect defaults, or leaking sensitive data.

Remote Config: dynamic mobile app parameters — why and how?

Remote Config lets you change parameters without a release, critical for A/B tests, hotfixes, and adapting to different markets. Unlike Feature Toggles, it works with any data type: numbers, strings, JSON. This gives flexibility: you can change API limits, server URLs, texts, colors, and even entire UI blocks.

How to set up Firebase Remote Config?

Step 1. Integrate the SDK — dynamic remote config

iOS:

let remoteConfig = RemoteConfig.remoteConfig() let settings = RemoteConfigSettings() settings.minimumFetchInterval = isDebug ? 0 : 3600 remoteConfig.configSettings = settings 

Android (Kotlin):

val remoteConfig = Firebase.remoteConfig remoteConfig.setDefaultsAsync(R.xml.remote_config_defaults) 

Firebase documentation recommends a minimum fetch interval of 3600 seconds for production builds.

Step 2. Set default values

This is not optional. If Remote Config is unavailable (first launch without a network, Firebase outage), the app works with defaults. Without explicitly defined defaults, the SDK returns empty strings and zeros. api_timeout_seconds = 0 — every request immediately times out. Defaults on iOS are in RemoteConfigDefaults.plist, on Android in res/xml/remote_config_defaults.xml. When adding a new parameter, the default is added simultaneously.

Step 3. Fetch + Activate

remoteConfig.fetchAndActivate { status, error in let timeout = remoteConfig["api_timeout_seconds"].numberValue.intValue } 

remoteConfig.fetchAndActivate().addOnCompleteListener { task -> val maxRetries = remoteConfig.getLong("max_auth_retries").toInt() } 

How to avoid typical Remote Config mistakes?

Defaults are a safety net in case of network failure or server error. Store them in the repository and update them with the code. In one project, the client forgot to set a default for api_timeout_seconds — after the update all requests timed out. We fixed it in an hour, but lost 15% of active users. 100% of projects with Remote Config must have defaults for every parameter. Another common mistake is exceeding the Firebase quota: the free tier is 10,000 fetches per day. Increase the fetch interval to 12 hours in production, use caching (UserDefaults/SharedPreferences). For A/B tests, consider a custom server or a paid plan. Proper configuration saves up to 100,000 fetches per month (10% of the free plan quota).

Remote Config readiness checklist:

• All parameters have defaults
• Fetch interval set: production ≥ 3600 sec, debug = 0
• Client-side caching implemented
• Targeting conditions correct (version, country, percentage)
• Load testing performed (simulate offline)
• Documentation for adding new parameters

Conditions

Remote Config supports targeting by: app version, country/region, device language, random user percentage. This allows:

• Enable a new CDN endpoint only for European users
• Show a special configuration for beta testers (app version contains "beta")
• Gradually roll out a new feed algorithm to 10% of users

Comparison: Firebase Remote Config vs custom config service

Remote Config vs Feature Toggles: what's the difference?

In practice, they are combined: Feature Toggles enable a new module, Remote Config sets its configuration.

When is a custom Remote Config service needed?

Firebase isn't always suitable: you can't send user data to Google, you need custom targeting conditions, or require integration with a corporate IAM system. A minimal architecture includes an API endpoint GET /api/config?appVersion=X&platform=ios&region=eu, Redis for caching, PostgreSQL for storing parameters, and a webhook for instant invalidation. An admin UI lets non-technical staff change values. Contact us for an assessment — we'll select the optimal solution for your infrastructure.

What is included in Remote Config integration work

• Audit of current parameters and strategy selection (Firebase / custom)
• SDK setup, defaults, targeting conditions
• API development (if custom) and admin panel
• Deployment, monitoring, team training
• Documentation for adding new parameters
• 3‑month warranty on correct configuration operation

Get an individual Remote Config implementation plan tailored to your app. Request a consultation — we'll analyze your current configuration and suggest the best solution. Leave a request — we'll contact you within 24 hours to discuss details.