Реализация Feature Toggles для управления функциональностью мобильного приложения
Feature toggle — механизм включения/отключения функциональности без нового релиза приложения. Звучит просто, до тех пор пока не начинаешь думать о версиях клиентов, кешировании флагов, graceful degradation при недоступности сервера и накопленном кладбище мёртвых флагов через год.
Зачем нужны флаги в мобильном приложении
Trunk-based development. Разработчик мержит незаконченную фичу в main под флагом — CI/CD работает нормально, QA не видит сырой код, в production он выключен. Долгоживущие feature-ветки с merge conflict'ами через три недели — прошлое.
Поэтапный rollout. Новая фича включается сначала для 1% пользователей → 10% → 50% → 100%. Если Crashlytics показывает рост крешей — флаг выключается мгновенно, без отзыва релиза.
A/B тесты. Одна кнопка зелёная, другая — синяя. Флаг с вариантами, аналитика показывает которая конвертит лучше.
Kill switch. Платёжный провайдер упал — выключаем платёжный экран, показываем заглушку. Без хотфикса и App Store Review.
Варианты реализации
Firebase Remote Config — стандарт де-факто для большинства мобильных приложений. Бесплатно, SDK для iOS/Android/Flutter/React Native, персонализация по user properties (страна, версия приложения, сегмент). Минус: не подходит для enterprise со строгими требованиями к хранению данных.
LaunchDarkly — enterprise-решение с targeting rules, A/B тестами, аудитом изменений, SSO. Дорого, но если у команды 50+ разработчиков и сотни флагов — оправдано.
Собственный сервис — когда нужен полный контроль или нельзя отправлять пользовательские данные на сторонние серверы. Go/Node/Laravel backend, PostgreSQL для хранения флагов, Redis для кеша, WebSocket или polling для обновлений в реальном времени.
Unleash — open source альтернатива LaunchDarkly, self-hosted. SDK для всех платформ, targeting, gradual rollout. Хороший баланс между функциональностью и контролем.
Техническая реализация на клиенте
Ключевое правило: флаги должны работать без сети. При первом запуске — дефолтные значения из бандла, при последующих — кешированные из UserDefaults/SharedPreferences, фоном обновляются с сервера.
iOS (Swift):
// FeatureFlagService с кешированием
actor FeatureFlagService {
private var flags: [String: Bool] = [:]
func isEnabled(_ flag: FeatureFlag) -> Bool {
flags[flag.rawValue] ?? flag.defaultValue
}
func refresh() async {
// Загружаем с Remote Config или собственного API
let fetched = await remoteConfigService.fetch()
flags = fetched
}
}
// Использование в SwiftUI
if featureFlagService.isEnabled(.newCheckoutFlow) {
NewCheckoutView()
} else {
LegacyCheckoutView()
}
Android (Kotlin): аналогично через StateFlow в ViewModel, чтобы UI реагировал на изменение флагов в реальном времени без перезапуска экрана.
Управление жизненным циклом флагов
Главная операционная проблема: флаги накапливаются. Через год в коде if (featureFlags.isEnabled("new_onboarding_v2_2023")) — это мёртвый флаг, который никто не выключит никогда, потому что непонятно чем он грозит. Код не читается, тесты не покрывают обе ветки.
Процесс: каждый флаг создаётся с плановой датой удаления (expires: 2024-06-01). После полного rollout — задача на удаление флага и ненужной ветки кода. Инструмент: ArchUnit (Android) или статический анализ (SwiftLint custom rule) для обнаружения expired флагов в CI.
Сроки: интеграция Firebase Remote Config + базовые флаги — 2–3 дня. Собственный feature-flag сервис с targeting, rollout, dashboard — 3–4 недели.