Firebase Remote Config loading strategies

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.

Note: If you are loading values for an
A/B Testing experiment, this strategy
is very strongly recommended. With A/B Testing, additional time is required
as the user is placed into an experiment and the experimental values are applied.

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:

On startup, immediately call activateFetched(). This applies any values
you've downloaded from the server in a previous session, and is nearly instantaneous.

While the user interacts with your app, kick off an asynchronous call to fetch new values.

In the completion handler 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 iOS.

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.