Feature Toggle — basics, switch types, and application
Feature Toggle is a runtime mechanism for switching application functionality on and off, allowing developers to manage feature availability without changing code or redeploying. Unlike conditional compilation (ifdef), toggle works at the runtime level and can be changed dynamically. According to Martin Fowler (2024), feature toggles are a key element of trunk-based development and continuous delivery. Feature toggle gives teams flexibility in managing releases and experiments.
Key Takeaways
- Feature Toggle — a dynamic switch that controls application behavior through configuration
- Main types: business toggles, release toggles, experiment toggles, and infrastructure toggles
- Feature Toggle vs Flag — toggle usually refers to simple binary switches, flag — to full-fledged platforms
- CI/CD Integration enables automatic checking and testing of toggles at every pipeline stage
- Main problem — accumulation of stale toggles, which need to be regularly audited and removed
What is a Feature Toggle
Feature Toggle is a technique where new feature code is wrapped in a conditional statement that checks a configuration parameter value. If the parameter is true — the new functionality is active, if false — the old code runs. The key difference from a feature flag is that a toggle is a binary switch operating on an on/off principle, without complex targeting rules or traffic distribution.
Definition and How It Works
A feature toggle is implemented as a simple if-construct around new functionality. The toggle value is stored in the application configuration — environment variables, a JSON file, or a database. When the application starts, it loads the configuration and uses it to make decisions about feature visibility. In the simplest case, changing a toggle value requires restarting the application, but in production systems toggles usually support hot reload through an external config server or API.
Simple Toggle Example
Let’s look at a feature toggle implementation in JavaScript (Node.js). The toggle is stored in a JSON config and loaded when the server starts. Middleware checks the toggle value before routing the request to the new or old handler. This implementation allows adding new functionality to the main code branch without breaking the current API version.
js
const config = require("./config.json");
const toggles = {
get(name) {
return config.features[name] ?? false;
},
isEnabled(name, context) {
const toggle = config.features[name];
if (!toggle) return false;
if (toggle.enabled === true) return true;
if (toggle.percentage && context.userId) {
return hashCode(context.userId) % 100 < toggle.percentage;
}
return false;
}
};
const app = express();
app.use("/api/checkout", (req, res, next) => {
if (toggles.isEnabled("new_checkout", req)) {
return newCheckoutHandler(req, res);
}
return legacyCheckoutHandler(req, res);
});Types of Feature Toggles
Pete Hodgson from ThoughtWorks identifies three main types of feature toggles, classifying them by lifespan and purpose. Properly identifying the toggle type helps choose the right storage mechanism and management process. Let’s look at each type in the context of mobile development.
Business and Release Toggles
Business toggles are the longest-living switches. They manage business rules available only to certain user categories (premium features, regional specifics). Such toggles can live for years and usually have more complex logic than binary on/off. Release toggles are temporary switches for hiding incomplete functionality. Their lifecycle ranges from a few days to a few weeks. Once the functionality is complete, the release toggle is removed from code. These toggles are the foundation of trunk-based development, allowing developers to commit to the main branch without waiting for all functionality to be complete.
Experiment and Infrastructure Toggles
Experiment toggles are used for A/B testing and gradual rollout. Unlike release toggles, experiment toggles support percentage-based user distribution and integration with analytics systems. They can live longer than release toggles (up to several months) but must also be removed after the experiment concludes. Infrastructure toggles are switches for managing infrastructure changes: database migration, switching to a new API provider, changing caching algorithms. These toggles require special attention to testing, as their switching affects the stability of the entire service.
| Toggle Type | Duration | Audience | Example |
|---|---|---|---|
| Business | Months-years | By roles/regions | Premium features |
| Release | Days-weeks | Developers/QA | Incomplete screen |
| Experiment | Weeks-months | % of users | A/B interface test |
| Infrastructure | Days-weeks | Internal | DB migration |
Feature Toggle vs Feature Flag
Although the terms “feature toggle” and “feature flag” are often used interchangeably, there are conceptual differences between them. Understanding these differences helps choose the right tool for a specific task and avoid confusion in the team. Let’s look at the key differences and use cases for each approach.
Differences in Approach
Feature toggle is primarily a technical mechanism: a binary switch embedded in the application code. Toggle is managed through configuration and does not require external infrastructure. Feature flag is a broader concept that includes a management platform: UI for configuration, SDK for integration, usage monitoring, analytics, and auditing. Flags support complex targeting rules (by region, version, device), A/B experiments, and automatic removal. You could say that feature flag is the evolution of feature toggle: teams start with simple configuration switches and move to a specialized platform as they grow.
When a Toggle is Enough
For small teams and projects with a single service or monolith, simple configuration toggles are perfectly sufficient. If you have 5–10 developers and 1–2 active toggles at a time, an external platform would be overkill. Feature flag platforms (LaunchDarkly, Unleash) become necessary when the number of active flags exceeds 20–30, the team has 20+ developers, or fine-grained access control is needed for different user segments. For mobile applications, where client updates take days, feature flag platforms provide an additional advantage — the ability to change application behavior without publishing a new version.
Management Tools
The choice of a feature toggle management tool depends on team size, technology stack, and security requirements. Let’s look at options from simple configuration files to enterprise-grade management platforms, including open-source alternatives.
CI/CD Integration
Feature toggles should be first-class citizens of the CI/CD pipeline. At the build stage, the pipeline checks that all release toggles scheduled for removal in the current sprint are actually removed from the code. At the testing stage, matrix tests are run with different toggle combinations. At the deployment stage, the system automatically synchronizes toggle configuration with the production environment. Integration with PagerDuty or Opsgenie allows creating alerts when stale toggles are detected or when the allowed number of active toggles is exceeded.
Popular Solutions
For simple scenarios, a JSON config in Git with code review on changes is sufficient. A more advanced option is Togglz (Java) or Gofeature (Go) — libraries that add a minimal UI for toggle management. For production systems, Unleash (open-source) with SDKs for all languages and activation strategy support is recommended, or Flagsmith with built-in A/B testing. LaunchDarkly remains the standard for enterprise projects with high audit and compliance requirements. For mobile applications, all solutions provide native SDKs with caching and offline mode.
Technical Debt and Removal
Feature toggles are a double-edged tool. Without management discipline, they turn into technical debt that slows down development and increases code complexity. According to a CodeScene study (2024), 35–50% of codebases contain stale toggles — switches that remain in the code after the rollout is complete. Let’s look at strategies for preventing and eliminating such debt.
Removing Toggles
The process of removing a feature toggle consists of four steps. First: make sure the toggle is enabled for 100% of the audience or disabled for 0% (depending on which code branch should remain). Second: remove all conditional toggle checks from the code, leaving only the branch that should be the production behavior. Third: remove the toggle definition from the storage system (config, database, or platform). Fourth: run tests to confirm that the removal did not break functionality. Each toggle should have an owner and a planned removal date, recorded when the switch is created.
Audit Automation
Manual toggle auditing is inefficient at scales over 50 switches. Automation is built on three principles: CI checking (stale toggles block merge), monitoring (a dashboard showing each toggle’s age and status), alerts (notifying the owner if a toggle hasn’t been changed in N days). Static analysis tools (SonarQube, ESLint plugin) can detect toggles that are always on or always off in code — a clear sign of a stale toggle. The final check is code review, where the reviewer must verify that the new toggle is actually needed and the old code branch will be removed.
go
package toggles
type Toggle struct {
Name string
Enabled bool
Owner string
CreatedAt time.Time
TTL time.Duration
}
type ToggleManager struct {
store map[string]*Toggle
}
func NewToggleManager() *ToggleManager {
return &ToggleManager{store: make(map[string]*Toggle)}
}
func (m *ToggleManager) IsEnabled(name string) bool {
t, ok := m.store[name]
if !ok {
return false
}
return t.Enabled
}
func (m *ToggleManager) GetStaleToggles() []string {
var stale []string
for name, t := range m.store {
if t.Enabled && time.Since(t.CreatedAt) > t.TTL {
stale = append(stale, name)
}
}
return stale
}Frequently Asked Questions
How is a feature toggle different from a feature flag?
The terms are often used interchangeably, but technically feature toggle is a binary switch in code (an if-condition checking a config value). Feature flag is a broader concept that includes a management platform with UI, SDK, analytics, and complex targeting rules. A toggle does not require external infrastructure; a flag usually does.
How often should old toggles be removed?
Release toggles should be removed within 1–2 weeks after the rollout is complete. Experiment toggles — immediately after the A/B test concludes. Business toggles require regular auditing (quarterly). It is recommended to set up a CI check that blocks merging if a PR adds a new toggle without a removal task in the task tracker.
Can toggles be used for mobile applications?
Yes, feature toggles are actively used in mobile development. The main tool is Firebase Remote Config, which allows dynamically managing switches without publishing a new version of the application. Alternatives: LaunchDarkly SDK for iOS/Android, Unleash SDK, a custom toggle server with REST API. It is important to implement value caching for offline mode.
How to test code with feature toggles?
The main method is matrix testing: running all tests with the toggle both on and off. For N toggles, full matrix testing requires 2^n runs, so in practice critical combinations are selected. Unit tests should mock the toggle value. Integration tests check specific scenarios. A step is added to CI that runs tests with a random toggle combination to detect unexpected interactions.
What are the risks of feature toggles?
Main risks: 1) stale toggles — code with both branches (on/off) becomes complex and hard to maintain; 2) combinatorial testing complexity — each toggle doubles the number of states; 3) dead code — the old branch remains in code after the toggle is permanently enabled; 4) security — switches controlling access create vulnerabilities when misconfigured. All risks are manageable with discipline and automation.
Summary
- Feature Toggle — a binary functionality switch controlled through application configuration
- Main types: business (months-years), release (days-weeks), experiment (weeks-months), infrastructure (days-weeks)
- Feature Toggle vs Flag — toggle is simpler (if-condition + config), flag includes a full management platform
- CI/CD integration is mandatory: stale toggle checking, matrix tests, configuration synchronization
- Stale toggles — the main risk: 35–50% of codebases contain unused switches
- Toggle removal requires a process: confirm state, remove code, remove config, run tests
- Audit automation through CI, dashboards, and static code analysis prevents technical debt accumulation
We will develop a mobile application turnkey
IT Sectr creates iOS and Android applications for startups and businesses since 2017. We will advise you and propose the best solution.
Read also