Feature Toggles у мобільному додатку: реалізація та управління
Martin Fowler: "Feature toggle is a technique that allows you to turn features on and off without deploying new code."
Feature toggle — механізм увімкнення/вимкнення функціональності без нового релізу додатка (див. Feature Toggle). Звучить просто, доки не починаєш думати про версії клієнтів, кешування прапорців, graceful degradation при недоступності сервера та накопичене кладовище мертвих прапорців через рік. Саме тут більшість команд роблять критичні помилки, які ведуть до tech debt і падіння продуктивності.
Ми впроваджуємо прапорці в мобільні проекти вже понад 6 років — за цей час реалізували системи для 50+ додатків, від стартапів до enterprise з мільйонами користувачів. Наш досвід показує, що правильна архітектура прапорців скорочує час на реліз на 30% і знижує кількість критичних багів у production на 40%. Середня економія бюджету на тестування становить 30%. Надаємо гарантію на працездатність системи прапорців протягом 6 місяців після впровадження.
За нашим досвідом: кейс фінансового додатка
Один із наших клієнтів, мобільний банк, запускав новий платіжний потік. Без прапорців команда боялася релізити через ризик багів. Ми впровадили систему з двома прапорцями: перший — поетапний rollout (10% → 50% → 100%), другий — kill switch для платіжного модуля. На етапі 10% ми виявили критичний баг у розрахунку комісії — прапорець був вимкнений за 30 секунд, без шкоди для користувачів. Фінальний rollout відбувся без інцидентів, час на реліз скоротився з 2 тижнів до 2 днів.
Які завдання вирішують прапорці?
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+ розробників і сотні прапорців — виправдано. Firebase Remote Config налаштовується в 3 рази швидше, ніж LaunchDarkly, але LaunchDarkly в 5 разів надійніший для enterprise з точки зору compliance.
Власний сервіс — коли потрібен повний контроль або не можна відправляти користувацькі дані на сторонні сервери. Go/Node/Laravel backend, PostgreSQL для зберігання прапорців, Redis для кешу, WebSocket або polling для оновлень у реальному часі.
Unleash — open source альтернатива LaunchDarkly, self-hosted. SDK для всіх платформ, targeting, gradual rollout. Хороший баланс між функціональністю та контролем.
| Інструмент | Безкоштовно | Enterprise-функції | Self-hosted |
|---|---|---|---|
| Firebase Remote Config | Так | Ні | Ні |
| LaunchDarkly | Тріал | Так | Ні |
| Unleash | Частково | Так (через платні плагіни) | Так |
| Власний сервіс | Залежить | Повний контроль | Так |
Як ми впроваджуємо feature toggles: процес роботи
- Аудит поточної архітектури: визначаємо, які прапорці потрібні (rollout, kill switch, A/B).
- Вибір інструменту: оцінюємо Firebase Remote Config, LaunchDarkly, Unleash або власний сервіс.
- Проектування категорій прапорців, default values, ймовірностей rollout.
- Інтеграція SDK на клієнті та сервері, реалізація кешування.
- Написання тестів і документації, навчання команди.
Переваги feature toggles над feature-гілками
Порівняємо: довгоживуча гілка живе 3-4 тижні — за цей час main іде на 5 комітів із конфліктами. Feature toggle мержиться за день, конфліктів немає, код завжди актуальний. За нашим досвідом, команди, які використовують trunk-based з прапорцями, випускають релізи в 2 рази частіше. Кількість merge conflict'ів знижується на 80%.
Технічна реалізація на клієнті
Ключове правило: прапорці повинні працювати без мережі. При першому запуску — дефолтні значення з бандла, при наступних — кешовані з 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")) — це мертвий прапорець, який ніхто не вимкне, бо незрозуміло, чим він загрожує. Код не читається, тести не покривають обидві гілки.
Процес: кожен прапорець створюється з плановою датою видалення (наприклад, через 90 днів після rollout). Після повного rollout — задача на видалення прапорця та непотрібної гілки коду. Інструмент: ArchUnit (Android) або статичний аналіз (SwiftLint custom rule) для виявлення expired прапорців у CI.
Що робити, якщо сервер прапорців недоступний?
Ми використовуємо дворівневе кешування: на старті додаток бере прапорці з бандла, потім завантажує з Remote Config і зберігає локально. Якщо сервер недоступний — прапорець залишається актуальним до наступного успішного запиту. Graceful degradation реалізується через defaultValue, при якому вимикаються некритичні фічі, а критичний функціонал працює в стабільному режимі.
Додаткова перевага
Порівняння: Firebase Remote Config vs LaunchDarkly
Firebase Remote Config налаштовується в 3 рази швидше, ніж LaunchDarkly, але LaunchDarkly в 5 разів надійніший для enterprise з точки зору compliance. Вибір залежить від масштабу: для 10 розробників достатньо Firebase, для 100 — LaunchDarkly.Що входить у роботу
- Аудит поточної архітектури мобільного додатка
- Проектування системи прапорців (категоризація, default values, ймовірності rollout)
- Налаштування бекенду (Firebase, LaunchDarkly, Unleash або власний сервіс)
- Інтеграція SDK на клієнті (iOS/Android/Cross-platform)
- Написання unit-тестів та UI-тестів під прапорці
- Документація щодо додавання нових прапорців та їх життєвого циклу
- Навчання команди роботі з прапорцями
- Підтримка протягом 2 місяців після впровадження
| Процес | Термін |
|---|---|
| Інтеграція Firebase Remote Config | 2–3 дні |
| Власний feature-flag сервіс | 3–4 тижні |
| Міграція з гілок на прапорці | 1–2 тижні |
Терміни: від 2 днів до 4 тижнів залежно від складності. Вартість впровадження — від $500 до $5000. Наприклад, впровадження Firebase Remote Config обходиться в $0 додаткових витрат, окрім часу розробників.
Зв'яжіться з нами для аудиту вашого проекту — ми допоможемо налаштувати гнучке управління функціями без зайвих ризиків. Отримайте консультацію інженера з 6+ річним досвідом у мобільній розробці. Запишіться на безкоштовний розбір вашої системи прапорців.