Реалізація Feature Toggles для управління функціональністю мобільного додатку
Feature toggle — механізм включення/вимкнення функціональності без нового релізу додатку. Звучить просто, доки не почнеш думати про версії клієнтів, кеширування флагів, graceful degradation при недоступності сервера та накопленому кладовищі мертвих флагів через рік.
Чому флаги потрібні в мобільному додатку
Trunk-based development. Розробник merge'їть незавершену функцію під флагом — 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 тестами, audit trails, 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 тижні.