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 місяців для повнофункціонального.