Short answer
By default the SDK fetches from Firebase at most once every 12 hours, and fetched values only apply after activate() (or fetchAndActivate()). For testing, set a low minimum fetch interval in a debug build only. For updates that should reach users quickly, add a real-time config update listener, which skips the fetch interval. Throttling errors mean the app fetched too often: fetch once per launch and listen for updates instead.
Rather not fix it yourself? App Fix Ticket starts with a fixed-price diagnosis, then a fixed price for the fix before any fix work.
Why the old value is still showing, and the fix
01
The 12-hour minimum fetch interval
“configs won't be fetched from the backend more than once in a 12 hour window, regardless of how many fetch calls are actually made.” Firebase, Get started with Remote Config (Android)
The default minimum fetch interval is 12 hours. Until it has passed, calling fetch again does not get new values from Firebase. During development, lower the interval in a debug build so you can see changes right away, and keep the default in the release build.
// Android (Kotlin): debug builds only val settings = remoteConfigSettings { minimumFetchIntervalInSeconds = if (BuildConfig.DEBUG) 0 else 43200 // 12 hours, the default } remoteConfig.setConfigSettingsAsync(settings)02
Fetched but never activated
“To make fetched parameter values available to your app, call the activate() method.” Firebase, Get started with Remote Config (Android)
fetch() downloads new values but the app keeps reading the old ones until activate() runs. Use fetchAndActivate() where an immediate change is fine, or activate on the next launch so the screen does not change under the user.
03
Fetching too often, so the SDK throttles
“If an app fetches too many times in a short time period, fetch calls are throttled and the SDK returns FirebaseRemoteConfigFetchThrottledException.” Firebase, Get started with Remote Config (Android)
A fetch on every screen, a retry loop, or a fetch interval of 0 shipped to many users can trip the limit, and the SDK returns a throttled error instead of new values. Fetch once per launch and listen for changes in real time.
04
No real-time listener for urgent changes
“Real-time updates bypass the minimum fetch interval setting.” Firebase, Remote Config loading strategies
If a change has to reach open apps quickly, such as switching off a broken feature, a real-time config update listener gets new values as soon as they are published, without waiting for the fetch interval. Activate the values in its callback.
Checked against the vendor’s docs on : Firebase docs: Get started with Remote Config (Android); Firebase docs: Get started with Remote Config (Apple platforms); Firebase docs: Remote Config loading strategies.
Rather hand it over?
Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.
- from $450App Fix TicketOne reproducible bug in an existing mobile or web app, diagnosed and fixed.See scope and start
- from $450AI-Built App RescueA Lovable, Bolt or Cursor app checked end to end in 3 days, then its worst problems fixed at a fixed price.No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way. This applies to the first 10 Launch Checks bought after October 30, 2026.See scope and start
“Very responsive, attentive to fixing bugs, and completed the project as needed! Thank you!”
Related: Firebase “No Firebase App [DEFAULT]” · Firebase App Check blocking requests · Firestore client is offline · FCM QUOTA_EXCEEDED