What is a feature flag?
Used in a sentence: The new checkout is already in the build, so let's keep it behind a feature flag and open it to a small slice of users first.
How it works
Engineers wrap a feature in a condition: if the flag is on, run the new code path, otherwise run the old one. The code for both paths ships inside the app binary.
When the app starts, or at set intervals, the SDK fetches flag values from a flag service. Values can depend on user attributes such as app version, country, plan or a random bucket, so the same flag can be on for some users and off for others. The app caches the last known values so it still behaves predictably offline.
Changing a flag in the dashboard changes behaviour on the next fetch, with no build and no store review. Old flags should be removed once a feature is fully live, or the codebase fills up with dead branches.
Example
A payments app rebuilds its UPI checkout. The new flow ships in a release but stays behind a flag. The team turns it on for a small share of Android users and watches payment success and error rates. When a bank-specific bug appears, they switch the flag off for that segment within minutes while engineers fix it. Once metrics hold steady, they widen the rollout in stages until everyone has the new checkout.
Feature flag vs server-driven UI
| Feature flag | Server-driven UI | |
|---|---|---|
| What it changes | Whether shipped code runs | What UI the app renders |
| New screens without a release | No | Yes, within supported components |
| Typical owner | Engineering | Product and growth teams |
Flags toggle code you already shipped. Server-driven UI sends the layout and content from a server, so new screens can appear without a build. Many teams use both.
Best practices
- Give every flag an owner and a removal date when you create it.
- Roll out in stages and define the metric that would make you switch it off.
- Keep a kill switch on risky flows such as payments and login.
- Compare flagged users against a holdout group to measure real impact.
How to do this with Digia Engage
Feature flags and Digia solve different problems. Flags toggle code already in the app. Digia sends new in-app UI and campaigns, such as nudges, widgets and surveys, from a dashboard without a release, and offers server-driven UI for Flutter and Android through Digia Studio. Probo, for example, ships feature rollouts and in-app experiments without app store dependencies. For how flags fit a release process, read our guide to feature flags.
Frequently asked questions
- What are feature flags used for?
- Teams use them for staged rollouts, A/B tests, beta access for selected users, and kill switches that turn off a broken feature without a hotfix. They also let engineers merge unfinished work into the main branch safely, because the code stays dormant until the flag is turned on.
- What is the difference between a feature flag and remote config?
- A feature flag is usually a simple on or off decision about whether a feature runs. Remote config holds values the app reads, such as a colour, a copy string or a limit. Many tools offer both, and a flag is often just a boolean stored in remote config.
- Can feature flags replace app releases?
- No. A flag can only switch on code that is already in the shipped binary. A brand new screen, component or flow still needs a build and app store review first. Flags control when and for whom shipped code runs, not what code exists in the app.
Related terms
Read more
Part of the In-app engagement glossary.