Налаштування Flavor/Scheme для версій мобільного застосунку

Уявіть: ваш фінтех-стартап випускає white-label застосунок для трьох банків. У кожного — свій дизайн, свій API endpoint, свій бандл. При цьому QA потрібно тестувати staging без ризику зачепити production дані. Без правильної налаштування Flavors/Schemes ви отримаєте плутанину з package name та неможливість встановити дві версії поряд. Ми вирішуємо це завдання за 2–5 днів, використовуючи Product Flavors (Android), Schemes/Targets (iOS) та конфігурації Flutter. Виконали понад 30 проектів — від фінтеху до b2b-white-label. Гарантуємо, що після налаштування ви зможете встановлювати всі версії одночасно на один пристрій, не боячись конфліктів.

Як налаштувати Flavors на різних платформах?

Android: Product Flavors — налаштування flavor scheme

Product Flavors в Android створюють окремі варіанти застосунку з різними applicationId, ресурсами, кодом та залежностями.

android { flavorDimensions += listOf("environment", "tier") productFlavors { create("dev") { dimension = "environment" applicationIdSuffix = ".dev" versionNameSuffix = "-dev" resValue("string", "app_name", "MyApp Dev") } create("staging") { dimension = "environment" applicationIdSuffix = ".staging" versionNameSuffix = "-staging" resValue("string", "app_name", "MyApp Staging") } create("production") { dimension = "environment" } create("free") { dimension = "tier" applicationIdSuffix = ".free" } create("paid") { dimension = "tier" } } } 

Матриця варіантів: devFreeDebug, devPaidRelease, productionFreeRelease і т.д. Зазвичай використовують лише потрібні комбінації та явно вказують решту через variantFilter. Ресурси по flavors зберігаються в src/dev/res/, src/staging/res/, src/production/res/. Kotlin-код, специфічний для flavor — в src/dev/kotlin/ і т.д.

iOS: Targets та Schemes

В iOS роль Flavors відіграє комбінація Targets + Schemes + xcconfig. Apple Developer Documentation рекомендує такий підхід для розділення конфігурацій.

Один target, кілька Schemes + Build Configurations — для staging/production:

• Створюємо конфігурації: Debug, Staging, Release
• Створюємо Schemes: MyApp, MyApp-Staging
• Кожен Scheme запускає потрібну Configuration

Кілька Targets — для white-label або суттєво відмінних версій (різний код, різні capabilities):

• Кожен Target має свій PRODUCT_BUNDLE_IDENTIFIER, іконку, Info.plist
• Спільний код → Shared framework або просто спільні файли, додані в обидва Target
• Підхід важчий у підтримці, але дає максимальний контроль

Targets: MyApp → com.myapp.ios → AppIcon → Release.xcconfig MyApp-ClientB → com.clientb.myapp → AppIconClientB → ClientB.xcconfig MyApp-Staging → com.myapp.ios.staging → AppIconStaging → Staging.xcconfig 

Flutter: Flavors

Flutter підтримує flavors нативно, під капотом вони маппяться на Android Product Flavors та iOS Schemes:

flutter run --flavor staging -t lib/main_staging.dart flutter build apk --flavor production -t lib/main_production.dart 

main_staging.dart ініціалізує застосунок з staging-конфігурацією, main_production.dart — з production. Конфіг передається через --dart-define або через окремий app_config.dart на кожен flavor. В pubspec.yaml можна використовувати flutter_flavorizr для генерації boilerplate — створює потрібні Targets/Schemes на iOS та Product Flavors на Android з одного конфіг-файлу.

Що обрати: один Target чи кілька?

Відповідь залежить від обсягу відмінностей. Якщо різниця лише в bundle ID, API-endpoint та іконці — достатньо одного Target з кількома Schemes. Якщо потрібен різний код, різні push-капабіліті (APNs/FCM) або third-party SDK — беріть кілька Target (iOS) / flavorDimensions (Android). На Android з flavorDimensions легко комбінувати free vs paid та staging vs production одночасно. За нашими вимірами, один Target з кількома Schemes в 3 рази швидше в налаштуванні, ніж кілька Target.

Чому розділення конфігурацій економить час і нерви?

Уявіть: QA тестує staging-збірку, випадково видаляє production-базу? З різними bundle ID це неможливо — застосунки сприймаються системою як різні. Dev-версія стоїть поруч із production, і ви можете миттєво порівняти поведінку. Крім того, в App Store Review Guidelines (Section 4.2) вимагається, щоб тестова версія не змішувалася з продуктивною. Ми це враховуємо.

Типові помилки при налаштуванні Flavors

Процес роботи

1. Аудит вимог до варіантів (скільки версій, які відмінності, хто буде збирати)
2. Вибір підходу: Flavors vs Targets vs комбінований
3. Створення структури ресурсів та коду (resource overlays, конфігураційні файли)
4. Налаштування CI (Fastlane + GitHub Actions / GitLab CI) для збірки всіх варіантів
5. Тест встановлення поруч один з одним (перевірка, що не перетинаються по package name)
6. Документування процесу додавання нової версії

Порівняння платформ

Терміни та вартість

Термін: 2–3 дні для стандартної схеми (staging/production), до 5 днів для white-label з кількома брендами. Вартість розраховується індивідуально після аудиту. Отримайте консультацію — зв'яжіться з нами, оцінимо ваш проект та запропонуємо оптимальне рішення.

Замовте налаштування flavors під ключ — ваш проект буде готовий до масштабування без архітектурних конфліктів.