Be careful when using Firebase Remote Config control for pre-announced feature

is an excellent tool that enables us to ship a feature hidden from the user, and get turned on at the designated time. However, if we are not careful, the hidden feature might be exposed without us knowing it. Read on how that happens. Firebase Remote Config Background Typical Flow As shown in diagram below, in normal convention, by default the Feature is turned OFF in Firebase. Hence the Feature is not seen in the App. As the Feature get turned on in Firebase, it will be visible to the Phone. Excellent! App get the Feature ON or OFF per the Firebase Remote Config Setting Caching Protection However, in reality, we would want to use the Firebase provided caching mechanism, to ensure user doesn’t get spammed with tans of Firebase Remote Config changes immediately if the changes occur more frequently than we desire. By default the cache expires after 12 hours Hence the behavior would be like the diagram below. This is still all good, as we have the Feature ON first, and the user only get to view them later. App only get the Feature ON after the cached value expired. Description of Problem However in reality, before we ship our product, we would like to perform end to end testing. Hence we turn on the Feature first, to ensure our Firebase Remote Config works accordingly. This inadvertently, post a risk, as the actual external user that uses the App at that time might be caching the value too, even though the feature is no available in the App yet. They can’t see it, but the value is cached. Upon shipping of the latest version of the App, when the user launch the App, since it is still retaining the ON value from the cache, the Feature in the app would be ON!! This is like a leak of your Feature known to the market place before actual time!! The App having the Cache ON value that was used for testing, and hence the hidden feature is now visible!! Resolution to the Problem To solve the problem, should be quite straightforward. We just need to turn OFF the Feature in Firebase, and leave it OFF for at least the minimum duration of the Cache, if not longer, before ship the App to the store. Product shipped after the Feature OFF longer than the Cache Time. More Problem to Take Note! If you’re thinking that’s all… Sorry, there’s another loophole. Assume we follow the convention described above, where we shipped the App after we have successfully turn OFF the Feature in Firebase, and waited longer than the Cache time. That’s all good. As we shipped, the user get the latest app automatically downloaded to his phone. But he has not launch the App, so no latest Firebase Remote Config value is fetched. He might have the cached value stored. Assuming at the time he launch the App, the Internet is Down; the Firebase Remote Config fetch would fail. This means the App would use the Cache value, which is ON. This also means this hidden feature will be fully visible (assuming this is an offline feature), as long as the internet is not back and the refetching is not happening!! Ouch!!! Sorry didn’t propose a solid solution here, as depends on the criticality of the feature’s visible state, the resolution would differs as well. This is just to make known t the risk pose, hence Firebase Remote Config need to be used with care. If your product is just too risky to be exposed before it’s announcement, maybe the safest approach is only ship your product after it is announced, as the famous saying. If you don’t want anyone to find out about it then don’t do it ~Chinese Proverbs~ If you like my post and want to get future update, follow me at or or medium Twitter Facebook