White-Label, SDK і модульна розробка мобільних додатків

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.