Разработка 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

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

Как гарантировать стабильность сборок для каждого tenant?

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

Сравнение подходов: Product Flavors vs Runtime конфигурация

Рекомендуем гибрид: статические ресурсы через flavors, а динамические фичи — через runtime флаги.

Этапы разработки white-label приложения

Типичные ошибки и как их избежать

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

Shared strings с захардкоженными брендами. (третье выделение) Имя бренда должно быть только в tenant-директории. Используйте ресурсы (strings.xml/Localizable.strings) для каждого бренда отдельно.

Единый Firebase проект. У каждого tenant должен быть свой google-services.json, иначе конфликты аналитики и push-уведомлений.

Отсутствие автотестов для каждого 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 недели. Стоимость рассчитывается индивидуально после анализа требований. Получите бесплатную консультацию по вашему white-label проекту — свяжитесь с нами для оценки.

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

В нашей практике white-label разработка – не просто «перекрасить приложение». Это архитектурное решение, которое необходимо закладывать на старте. Мы не раз сталкивались с попытками переделать монолитное приложение под white-label постфактум – это один из самых дорогих рефакторингов в мобильной разработке. За 5 лет работы мы реализовали 20+ white-label проектов для iOS, Android и кросс-платформенных стеков. Гарантируем: правильная модульная архитектура сокращает время адаптации нового клиента до 2 дней, а не 2 месяцев. White-label продукт (Wikipedia) – это не просто смена логотипа, а полноценная мультиарендная система. Получите консультацию по 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: отдельные поддомены (clienta.api.example.com). Вариант 3: tenant из JWT-токена после аутентификации.

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

Экономия от мультиарендной архитектуры по сравнению с выделенными бэкендами – до 60% на операционных расходах при 5+ клиентах.

Как правильно спроектировать 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 через распределённые билды.

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 месяц гарантийного сопровождения после релиза.

Сроки ориентировочно

Стоимость рассчитывается индивидуально – зависит от количества модулей, платформ и глубины кастомизации. Закажите бесплатный анализ вашей архитектуры – мы оценим объём работ за 2 дня. Свяжитесь с нами, чтобы обсудить ваш white-label проект – гарантируем соблюдение App Store Review Guidelines и Google Play policies.