Using Firebase Remote Config For Dynamic Apps
When we build a mobile app with ambition, one of our primary goals is adaptability— we want to be able to customise our app’s behaviours and appearance very smoothly. Sometimes, we may decide to try out a new UI design, or to build new features for selected user groups. This is why we must think carefully of how we setup configurations within our app; they will dictate how our app looks and behaves, so the process of updating and utilising them should be as least painful as possible.
Typically, we can bake app parameters in the source code as constants, store them in shared preferences, config files or in a local database, or manage them in our backend server. But sometimes our customisation needs grow as our app grows in features and audience. Fortunately, there are modern, accessible approaches that allow more than basic app configuration.
As a primary example, Firebase Remote Config, while basically being key-value pairs at its core, has the extra advantages of dynamic updates (as the name implies, parameters can be changed remotely) and targeting capabilities (thanks to its integration with Google Analytics). If we aim for our app to be unquestionably flexible, it’s a solution definitely worth looking into.
The official tutorial is comprehensive enough to get started with implementing Remote Config, so we won’t jump into that. This article rather illustrates different ways of structuring parameters to take advantage of its capabilities. Let’s get straight to them!
As resources
The official sample app provided by Firebase shows a basic implementation of Remote Config, with simple string and boolean values for displaying text in the app.
Likewise, you may store resources or links to resources — i.e. string keys, image URLs — directly in Remote Config. This can be useful when you want to test different text variants or display seasonal images, for example.
As you can see, Firebase has the capability of setting different values depending on certain conditions such as the user’s language or country, or even the time the config values are fetched.
As constants
Constants that you would typically store in the source code can be easily migrated to Remote Config. Doing so will allow you to conduct experiments with your app behaviour, like trying out different threshold values until you find what gives you the best results.
In a sample taken from Healint’s migraine recording app, we specify how many migraine attacks a user must record before showing them an ‘Are you enjoying this app?’ pop-up. Some time later, with the help of our analytic tools, we might realise that we ask our users for feedback too early or too late in their journey. To adjust the number of minimum records required, we can easily update the value in the Remote Config console — no need for an app update!
As feature flags
One of the main purposes of using remote configurations is for toggling features dynamically, like when rolling out a new feature for a percentage of users at a time or when enabling features to only a specific group in your audience. The A/B testing and the conditional value capabilities of Remote Config makes this very doable.
Extra: Advanced configurations
There are instances when simple String/Boolean/Double/Long values are not enough for your app’s logic. There could also be parameters that are not suitable to be stored as conditional values, due to Remote Config not being designed for 100% real time fetching and updating — in this case, you may want feature flags to be stored like constant values. Thankfully, Remote Config has good JSON support. Let me give you a quick example.
If you want to enable a certain feature depending on the device locale, and want to reflect the changes immediately when a user switches their phone language, you can define a parameter like this:
The app can then check against this list of supported languages every time the app is opened, and behave accordingly.
If you otherwise structured the parameter to be a Boolean value which returns
trueif the User Language condition is met, the expected app behaviour or appearance won’t reflect when a user changes their device language until 1) their Google Analytics User Language attribute is updated and 2) the new, appropriate remote configurations are fetched and activated.
Going back to the constants example, another advanced example is using JSON to define constant values per language:
The official documentation also provides an example of managing complex app configurations.
The takeaway
Firebase Remote Config is one of many ways to set app parameters. While it has its fair share of limitations, hopefully this article was able to show you that it’s a service that lets you be creative with how you apply customisations in your apps. There may be more than one possible way to structure an app configuration, and thanks to the convenience of remote parameters, you can make experiments and try out your options until you find what works best for your app and audience.
