Conditional Feature Flags
How to use condition strings in code to enable or disable features
Be sure to read our Feature Flag Guide, which covers common Feature Flag implementations.
Feature flags are great way to enable new features, stage rollouts, and disable features that are end of life.
However, static flags and randomized rollout often aren't powerful enough. What happens if you find out your new feature has a bug on iPad, issues on cellular networks, or bugs in some locales? What if you want to target only long standing users initially to prevent data from new users clouding the results of AB test?
You can't think of every condition you might need ahead of time, but with our conditional checks you can used advanced targeting, and update your targeting after you ship.
checkNamedCondition API
This API is simple, but powerful. It evaluates a condition string, and returns if it's true or false.
The condition strings are defined in your config file, allowing you to update them remotely without app updates.
Be sure to provide a unique name to each use case. Don't reuse names even if the current conditional logic is equivalent; that will make it impossible to override each usage independently from your remote config file.
Parameters and Return Value
name
: A name for this condition. Must be provided and can not be an empty string. This name is used to look up the conditional string from your config file's named conditions.error
: Any errors returned from evaluating the condition.
Return Value
Returns the result of evaluating the condition. Always false for any error.
Remote updates
You can update your conditions anytime from the cloud. The config file format to do so is described here.
Advanced Usage
See our feature flag guide for tips on how to implement staged rollouts, rollback, and other feature flag strategies.
Last updated