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. Отримайте консультацію по вашому кейсу.