Что это на практике
Одна кодовая база — много опубликованных приложений. У каждого бренда своя карточка в магазине, название, иконка, палитра и контент, и всё это собрано из общего исходника. Смысл в экономике: двадцатое приложение стоит доли первого, потому что первое оплатило платформу.
Заказчики устроены похоже. Агентства, перепродающие приложения своим клиентам. Франшизы, где каждому региону нужно своё присутствие в магазине. Мультибрендовые операторы с портфелем марок. Образовательные платформы и сообщества, выпускающие приложение на автора. Общая фраза всегда одна: «мне нужно десять или пятьдесят, и я не могу оплатить десять проектов разработки».
Четыре слова, которые путают между собой
| Что меняется под клиента | Сколько кодовых баз вести | |
|---|---|---|
| Перекраска | Логотип, цвета, название | Одна — но приложения остаются одним продуктом |
| Форк | Что угодно | По одной на клиента, расходятся с первого дня |
| Мультитенантность | Данные и контент, один деплой | Одна, одно приложение |
| White-label | Идентичность на сборке, контент и функции в рантайме | Одна, много приложений |
Форк — честный ответ для двух клиентов с по-настоящему разными продуктами. Мультитенантность — то, что делает SaaS, когда у всех одно приложение и различаются только данные. White-label — случай, когда каждому клиенту нужно своё приложение в своей карточке магазина, и именно эта карточка всё усложняет.
Чем это отличается от перекраски
Правило App Store Review Guideline 4.2.6 существует, чтобы удалять приложения, сгенерированные из шаблона, — а набор приложений с одинаковыми экранами и одинаковыми данными под разными логотипами ровно под это описание и подходит. Отказы здесь недобрые: приложения снимают после месяцев в проде, целые флоты застревают в ревью, аккаунты разработчика получают метку.
Вывод, который из этого обычно делают, неверен: будто из одной кодовой базы нельзя выпускать много приложений. Можно. Проблема никогда не в общей кодовой базе — она в том, что приложения оказываются одним продуктом в разных шляпах.
Слоёв дифференциации два, и почти все делают только первый.
Визуальная тема даёт каждому приложению свои цвета, типографику, логотип, сплэш, название, идентификатор бандла и иконку. Это необходимо и это минимум. Само по себе — ровно то, что 4.2.6 отклоняет.
Слой «клиент — сервер» и есть настоящая дифференциация. Каждое приложение аутентифицируется на бэкенде как отдельный тенант и вытягивает свой мир: свой контент, свой каталог, свои данные, свой набор функций за пофлаговыми переключателями тенанта, свою удалённую конфигурацию. Два приложения, собранных из одного бинарного чертежа, становятся по-настоящему разными продуктами в момент, когда стартуют и обращаются к серверу.
Тема заставляет приложение выглядеть иначе. Серверный слой заставляет его быть иным — и ревьюер, открывший два таких приложения, видит два продукта, а не одно приложение дважды.
Что спросить у подрядчика
- Что меняется в рантайме, а не только на сборке? Если ответ — только тема и название, вы покупаете перекраску, и 4.2.6 за ней придёт.
- Под чьими аккаунтами разработчика выходят приложения? Брендам часто нужно публиковаться под собственным издателем, а не под вашим.
- Сколько стоит двадцатое приложение? Если примерно столько же, сколько первое, платформы под этим нет — есть скрипт сборки.
- Как заводится новый бренд? Форма в админке означает, что это масштабируется. Инженер, правящий конфигурацию сборки под каждого клиента, — что нет.
Когда это неправильный ответ
Когда клиентов двое, а не двадцать. Работа над платформой — модель тенантов, пайплайн сборки, конфигурация под каждого — это вложение, которое окупается только на флоте; два форка вышли бы раньше и дешевле.
Неправильно и тогда, когда каждому клиенту нужны функции, которые остальным не понадобятся никогда. Общая кодовая база, впитывающая по-настоящему расходящиеся продукты, превращается в груду условий, которые никто не рискнёт трогать, — и тут форк, которого вы избегали, оказывается тем самым форком, который нужен.
Но если флот реален, рычаг необычный: новый бренд проходит путь от отправки формы до подписанного бинарника в нужном аккаунте магазина без участия инженера.
Длинная версия — архитектура, пайплайн сборки и стратегия подачи в магазин — в статье как мы выпускаем 20+ брендированных приложений из одной Flutter-кодовой базы, а страница услуги — разработка white-label приложений.