White-label мобильные приложения: SDK, модульная архитектура и мультиарендность
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 для темы упрощает это значительно.
Multi-tenant: один бэкенд, разные приложения
Если несколько 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.
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.
Сроки: рефакторинг монолита в multi-tenant архитектуру — 2-3 месяца. Новое white-label приложение с правильной архитектурой с нуля — 3-4 месяца. Разработка мобильного SDK — от 6 недель для простого, от 3 месяцев для полнофункционального.