Firebase is back at Google I/O on May 10! Register now

Firebase Remote Config loading strategies

Stay organized with collections Save and categorize content based on your preferences.

Firebase Remote Config provides lots of flexibility for how and when to fetch new values from the server and activate them in your app, allowing you to ensure a quality end user experience by controlling the timing of any visible configuration changes. This guide looks at a few loading strategies and discusses key considerations for picking the best option for your app.

Strategy 1: Fetch and activate on load

In this strategy, your app would call fetchAndActivate() when your app first starts up to fetch new values from Remote Config and activate them as soon as they are done loading. This simple approach works well for configuration changes that don't cause any dramatic visual changes in your UI. It should be avoided in any situation where your UI could change noticeably while users are in the middle of using it.

Strategy 2: Activate behind loading screen

As a remedy to the potential UI issue encountered in strategy 1, you could rely on a loading screen. Instead of starting up your app right away, show a loading screen and call fetchAndActivate in your completion handler. Then right after that — again using a callback or a notification — dismiss the loading screen and allow the user to start interacting with your app.

If you use this strategy, it's recommended to add a timeout to the loading screen. Remote Config's one-minute timeout may be too long for a quality app startup experience for users.

Strategy 3: Load new values for next startup

An effective strategy is to load new configuration values to activate on your app's next startup. In this strategy, your app activates fetched values on startup before attempting to fetch new ones, operating on the assumption that it may have already fetched — but not yet activated — new configuration values. The order of operations for this strategy is:

  1. On startup, immediately activate previously fetched values. This applies any values you've downloaded from the server in a previous session, and is nearly instantaneous.
  2. While the user interacts with your app, kick off an asynchronous call to fetch new values according to the default minimum fetch interval.
  3. In the completion handler or callback for the fetch call, do nothing. Your app will keep the downloaded values until you activate them the next time the app starts.

With this strategy, user wait time is greatly minimized. However, the user must run your app a second time to see the latest configuration. You'll need to balance these considerations against your business and app logic.

Loading anti-strategies

As you may have understood from the above discussion of loading pros and cons, there are a couple of usage patterns to avoid.

  • Don't update or switch aspects of the UI while the user is viewing or interacting with it — unless you have strong app or business reasons for doing so, like removing options related to a promotion that has just ended.
  • Don't send mass numbers of simultaneous fetch requests, which could result in the server throttling your app. Risks of this happening are low in most production scenarios, but it can be an issue during active development. Check out the throttling guidance for Android and Apple platforms.
  • Don't rely on network connectivity to obtain Remote Config values. Do set in-app default parameter values so that your app always behaves as expected. You can periodically keep app and Remote Config backend default values in sync using downloaded template defaults.

Next steps

These three basic strategies do not by any means comprise a complete list of the ways to load configuration values. Depending on your needs, you could devise much more sophisticated strategies such as the function-driven background updates described in Propagate updates in real time.

Check out the API reference for your platform to learn more about the specific calls for fetching and activating configuration values.