Разработка White-Label мобильного приложения

Разработка White-Label мобильного приложения

Представьте: у вас 10 клиентов, каждому нужно своё приложение с уникальным брендингом, но единой бизнес-логикой. Без white-label вы рискуете утонуть в копировании кода и ошибках, а бюджет на поддержку нескольких кодовых баз может превысить стоимость самого продукта. Наше решение — единая кодовая база с параметризацией, которая позволяет запустить нового клиента за считанные дни. Типичная экономия при использовании white-label вместо разработки с нуля — 60-80% времени и бюджета. Каждый клиент получает индивидуальные иконки, цвета и контент, а вы — один репозиторий и единый CI/CD. Наш опыт — 50+ проектов за 10+ лет — гарантирует чистую архитектуру с первого коммита.

Закажите разработку white-label приложения и получите первичный аудит текущей архитектуры.

Например, недавно мы запустили платформу для сети франчайзи: пять брендов, каждый со своей цветовой схемой и набором функций, на единой кодовой базе. Затраты на разработку сократились на 70%, time-to-market нового бренда — 10 дней. В этой статье разберём архитектурные решения, CI/CD и типичные ошибки.

Почему white-label подход лучше разработки с нуля?

Единый репозиторий означает, что вся логика в одном месте, обновления распространяются на всех клиентов. Кастомизация без дублирования достигается с помощью 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, каждый Target может иметь свой набор ресурсов. На Android аналогично, как описано в документации по 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

Разные клиенты часто имеют разный набор функций. Флаги, зашитые в 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