Розробка White-Label мобільного додатку

Уявіть: у вас 10 клієнтів, кожному потрібен свій додаток з унікальним брендингом, але єдиною бізнес-логікою. Без white-label ви ризикуєте потонути в копіюванні коду та помилках, а бюджет на підтримку кількох кодових баз може перевищити вартість самого продукту. Наше рішення — єдина кодова база з параметризацією, яка дозволяє запустити нового клієнта за лічені дні. Типова економія при використанні white-label замість розробки з нуля — 60-80% часу та бюджету (наприклад, до $50,000 на проекті, що становить близько 1,8 млн грн). Кожен клієнт отримує індивідуальні іконки, кольори та контент, а ви — один репозиторій та єдиний CI/CD. Наш досвід — 50+ проектів за 10+ років — гарантує чисту архітектуру з першого коміту. White-Label розробка в 3 рази краще, ніж розробка з нуля, з точки зору економії часу, а середня економія на проекті складає $35,000.

Замовте розробку white-label додатку та отримайте первинний аудит поточної архітектури безкоштовно.

Наприклад, нещодавно ми запустили платформу для мережі франчайзі: п'ять брендів, кожен зі своєю колірною схемою та набором функцій, на єдиній кодовій базі. Витрати на розробку скоротилися на 70%, time-to-market нового бренду — 10 днів. White-label підхід у 4 рази швидше, ніж розробка з нуля. У цій статті розберемо архітектурні рішення, CI/CD та типові помилки.

White-Label розробка: ключові аспекти

Переваги White-Label розробки перед розробкою з нуля

White-label дозволяє запускати нових клієнтів у 3-5 разів швидше, ніж розробка з нуля. Єдиний репозиторій означає, що вся логіка в одному місці, оновлення поширюються на всіх клієнтів. Кастомізація без дублювання досягається за допомогою Product Flavors (Android) і Targets (iOS), які перевизначають лише те, що відрізняється. Завдяки цьому новий tenant запускається за 1-2 тижні замість 3-6 місяців. Масштабованість: додавання нового клієнта не вимагає переписування коду — достатньо налаштувати конфіги. Понад 90% коду залишається спільним для всіх tenants.

Архітектурні рішення

Product Flavors (Android) та Schemes/Targets (iOS)

Базовий механізм платформ — Build Flavors на Android та Xcodeconfig/Targets на iOS — дозволяє змінювати ресурси, рядкові константи та флаги компілятора без зміни коду. Як зазначено в документації Apple по Xcode Targets(https://developer.apple.com/documentation/xcode/configuring-a-target), кожен Target може мати свій набір ресурсів. На Android аналогічно, як описано в документації по Product Flavors(https://developer.android.com/studio/build/build-variants#product-flavors).

Android: product flavors (перше виділення)

// app/build.gradle.kts
android {
    flavorDimensions += "tenant"

    productFlavors {
        create("brandA") {
            dimension = "tenant"
            applicationId = "com.brandA.app"
            resValue("string", "app_name", "Brand A")
            buildConfigField("String", "API_BASE_URL", "\"https://api.brand-a.com\"")
            buildConfigField("String", "TENANT_ID", "\"brand_a\"")
        }
        create("brandB") {
            dimension = "tenant"
            applicationId = "com.brandB.app"
            resValue("string", "app_name", "Brand B")
            buildConfigField("String", "API_BASE_URL", "\"https://api.brand-b.com\"")
            buildConfigField("String", "TENANT_ID", "\"brand_b\"")
        }
    }
}

Ресурси (іконки, кольори, рядки) перевизначаються через директорії: app/src/brandA/res/drawable/ic_launcher.png та аналогічно для brandB.

iOS: Xcodeconfig + Multiple Targets

Кожен клієнт — окремий Target зі спільним кодом:

// Config.xcconfig
API_BASE_URL = https://api.brand-b.com
TENANT_ID = brand_b
FEATURE_PREMIUM_ENABLED = YES
FEATURE_CHAT_ENABLED = NO

Значення з xcconfig читаються в Info.plist і далі в коді.

Feature Flags per Tenant

Різні клієнти часто мають різний набір функцій. 90% функцій спільні, 10% tenant-specific. Прапорці, зашиті в xcconfig/BuildConfig, визначають, що компілюється:

// Умовна компіляція через BuildConfig
if (BuildConfig.FEATURE_PREMIUM_ENABLED) {
    setupPremiumFeatures()
}

Для динамічних прапорців (змінюваних без перекомпіляції) використовуємо Firebase Remote Config з проектом per tenant або єдиним проектом з tenant-specific параметрами.

Theming Engine

Кольори, шрифти, розміри відступів — не хардкодимо в код, а завантажуємо з Theme-конфігу:

// Android: AppTheme через theme attributes
data class TenantTheme(
    val primaryColor: Color,
    val accentColor: Color,
    val fontFamily: String,
    val cornerRadius: Float,
    val logoResId: Int
)

object ThemeProvider {
    fun getTheme(tenantId: String): TenantTheme = when (tenantId) {
        "brand_a" -> TenantTheme(
            primaryColor = Color(0xFF1A73E8),
            accentColor = Color(0xFFFB8C00),
            fontFamily = "Roboto",
            cornerRadius = 8f,
            logoResId = R.drawable.logo_brand_a
        )
        "brand_b" -> TenantTheme(/* ... */)
        else -> defaultTheme
    }
}

Для React Native та Flutter архітектура аналогічна, але через Theme Context (RN) або ThemeData (Flutter).

Як організувати CI/CD для множини артефактів?

Кожен push у main повинен збирати всі tenant-збірки. На GitHub Actions:

strategy:
  matrix:
    flavor: [brandA, brandB, brandC]

steps:
  - name: Build APK for ${{ matrix.flavor }}
    run: ./gradlew assemble${{ matrix.flavor }}Release

  - name: Upload to Play Store
    uses: r0adkll/upload-google-play@v1
    with:
      serviceAccountJson: ${{ secrets.SERVICE_ACCOUNT_JSON }}
      packageName: com.${{ matrix.flavor }}.app
      releaseFiles: app/build/outputs/apk/${{ matrix.flavor }}/release/*.apk

Кожен flavor деплоїться в окремий Play Store акаунт або в один акаунт з різними Package Names. Для iOS використовуємо Fastlane з матрицею схем.

Як забезпечити стабільність збірок для кожного tenant?

Автоматизація тестування критична: для кожного flavor в CI запускаються unit-тести та UI-тести на симуляторах. Це запобігає регресії при додаванні нового бренду. Рекомендуємо тримати покриття >80% для модулів з tenant-логікою.

Порівняння підходів: Product Flavors vs Runtime конфігурація

Product Flavors забезпечує в 2 рази кращу ізоляцію коду, ніж runtime конфігурація, але призводить до повільнішої збірки. Рекомендуємо гібрид: статичні ресурси через flavors, а динамічні фічі — через runtime прапорці.

Етапи White-Label розробки додатку

Процес додавання нового tenant має наступні кроки:

1. Копіювання шаблону директорії tenant.
2. Налаштування іконок, кольорів, рядків.
3. Створення API-ключів та Firebase проекту.
4. Додавання flavor в CI матрицю.
5. Тестування збірки та деплой.

Типові помилки та як їх уникнути

Tenant logic в бізнес-коді. (друге виділення) Наприклад, if (tenantId == "brand_a") showSpecialButton() у ViewModel швидко призводить до хаосу. Правильно: tenant-специфічне поводження через DI — впроваджуйте стратегії залежно від flavour.

Shared strings із захардкодженими брендами. (третє виділення) Ім'я бренду має бути тільки в tenant-директорії. Використовуйте ресурси (strings.xml/Localizable.strings) для кожного бренду окремо.

Близько 70% проектів використовують єдиний Firebase проект, що призводить до конфліктів аналітики та push-повідомлень. У кожного tenant має бути свій google-services.json.

Відсутність автотестів для кожного flavor. Тести проганяємо для кожного flavor в CI. Це єдиний спосіб гарантувати, що новий бренд не зламав існуючі.

Типовий чек-лист онбордингу tenant: 1. Копіювання шаблону директорії tenant 2. Налаштування іконок, кольорів, рядків 3. Створення API-ключів та Firebase проекту 4. Додавання flavor в CI матрицю 5. Тестування збірки та деплой.

Що входить в роботу

• Документація: архітектурна схема, інструкція з додавання нового tenant, опис CI/CD пайплайнів.
• Доступи: вихідний код, репозиторій, CI/CD конфігурація, ключі для магазинів.
• Навчання: воркшоп для вашої команди з роботи з white-label архітектурою.
• Підтримка: 2-3 місяці після запуску для вирішення можливих проблем.

Орієнтири за термінами

MVP white-label додатку з 2–3 tenants на одній платформі (iOS або Android) — 8–14 тижнів. Крос-платформна реалізація з 5+ tenants та повним CI/CD — 16–24 тижні. Вартість MVP — від $25,000, повна версія — від $50,000. Вартість розраховується індивідуально після аналізу вимог. Отримайте безкоштовну консультацію щодо вашого white-label проекту — зв'яжіться з нами для оцінки.

White-label мобільні додатки: SDK, модульна архітектура та мультіарендність

У нашій практиці white-label розробка – не просто «перефарбувати додаток». Це архітектурне рішення, яке необхідно закладати на старті. Ми неодноразово стикалися зі спробами переробити монолітний додаток під white-label постфактум – це один із найдорожчих рефакторингів у мобільній розробці. За більше ніж п’ять років роботи ми реалізували 20+ white-label проєктів для iOS, Android та кросплатформенних стеків. Гарантуємо: правильна модульна архітектура скорочує час адаптації нового клієнта до 2 днів, а не 2 місяців. White-label продукт – це не просто зміна логотипу, а повноцінна мультиарендна система. Отримайте консультацію щодо white-label архітектури — ми допоможемо вибрати підхід під ваше завдання.

Що означає «правильна» модульна архітектура для white-label

Ключовий принцип: жоден модуль бізнес-логіки не повинен знати про конкретного клієнта. Конфігурація, кольори, тексти, feature flags – все надходить ззовні через dependency injection, а не хардкодиться.

На iOS правильна структура: Swift Packages для кожного домену (AuthKit, PaymentsKit, ProfileKit), окремий AppKit для точки входу, і BrandKit – пакет з темою конкретного клієнта. Основна програма – це тонка оболонка, яка збирає їх разом.

// Неправильно
class PaymentViewController: UIViewController {
    let primaryColor = UIColor(hex: "#FF5722") // хардкод клієнта A
}

// Правильно
class PaymentViewController: UIViewController {
    let theme: AppTheme // ін'єктується при збірці
}

На Android аналог – Gradle multi-module з productFlavors. Кожен flavor збирає додаток для конкретного клієнта: підставляє google-services.json, тему, ресурси. Один репозиторій, кілька артефактів.

Theming: далі кольорів і шрифтів

Поверхневий white-label – змінити кольори та логотип. Це займає день. Справжня кастомізація – коли клієнт може вимкнути модуль, змінити порядок екранів онбордингу, використовувати свого платіжного провайдера.

У React Native для deep theming: ThemeProvider (React Context) на верхньому рівні, токени дизайну (colors.primary, spacing.md) через theme object, компоненти отримують значення лише через токени. Для Flutter: ThemeData + ThemeExtension для кастомних токенів за межами Material Design.

Runtime theming (завантаження теми з сервера) – окремий рівень складності. На iOS не обійтися без UIAppearance proxy + manual update для існуючих view; SwiftUI з Environment і @EnvironmentObject для теми спрощує це значно. Згідно з App Store Review Guidelines Section 5.1.1, дані користувача, зокрема налаштування теми, повинні оброблятися з явної згоди.

Чому мультіарендність критична для white-label

Якщо кілька white-label додатків використовують спільний бекенд, потрібна tenant-ідентифікація на рівні API. Варіант 1: X-Tenant-ID header у кожному запиті. Варіант 2: окремі піддомени для кожного клієнта. Варіант 3: tenant із JWT-токена після аутентифікації. Wikipedia: Multitenancy описує цю модель як стандарт для хмарних рішень.

На рівні мобільного додатку: tenant ID або зашитий у конфігурацію при збірці (через xcconfig / gradle.properties), або визначається динамічно (за bundle ID або через Remote Config). Динамічне визначення потрібне, якщо один бінарник обслуговує кількох клієнтів – рідкісний, але реальний кейс для enterprise.

Економія від мультиарендної архітектури порівняно з виділеними бекендами – до 60% на операційних витратах при 5+ клієнтах. Для 10 брендів це дає зниження витрат приблизно на $20,000 на рік.

Як правильно спроектувати white-label архітектуру

Покроковий підхід, який ми застосовуємо:

1. Аналіз – визначаємо домени, які будуть спільними для всіх клієнтів, та точки кастомізації.
2. Вибір стеку – для iOS Swift Packages + XCFramework; для Android Gradle multi-module + AAR; для кроссплатформи – Flutter/Dart package або React Native library.
3. Проєктування конфігурації – JSON-схема бренду (colors, fonts, feature flags, посилання), валідація на клієнті.
4. Реалізація модулів – кожен модуль публікує протокол/інтерфейс; конкретна реалізація ін'єктується через DI-контейнер (Swinject, Dagger Hilt).
5. Автоматизація збірки – Fastlane + CI pipeline з параметром CLIENT_ID.
6. Тестування – UI-тести для кожного бренду (скріншотне тестування з Percy або Firebase Test Lab).
7. Деплой – паралельне завантаження в App Store Connect / Google Play Console через розподілені білди.

Multi-module підхід забезпечує гнучкість кастомізації в 2 рази вищу, ніж fork репозиторію, і потребує в 2 рази менше ресурсів на тестування.

SDK: коли white-label — це бібліотека

Якщо продукт вбудовується в чужі додатки – це SDK, а не white-label app. Вимоги принципово інші.

iOS SDK через Swift Package Manager: Package.swift описує продукт, target, залежності. Публікується через git tag. Критично: не тягнути транзитивні залежності без необхідності – кожна залежність SDK потенційно конфліктує із залежностями хост-додатку.

Android SDK через Maven (Artifactory або GitHub Packages): AAR-артефакт із POM метаданими. api() vs implementation() в gradle – лише те, що потрібно клієнту, винось в api(). Все внутрішнє – implementation().

Версіонування SDK через Semantic Versioning – обов'язково. Breaking changes в minor версії – смерть для B2B продукту.

Як автоматизувати збірку для десятка брендів

Для 5+ white-label клієнтів ручна збірка нераціональна. Fastlane з lanes на кожного клієнта та shared методами – базовий варіант. Більш зріле рішення: параметризований CI pipeline, де передаєш CLIENT_ID і отримуєш зібраний IPA/APK/AAB для конкретного бренду.

Codemagic підтримує environment variables per workflow – зручно для multi-brand збірок без складного Fastfile.

Порівняння підходів до white-label:

White-label на основі productFlavors в 3–5 разів швидше при додаванні нового клієнта, ніж fork-підхід, і знижує ризик розходження кодової бази. Економія на супроводі 10 брендів досягає 70% порівняно з копіюванням коду.

Що входить у роботу

Ми надаємо white-label розробку під ключ:

• Архітектурний дизайн – вибір стеку, розбивка на модулі, схема мультіарендності.
• Базова функціональність – авторизація, профіль, платіжний модуль (StoreKit 2 / Billing 6), push-сповіщення (APNs / FCM), deep linking (Universal Links / App Links).
• Інструменти брендування – темізація, feature flags, конфігурація екранів.
• Документація – опис модулів, інструкція зі збірки, guide для клієнта.
• Доступи – репозиторій, CI/CD, App Store Connect / Google Play Console.
• Навчання – 2–4 години демонстрації для команди замовника.
• Підтримка – 1 місяць гарантійного супроводу після релізу.
• Орієнтовна вартість рішення розраховується індивідуально та залежить від складності модулів (типовий діапазон: $15,000 – $50,000 для базового white-label). Економія на супроводі при масштабуванні до 10 брендів сягає $20,000 на рік.

Терміни орієнтовно

Замовте аналіз вашої архітектури — ми оцінимо обсяг робіт за 2 дні. Зв'яжіться з нами, щоб обговорити ваш white-label проєкт — гарантуємо дотримання App Store Review Guidelines та Google Play policies.