Flags & config
Flags & config in the Marketing area (Optimization) — route /marketing/flags-config.
Flags & config lives in the Marketing area of the dashboard, under Optimization.
At a glance#
| Dashboard route | /marketing/flags-config |
| Area | Marketing (marketing) |
| Group | Optimization |
| Platforms | Available for every app platform. |
What it does#
Flags & config is the runtime-configuration family under one tabbed shell — three separate backends, three tabs:
Feature flags — turn a feature on or off without shipping a release.
Rollouts & kill switches — release a feature to a percentage of users, and turn it off instantly if it goes wrong.
Remote config — values your app reads at runtime rather than compiling in.
When to use it#
Continuously, and the kill switch is the reason. Mobile releases take days to reach users and cannot be recalled: without a remote off-switch, a bug in a new feature is live until a new build propagates through a store review and a user update cycle. With one, it is off in seconds.
Every mobile feature of any size should ship behind a flag. That is not caution, it is the only rollback mechanism you have.
Workflow#
Ship the flag before the feature
A flag added in the same release as the feature it guards is a flag you cannot use if that release is the problem. Ship the flag first, default off.
Roll out in stages
1%, then 10%, then half, then everyone — checking crash rate and performance between steps. A problem found at 1% affects a hundredth as many people.
Verify the kill switch works before you need it
Turn it off once, deliberately, on a staging build. An untested kill switch is a hope.
Remove flags after full rollout
Every permanent flag is a branch in your code and a state combination nobody tests. Flag debt is real and compounds.
Permissions and prerequisites#
Requires the SDK's flag and remote-config support, and your code to actually respect the flag — see Feature flags.
Limits and edge cases#
Flag evaluation happens client-side, so there is a propagation delay determined by your SDK configuration.
Percentage rollouts must be stable per user, or users flip between behaviours between sessions.
Remote config values are strings and numbers, not code. They cannot change behaviour your app does not already support.
Three separate backends behind one shell; the tabs do not share state.
Troubleshooting#
Flipped a flag and nothing changed. Propagation delay, cached values, or a code path that does not check the flag. Check in that order.
Rollout percentage behaving inconsistently per user. Assignment is not stable — usually a bucketing key that changes between sessions.
Remote config value not applied. Confirm the app reads it at the point you expect rather than at launch only.
Where the data comes from#
Flags, rollouts and experiment assignment are all delivered in the SDK config payload.
From the SDK
Served by
SDK config
Experimentation