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