What Are Remote Config and Feature Flags?
Remote Config lets you change your app's behavior and appearance without requiring users to download an update. Feature flags extend this concept by enabling or disabling specific features for targeted user segments.
Together, they give you a server-side control panel for your mobile app. This is critical because mobile app updates go through store review (1-7 days), require users to update (many do not), and cannot be rolled back once published.
Why Every Mobile App Needs This
Consider these scenarios where remote config saves the day:
- A new feature causes crashes on Samsung devices - toggle it off instantly
- Your holiday promotion needs to start at exactly midnight across all time zones
- You want to test two different onboarding flows to see which converts better
- A third-party API changes its endpoint URL and your app hardcodes it
Without remote config, each of these scenarios requires a new app build, store review, and user update cycle that takes days or weeks.
Popular Platforms
Firebase Remote Config
The most common choice due to its free pricing and Firebase ecosystem integration. Supports default values, conditional targeting, and A/B testing. Targeting by country, language, app version, user property, and random percentile.
LaunchDarkly
Enterprise-grade feature management with real-time flag updates via streaming (no polling delay), multi-environment support, and audit logs for regulated industries. Starts at ~$10/seat/month.
Statsig
Feature flags combined with product experimentation and analytics. Automatic statistical analysis of feature impact on metrics. Free tier includes 1M events and unlimited flags.
Implementation Patterns
The Fetch-Activate Pattern
Most remote config SDKs follow a two-step process: Fetch new values from the server, then Activate them. This separation prevents UI flickering. Fetch on app launch, then activate on the next session or at a natural transition point.
Default Values
Always define default values in your app code for every remote config key. This ensures your app works correctly when the user has no internet, the server is unreachable, or a new config key has not been published yet.
Targeting Strategies
| Strategy | Use Case | Example |
|---|---|---|
| Percentage rollout | Gradual feature launch | Enable for 10%, then 25%, 50%, 100% |
| User segment | Beta testers, premium users | Show new design to premium subscribers |
| Geography | Region-specific features | Enable payment method X in Europe only |
| App version | Version-gated features | Enable widget for v3.2+ only |
| Device type | Platform-specific tweaks | Different layout for tablets |
A/B Testing with Feature Flags
Feature flags are the delivery mechanism for A/B tests in mobile apps:
- Create a feature flag with multiple variants (control, treatment A, treatment B)
- Randomly assign users to variants based on percentage
- Track relevant metrics (conversion, retention, revenue) for each variant
- Analyze results after reaching statistical significance
- Roll out the winning variant to 100%
Best Practices
- Name flags descriptively - Use names like enable_new_checkout_flow, not flag_42
- Clean up stale flags - Remove flags that have been at 100% for more than 30 days
- Log flag evaluations - Track which variant each user sees for debugging
- Set cache expiration wisely - 12 hours for stable configs, 1 hour for active experiments
- Test flag-off states - Ensure your app works correctly when every flag is disabled
Pitfalls to Avoid
- Do not use remote config for values that must be available instantly at cold launch (splash screen colors, initial route). Fetched values are only available after the first successful fetch.
- Do not create flags for every minor change. Reserve them for risky features, experiments, and values that genuinely need server-side control.
- Do not forget offline users. Your app must behave sensibly with only default values.