Mobile App в White Label уже в личном кабинете
Время прочтения: 2 мин.
Наконец, мы реализовали новую функцию «Мобильное приложение», которая позволит вашим посетителям скачивать мобильное приложение для iOS с вашими цветовыми настройками, логотипом, названием и т.д. Все продажи, совершённые в этом приложении, будут зачисляться на ваш аккаунт.
Как это работает?
Механизм простой — мы создали «пустое» приложение для iOS и загрузили его в Apple Store. В случае, если установка будет сделана с вашего White Label, приложение пользователя получит все необходимые настройки и закрепится за вашим аккаунтом.
Функция «Мобильное приложение» — отличный способ «привязать» навсегда ваших mobile-пользователей, не прибегая к дополнительной разработке.
Вам нужно только кастомизировать мобильное приложение.
После сохранения всех настроек у вас появится активная ссылка для установки приложения.
Делитесь в комментариях пожеланиями по работе Mobile App.
Как White Label помогает в развитии сервисов и продуктов. 5 примеров
Любое партнерство в бизнесе всегда носит индивидуальный характер и собственные предпосылки. Кто-то пытается найти новые каналы и способы развития, кто-то приходит к интеграции с партнером не от хорошей жизни.
Идеальная партнерская программа – та, что развивает и дополняет продажи. Строить бизнес исключительно на партнерстве достаточно рискованно, поскольку при этом одна из компаний может быстро попасть в зависимость от партнера и потерять свои цели и стратегию. В этой статье — про партнерские отношения по модели White Label.
White Label – понятие относительно новое. Помогут разобраться в нем 5 представителей разного бизнеса. Это сервисы, которые уже внедрили программу White Label и предлагают своим партнерам взаимовыгодное сотрудничество. Кому и зачем это может быть интересно? Разбираемся вместе с туроператором, SMM-сервисом, антивирусной системой и другими продуктами.
White Label – это про взаимную выгоду
White Label – это модель сотрудничества нескольких компаний. Она подразумевает реализацию услуг или продукции под брендом компании-продавца и оказывается ресурсами другой компании. Сегодня такую схему взаимодействия чаще всего используют организации с крупными клиентскими базами и зарекомендованным на рынке брендом. В других случаях модель работает менее эффективно.
В русской терминологии иногда встречается понятие “немарочный продукт” или сервис. То есть акцент снова-таки делается на том, что товар выпускается без лейбла и предлагается розничному торговцу или дистрибьютору. Чаще же всего в бизнесе распространено понятие White Label.
Почему бизнес приходит к партнерской программе?
У всех свои причины. В целом, предпосылки для использования White Labeling выглядят так:
“Мы являемся крупным иностранным туроператором, поэтому партнёрские программы, а в частности White Label, – это неотъемлемая часть продвижения нашего продукта. Сегодня престижно иметь в арсенале такой вид партнерства, тем более, что он особенно хорошо подходит для нашей сферы деятельности (онлайн туры). У нас богатая форма поиска: расширенное подробное меню, где клиент может сам составить себе тур из разных параметров (направление, медицинское показание, тематика, питание, продолжительность, расположение отеля, виды спорта, и т.д.). Это всё очень хорошо обогащает и повышает уровень того ресурса, который все это предлагает. То есть такое White Label решение престижно иметь у себя на сайте.
У нас много рынков сбыта, поэтому предлагаем White Label на многих языках мира. Это удобно для партнеров и конечных потребителей.
Конечно же есть и свои минусы. Многие партнеры думают, что после установки White Label дела пойдут сразу же вверх и прибыть «польется рекой». При этом они ничего не делают, чтобы правильно позиционировать White Label и свой ресурс. White Label требует определённой «огранки». Сайт должен соответствовать уровню предлагаемого продукта. Должен постоянно наполняться контентом и быть актуальным. Мы всегда следим за новыми веяниями в сфере СПА и оздоровительного отдыха, в сфере маркетинга и IT технологий. Посетитель должен легко находить White Label. Партнер должен также продвигать решение, которое он установил, делать какие-то акции, интересные предложения, подключать социальные сети, рассказывать о продукте, делать рассылку. Это кооперация двух сторон.
Мы работаем с PR-фирмой, аналитической компанией, используем силы собственного отдела маркетинга, плюс за каждой отдельной страной закреплены сотрудники, которые более детально, приближённо конкретно к рынку сбыта, продвигают продукты, в том числе White Label. Без постоянной работы по продвижению результат падает. Для нас плюс в White Label заключается также в наращивании трафика, посетителей. Люди любят, когда всё удобно и не надо додумывать или лишний раз задавать кучу вопросов”.
В чем выгода White Label для партнеров?
Каждая компания, работающая по White Label схеме, предлагает партнерам собственные условия. Но чаще всего, White Label подразумевает следующие выгоды:
“Чтобы понять все преимущества решения White Label в сфере онлайн гемблинга, нужно хотя бы общо представлять структуру онлайн казино.
Любое онлайн казино состоит из 3-х частей: платформы, контента и платежной системы. Платформа — это ПО, которое включает в себя весь необходимый для оперирования функционал, в который входит система регистрации, система отчетов, система управления игровым контентом, система бонусов, управление электронным кошельком и т.д. Контент, т.е. игры — это слоты, настольные игры, a также живые диллеры. Это отдельное направление, которое не является встроенным в платформу. Платежные системы – способ ввода/вывода денег на онлайн казино — visa, master card, neteller, skrill и т.д.
Это все разные направления бизнеса, и для того, чтобы создать проект, необходимо объединить их в одно целое. Модель White Label представляет собой комплексное решение по открытию онлайн казино, с полностью сформированной юридической, финансовой инфраструктурой и включает в себя: платформу по модели Saas, проинтегрированные игры, платежные системы и лицензию.
Оператору не нужно тратить время на получение лицензии и на заключение договоров с провайдерами игр и платежных систем. Оперирование производится под лицензией поставщика решения White Label и по его прямым договорам с провайдерами игр и платежных систем. Таким образом, благодаря White Label оператор получает возможность запустить проект в максимально сжатые сроки, а сэкономленное время и бюджет на получение лицензии он сможет потратить на продвижение своего проекта. Большая часть проектов на рынке работает именно по такой модели”.
Николай Туголуков, менеджер по развитию BOSS Gaming Studio
White Label – краткосрочная перспектива?
Считается, что основной недостаток White Label в том, что партнер, продавая продукт под собственным брендом, снижает фокусировку на своем. Вы быстро сможете получить деньги – для краткосрочной перспективы это звучит заманчиво. Но при долгом взаимодействии – ваш бренд просто может прекратить развитие.
Но если бы недостаток White Label превалировал над всеми достоинствами модели, к нему бы вряд ли обращались многие компании, и White Label сотрудничество не становилось бы популярнее из года в год. Своим опытом это доказывают компании, которые только начинают внедрять немарочную систему партнерства, или которые давно ощутили выгоду от работы с White Label.
Вот как комментирует применение White Label в своем бизнесе директор НАНО Секьюрити, Денис Богданов:
“Создание антивирусного решения с нуля – крайне ресурсоемкая задача, в том числе, в плане временных затрат. Во всем мире лишь единичные компании могут позволить себе такую разработку. Использование нашего готового решения позволяет партнерам в кратчайшие сроки получить свой собственный качественный антивирусный продукт, разработанный с учётом всех высоких стандартов индустрии. Кроме того, мы обеспечиваем профессиональную техническую поддержку, обновление с использованием наших ресурсов и прочие типы сопровождения нового продукта для наших клиентов. Такой подход интересен компаниям-партнерам, которые используют нашу White Label платформу для своих решений.
Наш продукт NANO Antivirus White Label – это ко-брендинговая платформа, полностью основанная на наших технологиях. Мы используем платформу для создания новых антивирусных решений в соответствии с требованиями и потребностями клиента.
Мы предлагаем реализовать «практически невозможное» – за короткий срок и относительно небольшую цену получить собственный качественный антивирус. С партнёра полностью снимаются все технические вопросы, связанные с разработкой, а также дальнейшей поддержкой и сопровождением антивирусного решения. В итоге партнёр получает продукт с своим брендом, выполненный в соответствии с его техническим заданием. Далее он может начать зарабатывать деньги на дистрибуции собственного антивируса, использовать его в имиджевых целях или распоряжаться им как-то иначе в соответствии со своим бизнес-планом. При этом клиент получает антивирусное решение, аналогичное по качеству NANO Антивирус Pro.
С продвижением White Label все просто: используем собственный сайт, сторонние интернет-ресурсы, специализированные мероприятия (конференции, выставки), прямые контакты с потенциальными клиентами”.
В сервисе для масспостинга и аналитики соцсетей KUKU.io стали предлагать White Label сотрудничество с этого года:
“Сегодня бизнес любого размера активно приходит в социальные сети, которые становятся незаменимым каналом продаж и продвижения. Поэтому сервисы для автоматического постинга, детальная аналитика аккаунтов, использование удобного контент-календаря, а также управление SMM-командой и контентом онлайн значительно упрощают жизнь маркетологов. Поэтому KUKU.io White Label может быть интересен компаниям из любой отрасли и разных регионов. Для нас же — это, в первую очередь, выход на новую аудиторию.
Любой из модулей, будь то аналитика или постинг, могут быть внедрены в ваш существующий продукт. Кроме этого, могут быть добавлены дополнительные возможности, позволяющие делать более детальный анализ контента и аудитории, автоматизировать работу сотрудников и ряд других. То есть за 1-2 месяца партнер получает полностью уникальный SMM-продукт, который сможет продавать под своим брендом.
К нам обращаются финансовые, медиа, рекламные организации для создания собственных сервисов работы с социальными сетями. Практика показывает, что за этой моделью будущее, поэтому рассчитываем на интерес новых партнеров”.
Компания Black42pay оценивает свой опыт так:
“Мы предлагаем возможности по организации оплаты банковскими картами на интернет сайтах со всего мира (эквайринг), в аренду свою сертифицированную платформу, которую партнер использует под свою платежную систему, под своим брендом.
Мы пришли к White Label, чтобы «держаться на плаву» в бизнесе. Такой формат сотрудничества подразумевает взаимную выгоду, при которой каждая сторона занимается зоной своей компетенции.
Предоставляем интеграционные решения и создаем партнерские отношения с другими электронными платежными системами, например, партнерство по White Label технологического направления. Обеспечиваем программно-серверную часть системы. Наша выгода – проценты от интеграции и аренды программного обеспечения, выгода наших White Label партнеров — возможность продвинуться на рынке эквайринга и электронных платежей.
У нашего White Label партнера затраты минимальны, так как перечень необходимых ему модулей для своей платежной системы он выбирает сам, согласно прайсу и пожеланий конечного результата в работе системы.
С момента внедрения White Label модели у нас были заключены десятки соглашений, схема White Label работает, партнеры довольны результатами, поскольку получили возможность запустить свою платежную систему с нуля с минимальными потерями времени и средств.»
Системный гайд по созданию White Label android-приложений
Как написать код один раз, а продать 20 мобильных приложений? Мы нашли ответ путём проб и факапов и разложили опыт по пунктам: из статьи вы узнаете, как безболезненно реализовать White Label android-проект.
Greetings and salutations! Меня зовут Кирилл, по работе я однажды получил крутую задачу по разработке White Label android-приложения. Изучил достижения коллег в этой области и нашёл только:
входные гайды (раз, два, три, etc) о механизмах, но без промышленного дизайна;
статьи, в которых освещены узкие аспекты задачи (раз, два, etc).
На мой взгляд, теме не хватает цельного гайда, который проведёт от потребностей к требованиям, от требований к архитектуре и вооружит best practices. Поэтому я решил сделать его сам.
1 Ставим задачу
Мы в «Лайв Тайпинге» уже 10 лет делаем приложения для сегмента eCommerce и retail. За это время мы поняли, что и малый, и средний бизнес нуждается в дешёвых приложениях для систем лояльности: крупные ретейлеры уже обзавелись такими продуктами и приучили пользователей к мобильным приложениям.
Работает система просто (покупатели показывают приложение на кассе вместо пластиковой карты и получают скидки и бонусы), а для её реализации нужны типовые фичи: регистрация, виртуальная дисконтная карта и прочие.
Бюджет ограничен. фичи типовые. да здравствует конструктор приложений! Или White Label продукт? Пока отложим термины и опишем задачу: генерировать приложения из единой кодовой базы, каждое – с дизайном под бренд клиента и только нужными ему фичами.
Задача: создавать приложения для разных клиентов из единой кодовой базы
1.1 Визуализируем решение
Посмотрим, как это должно работать на примере экрана дисконтной карты. В магазине карту можно использовать двумя способами: чтобы узнать баланс и чтобы получить тот или иной бонус.
У каждого бренда своя программа лояльности, например в SEPHORA накапливаются бонусные баллы и процент скидки, а в «Пятёрочке» только баллы. В приложениях это выглядит так:
Мы хотим поддерживать как можно больше программ лояльности, при этом интерфейс оставить общим. Предусмотрим вариативность, получим возможный вид экрана карты для разных клиентов:
Как реализовать такой проект без боли? Прочитайте статью и найдёте ответ.
Мы знаем, о чём говорим, ведь уже создали «Лояку» — White Label продукт, который помогает быстро собирать крутые мобильные приложения с программой лояльности. Рост выручки, клиенты в курсе всех акций — вот это вот всё 
1.2 Детализируем требования
Разложим видение по полочкам: как в ТЗ, но проще.
Функциональные требования
Реализовать общие модули фичей:
новости – клиент узнаёт об акциях и жизни сети магазинов;
лояльность – получает дисконтную карту, узнаёт баланс, пробивает на кассе;
Задавать отдельно для каждого приложения:
наборы фичей, чтобы выбирать сами модули и настраивать их параметры;
бренд, чтобы настраивать цвета и менять ресурсы: шрифты, картинки, зашитый контент.
Нефункциональные
у приложений должен быть общий код;
настройка нового приложения – меньше четырёх часов разработчика;
архитектура должна упрощать расширение модулей и поддержку от 10 до 100 приложений.
1.3 Что пилим то? Конструктор? White Label?
Требования ясны – разберёмся с терминами. На старте проекта я думал, что мы делаем «конструктор приложений». Искал статьи с опытом создания, а находил рекламу готовых продуктов. Потратил пару часов на гугл и с радостью сэкономлю время вам:
универсальный сервис сборки приложений из готовых компонентов;
например, AppGyver – drag’n’drop вёрстка, программирование на низкоуровневых фичах (открыть экран, сделать фото);
творим что угодно – от приложений по покупке золота до приёмки грузов.
конструктор для конкретного типа приложений, например для такси;
ребрендинг под клиента и настройка высокоуровневых фич (новости, профиль)
Наш фокус на системах лояльности. Значит, делаем White Label. Гуглим «white label android development» и находим то, что нужно.
2 Проектируем и воплощаем
Строим системную схему White Label приложения
Для успешной реализации проекта нам нужно создать «понятную» и «расширяемую» архитектуру (раскрывать термины не буду, здесь хватит интуитивного понимания). Для этого заглянем вглубь системы, выделим подзадачи по слоям Clean Architecture…
… и получим четыре жирные проблемы:
Как шарить кодовую базу между приложениями?
Как сделать ребрендинг?
Как задавать конфиги?
Как отключать ненужные модули и настраивать необходимые?
В очередь, проблемы, в очередь!
2.1 Шарим код
Задача – одна кодовая база, до 100 приложений. Решение – Gradle Product Flavors.
Если вы ещё не знакомы с Gradle Product Flavors, советую почитать документацию или общие статьи. А можно и сразу в контексте White Label: кратко или в формате инструкции
Главное преимущество. Относительная простота переиспользования кода и ресурсов, удобство сборки.
Главный недостаток. Если вариантов больше 100, то в проекте и конфигах будет тяжело ориентироваться. Но у нас меньше, поэтому ок.
Альтернативы, на мой взгляд, рассматривать нет смысла: решение надёжное, из коробки.
Пример flavors. Допустим, на старте делаем два приложения:
«Лояка» — абстрактная компания;
«Ювелирия» — сеть ювелирных магазинов.
Здесь и далее привожу сокращённые примеры из тестового проекта к статье.
Наконец, задействуем flavors — в build.gradle уровня app :
2.2 Перекрашиваем
2.2.1 Концепт
У каждого приложения свой бренд, который складывается из:
шрифтов, картинок, строк;
зашитого контента (соглашений, ссылок в соц. сети).
Благодаря flavors тоже решим задачу просто. Загрузим в голову 3 факта:
общие код и ресурсы проекта лежат в папке main ;
для gradle main это как дефолтный flavor;
Слева — ресурсы по flavor; справа — итоговый APK.
2.2.2 Best practices
Крайне важно заранее договориться с дизайнерами:
ресурсы в приложениях называем одинаково — вставляем в проект прямиком из дизайна;
тему задаём чётким набором цветов — для перекрашивания копируем colors.xml в новый flavor и просто меняем значения.
Проблема в том, что костыли масштабируются на 100 приложений! Представьте, что дизайн оставили, а для решения проблемы ввели новый цвет в общей теме. Приходит новое приложение, а там опять несоответствие: вводим очередной цвет, итог — тема на сотни значений и проект, который тяжело поддерживать.
Создать и поддерживать чёткую схему для всех приложений на порядок дешевле, чем расширять код, состоящий из «уникальных» косяков.
2.2.3 Пример схемы цветов
Задаём цвета бренда в файле project_styleguide.xml :
2.3 Задаём конфиг
2.3.1 Концепт
Фичи настраиваем на двух уровнях:
отключаем ненужные модули;
меняем параметры внутри самих модулей.
Начнём с того, что зафиксируем правила в типовой форме и пошарим на команду. Настройка нового приложения упрощена: аналитик собирает с клиента требования и присылает форму. Разработчику остаётся механически перевести её в конфиг.
Упрощённый пример дока в формат «модуль-фича-параметры»:
Подключаемые модули:
Аутентификация:
логин пользователя: телефон или email;
Карта лояльности:
тип штрих-кода: EAN-8, EAN-13, CODE-128.
2.3.2 Пути решения
Как сделать качественный конфиг? Само качество определим так:
удобство работы – «простота» чтения, «простота» заполнения (в идеале, хотим DSL);
Скорость обработки – важно, чтобы чтение конфига не тормозило приложение.
Выделим основные пути:
задаём переменные в gradle скрипте;
json объект в файле;
зашит локально, либо получаем с сервера.
Кратко оценим пути по критериям.
2.3.3 Путь №1. Gradle buildConfigField
удобство создания — делаем DSL на минималках: выносим типы и возможные значения параметров в переменные; выявляем синтаксические ошибки на компиляции;
простота — большинству уже знаком;
скорость — обращаемся к классу BuildConfig в памяти.
Главный минус — отвратительная читаемость: переменная состоит из четырёх блоков, подсветки синтаксиса нет.
Пример переменной на условном DSL:
buildConfigField MAIN_SCREEN_TYPE, MAIN_SCREEN_VAR, MS_SHOPS
2.3.4 Путь №2. JSON
удобство чтения — особенно в формате HOCON;
удобство создания — делаем DSL через JSON Schema, проверяем на ошибки по мере написания;
переиспользование — шарим между iOS и Android.
скорость — придётся перед запуском считать из файла или получать с сервера;
время на освоение — по сравнению с первым вариантом JSON Schema наверняка менее популярна.
2.3.5 Так что же лучше?
Когда делали проект, даже не изучали альтернативы. Сразу сделали через Gradle. На мой взгляд, JSON + Schema его побеждает. Удобство чтения — приоритет, при этом удобство создания остаётся на том же уровне, если не лучше. Дополнительная секунда для загрузки файла на общем фоне незначительна.
Сделали конфиг через Gradle, не изучая альтернатив. Но оказалось, что JSON Schema удобнее для чтения – и это её главное преимущество.
2.3.6 Best practices для buildConfigField
при изменение имени или типа переменной придётся делать Find & Replace по всем конфигам.
Дальше настраиваем приложения в скриптах flavor, которые на первом шаге заботливо вытащили по файлам.
2.3.7 Получаем доступ к конфигу
Спроектируем решение в контексте Clean Architecture.
Как сгруппировать параметры по классам? Мы на проекте за группу взяли экран, а зря. С одной стороны, компактные классы, а с другой — возникли коллизии, например на экранах ввода номера телефона и подтверждения кода нужна маска номера. Пришлось реализовать считывание из конфига 2 раза.
С BuildConfig это легко, но с JSON будет грязно. Считаю, что оптимально группировать по процессу (флоу). Под процессом здесь понимаю целевой use case и вторичные по отношению к нему. Обычно это группа экранов, например в модуле лояльности два целевых процесса:
аутентификация — чтобы авторизоваться, придётся ввести логин, а затем код подтверждения;
просмотр дисконтной карты — чтобы получить доступ, нужно сначала её привязать, либо сгенерировать.
Пример реализации конфига для второго процесса: фрагмент BuildCardConfig.kt:
В итоге получим архитектуру работы с конфигом (диаграмма классов UML; в ui MVVM):
UseCase работает только с одним конфигом, ибо в этом классе есть все параметры целевого процесса. Если требуется больше одного — звоночек, похоже UseCase делает много вещей.
2.3.8 Валидируем конфиг
Возникает проблема: если создавать UseCase на каждый параметр, то будет много пустых классов. Ведь правила есть не везде.
Впрочем, если правил у вас субъективно мало и коллизии очевидные, такая валидация не нужна. Мы обошлись без неё и багов из-за этого пока не ловили.
2.4 Настраиваем фичи
2.4.1 Выбираем модули
Мы должны отключать модули, которые не нужны клиенту. Под модулем здесь пониманием связный и независимый кусок функциональности, обычно крупный. Например, модуль «лояльность»: в него входит работа с дисконтной картой и аутентификация.
Модуль здесь – крупный связный и независимый кусок функциональности.
В идеале хочется выпиливать код и ресурсы выключенных модулей из APK. Но на мой взгляд, это оверкилл, поэтому ограничимся функциональным отключением.
Рассмотрим главные точки связи модуля с приложением:
Переходы из ui — боттом навигация, рандомная кнопка, etc;
Реакция на события — кастомные (выбран город), платформы (найдена сеть), etc.
По опыту, обычно хватит убрать пункт модуля из меню, например, для лояльности — это таб из боттом навигации. Я реализовал пример в MainViewModel и MainActivity тестового проекта.
Но бывает, что есть межмодульные переходы, например когда по кнопке из акции попадаем на экран карты – такое придётся обработать отдельно для каждого кейса.
На события в «Лояке» реагирует только модуль пушей. Когда юзер выбирает свой город – подписываемся на соответствующий новостной канал. Опять же обрабатываем каждый кейс.
2.4.2 Настраиваем экраны и бизнес-правила
Настройка конкретных фичей основана на уже спроектированной архитектуре. Например, при отсутствии сети мы хотим показывать карту лояльности из кэша. Однако хотим это настраивать, чтобы отключать кэш для кейсов, когда критична свежесть данных.
Например, получаем карту двумя способами: привязываем физическую или генерируем виртуальную. Не у всех клиентов доступны оба способа, но один гарантирован.
2.4.3 Ещё один трюк
Иногда вариативную вёрстку целесообразнее сделать без конфига.
Вспомним начало поста, хотим показать дисконтную карту – номер, статус, размер скидки и баланс бонусов. Однако процессинг лояльности у клиентов разный, поэтому не все поля гарантированы:
Аналитик собрал наиболее вероятные поля, дизайнер продумал кейсы и переиспользовал вьюхи. Получилось так, что обошлись даже без конфига — смотрим на то, какие данные приходят с бэкенда и показываем необходимое состояние. В тестовом проекте реализован пример — CardInfoFragment.
3 Подведём итог
Мы успешно спроектировали архитектуру White Label android-проекта, которая соответствует поставленным требованиям, а именно позволяет:
✅ развивать общую кодовую базу – расширять модули фичей и собирать из одного кода разные приложения, от 10 до 100;
✅ создавать приложения под клиента – настраивать набор модулей и параметры фичей, менять бренд, делать это относительно быстро (до четырёх часов, по моей оценке).
Горькими уроками поделились, best practices передали. Надеюсь, наш опыт создал цельное представление о создании White Label android-приложений и комфортную отправную точку для вашего проекта.
Напомню, что полный код примера доступен на гитхабе — можно изучить реализацию подробнее, поиграть с настройками. Пример полноценного приложения есть в сторе.
Если возникли вопросы — пишите в комменты, буду рад ответить! А если заинтересовала «Лояка» как продукт, то мы с удовольствием расскажем больше
4 Куда развить решение?
Мы продаём целую систему, а что если продавать модули в другие приложения? Тот же White Label, но на системный уровень ниже. Мы такую задачу решали, если интересно – напишите в комментах, расскажем.
Когда количество приложений растёт, хочется CI и CD. В этом репозитории есть подробный гайд по настройке Azure Devops.
Если не нужна детальная настройка фичей, а писать flavors руками надоело – сделайте автогенерацию flavors по json конфигу.
Бизнес бьёт ключом, клиентов больше сотни? Пора автоматизировать создание приложений.
Если знаете кейсы, на которые нет ссылок в нашей статье, то обязательно скиньте их в комменты – вместе мы точно соберём крутую библиографию!