App releases · 13 Nov 2026 · 5 min read
Feature flags and staged rollouts for apps, explained
Two simple ideas let you release an app update without betting everything on it: switch features on gradually, and send the update to a few users first.
The short answer
A feature flag is a setting that turns a feature on or off without a new app release. A staged rollout sends a new app version to a small share of users first, then more as it proves stable. Used together they let you spot problems early, limit the number of people affected and reverse some changes quickly.
What is a feature flag?
Feature flags are switches. The code for a feature is shipped inside the app, but a setting, usually held on a server, decides whether the user sees it. Change the setting and the behaviour changes, without waiting for a new version to be approved and installed.
A simple example: a new checkout screen is built and shipped in version five of an app, but switched off. The team turns it on for staff, then for a small share of customers, then for everyone. If it causes errors, they turn it off again.
Flags can be for everyone, for a percentage of users, for a country, for a device type or for named test accounts. Which options you need depends on your product. A small app may need only an on and off switch.
A flag needs somewhere to be stored and a way for the app to read it. That is usually part of the server side described in what an app backend does, or a separate configuration service.
What is a staged rollout?
A staged rollout is a feature of the app stores, not of your code. You release a new version to a share of users first and widen it over time.
Apple calls its version a phased release. According to Apple's help pages, it spreads an update across a period using a fixed schedule, applies to users with automatic updates turned on, and can be paused. Users can still update by hand at any time. Google Play's staged rollout lets you choose the percentage of users who receive the update, and you raise it yourself. You can halt a rollout, and users who already have the version stay on it. Google notes that staged rollouts are for updates, not for an app's first publication.
The two stores behave differently, and the details change, so check the current documentation before you plan a launch around them.
How do these reduce launch risk?
Both approaches limit how many people a mistake reaches and how long it lasts. They work at different levels.
| Feature flag | Staged rollout | |
|---|---|---|
| What it controls | A feature inside the app | Which users get a new app version |
| Where it lives | Your code and a server setting | The app store console |
| Speed of change | Can be near instant for users who are online | Depends on the store and the user installing the update |
| Reversal | Switch the feature off | Halt the rollout, but those who updated keep the version |
| Best for | New or risky features, tests, regional launches | Catching crashes and install problems early |
The key difference is reversal. Once a version is on a user's phone, a store halt does not remove it. A flag can switch a broken feature off for people already on the new version, as long as the code that reads the flag is itself sound. So the most useful setup is both: roll out gradually, and put risky features behind flags.
What to watch during a rollout
A staged release helps only if you look at the results. Decide what you will watch, and who will watch it, before you start.
- Crash and error rates for the new version compared with the old one.
- Launch and sign-in success.
- Key actions, such as completed orders or sent messages.
- Support messages and new store reviews.
This depends on having measurement in place. The guide on what to track in app analytics lists what is worth recording. Agree beforehand what result would make you pause: for example, a rise in crashes or a drop in completed purchases. Without a stated trigger, it is easy to keep going while worried.
Plan communication as well. If support will be asked about a new feature seen by only some users, give them a line to use. A matching line in the update note helps; see how to write app release notes.
Limits and costs you should know about
These tools are not free of trade-offs.
- Flags add code paths. Every flag doubles the cases to test, and old flags left in place make the code harder to understand. Remove a flag once the feature is settled.
- A flag read from a server needs a fallback if the server cannot be reached. Decide what the app does by default.
- Flags are not a security measure. Do not hide anything sensitive behind a flag in the app code; a user could still find it.
- Different users see different things, which complicates support and testing. Keep a record of who has which flag on.
- A staged rollout slows the arrival of fixes for those not yet included, and some users want the update at once.
- Neither replaces testing. They reduce the damage from mistakes that get through.
Stores still review your submission. A feature hidden behind a flag has to be explained honestly to the reviewer if it could change the app's behaviour in a way they should know about. The reasons stores refuse updates are listed in why apps get rejected from app stores. Check each store's rules about changing features after review.
Do small apps need this?
Often not at first. A small app with a few hundred users can ship carefully, test well and fix problems quickly. A staged rollout is cheap to use because it is a console setting, so it is worth turning on for most updates. Flags become more useful when the app has many users, several people working on it, or features you want to try on a few people first.
A good middle path: use staged rollouts from the first update, and add a simple flag system when you first have a feature you are nervous about. Plan this as part of your release process, described in the mobile app development process from idea to launch.
Support inside the app
When you try something on a part of your audience, people will ask why their screen looks different. Having a route for questions helps; see in-app support and feedback forms. If you want a team to set up the release process, the mobile app development service at Liftup Technologies covers builds and releases, and the right level of tooling depends on your app and budget.
Related guides
- Mobile app development
- Mobile app development process from idea to launch
- In-App Support: Help Centres and Feedback Forms
- App Release Notes: How to Write Them for Users
- App localisation basics
- Mobile app accessibility basics
Questions and answers
What is a feature flag?
A feature flag is a setting that turns a feature on or off without a new app release. The code ships in the app, and a setting, often on a server, decides who sees it.
What is a staged rollout?
A staged rollout releases a new app version to a share of users first and widens it over time. Apple calls it a phased release, and Google Play lets you choose and raise the percentage yourself.
How do these reduce launch risk?
They limit how many people a mistake reaches. A staged rollout catches crashes and install problems early. A flag lets you switch a risky feature off for people who already have the update.
Can I reverse a staged rollout?
You can pause or halt it, which stops more users receiving the version. People who already installed it keep it, so a fix needs a new version or a feature flag.
Do small apps need feature flags?
Not always. Use staged rollouts from the first update because they are a console setting. Add flags when you have a feature you want to test on a few people or are unsure about.
Tell us what you are building.
A short call, a written plan and a fixed quote. No obligation.