Changing an app's behavior, prices, text, limits, toggles, from a server, without shipping a new version. Vital on mobile.
Why it exists
Some behavior needs to change after an app is already on users' phones, where you cannot deploy new code quickly and app-store review is too slow to flip a value. Remote config exists to control chosen settings from the server, so you can adjust behavior live without shipping a new build.
How it actually works
Some values you want to change without a release: a promotional price, a piece of copy, a feature toggle. Remote config keeps these on a server the app reads at startup or on the fly, so you change them centrally and every app updates without an app-store release.
This matters most on mobile, where a normal change waits days for app-store review and depends on users updating. Remote config sidesteps that entirely for the values you've made remote.
A senior PM walks you through it
A junior PM, stuck
Marketing wants tomorrow's Kacchi promo price live in the app that people already have installed, without waiting days for app-store review. The dev said "that's remote config, it's fine," and I nodded, but I genuinely cannot picture how a price changes on someone's phone without them updating the app. I do not want to promise marketing something I cannot explain.
You can promise it, and here is the picture. The installed app does not hardcode certain values; it asks a server for them each time it opens. Change the value on the server and every phone picks it up on the next fetch, no new build, no review. I captured the same call the app makes, once this morning and once after ops edits the promo price. The two responses are the whole trick.
GET /api/remote-config, before and after the promo edit
This morning, before the edit
11.1
2
31.1200
4{
5"banner_text":"Order your daily tiffin",
6"kacchi_promo_price":null,
7"delivery_fee":60
8}
This afternoon, after ops edits one value
91.1
10
111.1200
12{
13"banner_text":"Friday Kacchi promo now on",
14"kacchi_promo_price":699,
15"delivery_fee":60
16}
Click a step to see the lines it points at.
Mistakes I've seen
Promising marketing you can change any value live. Only the values built to be remote can move without a release. Check what is actually wired to remote config before you commit to a same-day change.
Confusing this with pushing an app update. A remote-config change touches a server value; users get it on the next fetch with no download. An app update goes through store review and depends on people updating.
Deciding remote-configurability too late. It has to be built in during design. Realizing after launch that the promo price is hardcoded is exactly the days-long delay remote config was meant to avoid.
Making everything remote to be safe. Every remote value is one more thing that can be changed by mistake in production. Make the values you will actually need to move remote, and leave the rest in the build.
Tell marketing: "The promo price is remote config, so we can set it on the server and every installed app picks it up on the next open, no app-store wait." Then confirm with the dev that the specific value is wired that way. You read the before and after and know what remote config can and cannot do. That is the lever.
Where a PM meets this
It's how you change a price or a message on mobile today instead of next week; a direct lever on your ability to react.
Deciding which values are remote-configurable is a product decision made during design; you can't remotely change what wasn't built to be remote.
Hear it in a meeting
"The banner text is remote-config, we can update it without a release."