firebase
RemoteConfig ignores missing defaults plists
Description
If you point RemoteConfig at a plist file and that file isn't found at runtime, RemoteConfig logs an error to console, but doesn't throw.
Then all attempts to read with configValue(forKey) just return default primitive values, e.g. 0 for numbers. That's very dangerous if you're using this for example to set a minimum time before something is deleted, or to configure the frequency with some operation can happen.
A refactor at any time could cause the plist file to fail to be found, which could then easily go unnoticed if the things that depend on remote config aren't immediate and obvious.
A method that throws or even panics would be preferable.
The whole API seems a bit dangerous. Setting the defaults in bulk when you initialize RemoteConfig, rather than at the call site forces you define the key multiple times, which introduces a not insignificant risk that you either forget to set the default or mistype the key name somewhere. I'd prefer a configValue(forKey: <>, withDefault: <>) method over setDefaults so that I'm guaranteed the ability to set a reasonable default value. Then the worst case scenario is that I use my sane hard coded default instead of my better remote default. Today the worst case seems to be I end up using a risky primitive default value.
Reproducing the issue
Point remote config at non-existent file via https://firebase.google.com/docs/remote-config/get-started?platform=ios#rest_2
Firebase SDK Version
10.29.0
Xcode Version
15.0.1
Installation Method
Swift Package Manager
Firebase Product(s)
Remote Config
Targeted Platforms
iOS
Relevant Log Output
No response
If using Swift Package Manager, the project's Package.resolved
Expand Package.resolved snippet
Replace this line with the contents of your Package.resolved.
If using CocoaPods, the project's Podfile.lock
Expand Podfile.lock snippet
Replace this line with the contents of your Podfile.lock!
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
Thanks for your feedback, @sjudd. I tried to incorrectly set the default plist, and I was able to get the same behavior you encountered. I get that the SDK should handle the missing default plist well or provide a failsafe default value to prevent unexpected app behavior. I'll raise this to our engineers and see what we can do here.
