White-Label мобільного додатку: кастомізація під бренд

Кастомізація White-Label мобільного додатку під бренд клієнта

Ви передаєте готовий white-label додаток новому клієнту і одразу стикаєтеся з задачею адаптації під його фірмовий стиль. Без правильної архітектури ресурсів заміна логотипу, кольорів і шрифтів перетворюється на багатогодинний пошук кожного хардкодного значення. На одному проекті ми нарахували 47 інстансів кольору #1A73E8, розкиданих по layout-файлах. Після рефакторингу з виносом у colors.xml ребрендинг нового клієнта став займати 2 години замість 3 днів. За 5+ років роботи з 30+ white-label проектами ми виробили шаблон tenant-структури, який скорочує час ребрендингу до 1–3 днів.

Чому стандартний підхід до брендування гальмує запуск?

Типова помилка — кольори зашиті в layout-файлах, рядки з назвою бренду — в коді, шрифти — в проперті. При кожній зміні клієнта розробник витрачає години на пошук і заміну. Автоматизація через Fastlane робить ребрендинг у 2–3 рази швидше ручного підходу і виключає помилки.

Які елементи додатку змінюються при ребрендингу?

Візуальна ідентичність

Іконка додатку. На iOS потрібні іконки в 15+ розмірах для всіх пристроїв і App Store. Сучасний підхід — одна AppIcon.appiconset з одним вихідним зображенням 1024×1024 і автогенерацією через Xcode або Fastlane appicon. На Android — адаптивна іконка (mipmap-anydpi-v26/ic_launcher.xml) з foreground і background шарами: фон бренду + логотип.

Колірна схема. Всі кольори мають бути винесені в colors.xml (Android) або Assets.xcassets → Color Set (iOS). Прямі hex-значення в layout або коді — ознака того, що ребрендинг займе кілька днів замість кількох годин.

<!-- Android: res/values/colors.xml для конкретного tenant -->
<resources>
    <color name="color_primary">#1A73E8</color>
    <color name="color_primary_variant">#1557B0</color>
    <color name="color_secondary">#FB8C00</color>
    <color name="color_surface">#FFFFFF</color>
    <color name="color_on_primary">#FFFFFF</color>
    <color name="color_error">#B00020</color>
</resources>

Шрифти. Брендовий шрифт підключається через res/font/ (Android) або через Info.plist UIAppFonts (iOS). Якщо шрифт платний — перевіряємо ліцензію на мобільне використання (Desktop/Web ліцензія не покриває вбудовування в додаток).

Тексти та локалізація: Всі тексти, які містять назву бренду, слогани або описи — в strings.xml / Localizable.strings в директорії tenant. Жодних захардкоджених рядків у загальному коді. Splash screen text, onboarding-тексти, заголовок в tab bar — все перевизначається без зміни коду.

Екрани онбордингу та splash: Splash screen на iOS реалізується через LaunchScreen.storyboard (або Launch Screen в Info.plist для SwiftUI). На Android — через SplashScreen API (Android 12+) з брендовим іконом і фоном:

// Android 12+ SplashScreen з брендовим кольором
installSplashScreen().apply {
    setKeepOnScreenCondition { viewModel.isLoading.value }
}

Тема для splash:

<style name="Theme.App.SplashScreen" parent="Theme.SplashScreen">
    <item name="windowSplashScreenBackground">@color/color_primary</item>
    <item name="windowSplashScreenAnimatedIcon">@drawable/ic_splash_logo</item>
</style>

Як автоматизувати ребрендинг через Fastlane?

Ручна заміна ресурсів при додаванні кожного нового tenant — джерело помилок. Fastlane action для застосування брендингу:

# Fastfile
lane :apply_branding do |options|
  tenant = options[:tenant]
  brand_dir = "tenants/#{tenant}"

  # Копіюємо ресурси
  sh "cp #{brand_dir}/AppIcon.png fastlane/metadata/#{tenant}/app_icon.png"
  sh "cp -r #{brand_dir}/assets.xcassets ios/MyApp/#{tenant}.xcassets"

  # Оновлюємо Bundle ID
  update_app_identifier(
    xcodeproj: "ios/MyApp.xcodeproj",
    plist_path: "MyApp/Info.plist",
    app_identifier: "com.#{tenant}.app"
  )

  # Оновлюємо Display Name
  update_info_plist(
    plist_path: "ios/MyApp/Info.plist",
    display_name: options[:display_name]
  )
end

fastlane apply_branding tenant:brand_b display_name:"Brand B"
fastlane ios build tenant:brand_b

Fastlane — не єдиний варіант. Аналогічні скрипти можна написати на Bash або Makefile. Головне — єдина точка входу для всіх tenant-ресурсів.

Порада: Починайте новий white-label проект з виділеної tenant-директорії для кожного клієнта. Зберігайте всі змінювані ресурси: іконки, кольори, шрифти, рядки, конфіги. Це заощадить години при додаванні наступного клієнта.

Порівняння ручного та автоматизованого брендування

Чекліст кастомізації нового tenant

Що входить в роботу з кастомізації?

При замовленні послуги ми готуємо:

• Документація: схема tenant-директорій, інструкція з додавання нового клієнта.
• Доступи: App Store Connect, Google Play Console, Firebase, TestFlight (ваші акаунти).
• Навчання: сесія для вашого QA з перевірки брендингу.
• Підтримка: 2 тижні після деплою — виправлення неточностей у візуалі.

Порівняйте: створення white-label додатку з нуля під одного клієнта коштує в 5–10 разів дорожче, ніж кастомізація готового рішення. При масштабуванні на 10+ клієнтів економія ресурсів перевищує 80%.

Орієнтири за термінами

Кастомізація готового white-label додатку під нового клієнта при правильно налаштованій структурі ресурсів — 1–3 дні. Якщо ресурси не були винесені в tenant-директорії і потрібен рефакторинг для кількох місць хардкоду — 3–7 днів. Вартість розраховується індивідуально.

Зв'яжіться з нами — оцінимо ваш проект за 2 години. Працюємо з 30+ white-label проектами на iOS та Android. Отримайте консультацію по вашому кейсу.

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.