Налаштування Flavors/Schemes для різних версій мобільного додатку

Налаштування Flavors/Schemes для різних версій мобільного додатка

Один репозиторій, кілька додатків. White-label продукт для трьох клієнтів. Безплатна та платна версія з різними пакетами та іконками. Staging-збірка для QA з іншим bundle ID, яку можна встановити поряд з production-версією. Це все — завдання для Product Flavors (Android) та Schemes/Targets (iOS).

Android: Product Flavors

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.

Ресурси по flavor зберігаються в src/dev/res/, src/staging/res/, src/production/res/. Kotlin-код специфічний для flavor — у src/dev/kotlin/, тощо.

iOS: Targets та Schemes

На iOS роль Flavors відіграє комбінація Targets + Schemes + xcconfig.

Один 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 з одного конфіг-файла.

Типові помилки

• Додавання нового flavor без оновлення CI — пайплайн збирає лише старі варіанти
• Дублювання коду замість використання src/<flavor>/ overlay — maintainability падає
• Різні versionCode/CFBundleVersion для різних flavor одного релізу — плутанина при тестуванні

Процес

Аудит вимог до варіантів → вибір підходу (Flavors vs Targets) → створення структури ресурсів → налаштування CI для збірки потрібних варіантів → тест встановлення поряд один з одним → документування.

Період: 2–3 дні для стандартної схеми, до 5 днів для white-label з кількома брендами. Вартість розраховується індивідуально.