Феникс: трансформация мобильного приложения Бургер Кинг за 16 месяцев

Мобильное приложение Бургер Кинг — один из главных каналов продаж крупнейшей сети бургерных в России с аудиторией в более чем 6 миллионов пользователей. Surf несколько лет развивали его как технологический партнёр: вели поддержку, выпускали новые фичи, проводили редизайн. Приложение вышло на первое место в категории «Еда и напитки» в App Store и Google Play и остаётся в топовых позициях в сторах. Это был зрелый продукт с сильной аудиторией.

Но у бизнеса появились амбиции, для которых нужен был принципиально новый фундамент. Быстрый запуск промо-механик, кастомизация заказов, динамические сценарии, гибкое A/B-тестирование, масштабирование на другие каналы — всё это требовало архитектуры, спроектированной под рост. Нужно было не оптимизировать существующее решение, а создать платформу, на которой бизнес сможет двигаться в разы быстрее.

Мы вместе с командой разработки бэкенда ZeBrains предложили стратегический шаг — собрать новое приложение с нуля. Полностью переписать фронтенд под iOS и Android, а параллельно — заново спроектировать бэкенд на микросервисной архитектуре. При этом сохранить весь привычный для пользователей функционал и обеспечить бесшовный переход — чтобы миллионы людей даже не заметили, что под капотом сменилось всё.

Мы начали с аудита и проектирования. Разобрали архитектуру, бизнес-процессы и все бутылочные горлышки. Вынесли архитектурное решение на внешний аудит — получили рекомендации независимых экспертов и адаптировали подход. Только после этого зафиксировали стратегию.

Сформировали пять принципов, на которых будет построено новое приложение:

1. Модульность. Каждая бизнес-фича живёт в собственном модуле: корзина, меню, купоны, лояльность — всё изолировано. Изменения в одном месте не ломают другое. Несколько команд работают параллельно, не мешая друг другу. Новые разработчики быстро погружаются — потому что работают с понятным, ограниченным контекстом, а не с огромной кодовой базой целиком.

2. Современный стек. Мы, как команда фронтенда, решили полностью перейти на SwiftUI на iOS и на Jetpack Compose на Android. Команда бэкенда параллельно разрабатывала бэкенд. Выбор технологий определялся тем, что каждая ускоряет разработку, упрощает поддержку и даёт возможности, которых раньше не было.

3. Три направления параллельно. Фронтенд и бэкенд разрабатывались одновременно двумя командами. Это позволило уложиться в сжатые сроки – за 16 месяцев выпустили новое приложение.

4. Бесшовная миграция. При релизе нового приложения старое работало параллельно. Composition Layer маршрутизировал запросы, обеспечивал прозрачность для пользователя и давал возможность мгновенного отката. 

5. Полнота функционала с первого дня. Бизнес поставил чёткое условие: в новом приложении должно быть всё, к чему привыкли пользователи. Авторизация, программа лояльности, купоны, множество способов оплаты, меню, корзина и новые дополнительные фичи для вовлечения клиентов — джекпот, рулетка комбо и более нативный онбординг для новых пользователей.

Стратегия, зафиксированная до начала разработки, позволила избежать хаотичных решений в процессе. Бизнес получил прогнозируемые сроки и понятный план перехода без остановки продаж через мобильный канал.

Обычно разработка стартует, когда готово ТЗ. Мы поступили иначе. Пока аналитики и дизайнеры на стороне Бургер Кинг прорабатывали требования и макеты, наши разработчики на каждой платформе уже закладывали техническую базу — то, что гарантированно понадобится независимо от конкретных бизнес-требований.

Начали с проектирования многомодульной архитектуры. Для iOS и для Android команда спроектировала структуру с нуля, учитывая опыт предыдущих проектов. Определили стек технологий и зафиксировали его: на iOS — MVVM + Coordinators, SwiftUI, Combine, Factory (DI), NodeKit; на Android — MVI, Jetpack Compose, Coroutines, Hilt (DI), Ktor. Каждая технология — современная, позволяющая масштабировать приложение без дополнительной разработки.

Параллельно спроектировали модуль навигации, включая полноценную систему диплинков. Диплинки — это точка входа для маркетинга: push-уведомление ведёт к конкретному купону или блюду. На прошлых проектах их реализацию часто откладывали на потом. Мы продумали механизм заранее — и когда пришло время интеграции в бизнес-фичи, это заняло в 2 раза меньше времени.

Как только у дизайнеров Бургер Кинг появились первые макеты — мы начали реализовывать UI Kit: тему приложения, стили текста, цвета, базовые компоненты. Это позволило масштабировать команду: к моменту старта активной разработки фичей каркас уже был готов, и разработчики разного уровня могли сразу включаться в работу — собирать экраны как конструктор из проверенных компонентов.

Без этого этапа первые месяцы активной фазы ушли бы на хаотичное создание инфраструктуры, а риск запутанного кода при быстром масштабировании команды вырос бы кратно. Два месяца подготовки сэкономили время на всех последующих этапах.

Архитектуру нового iOS-приложения выстроили на базе SPM-пакетов с жёсткой иерархией из четырёх уровней:

1. На нижнем — Core Layer: расширения системных классов, ресурсы (цвета, шрифты, локализация), доменные модели, протоколы взаимодействия, базовая реализация сетевого слоя и кэша. 

2. Выше — Middle Layer: сервис работы с данными и DTO, общие бизнес-сервисы (геолокация, корзина), библиотека переиспользуемых UI-элементов, аналитика. 

3. Далее — Feature Layer с модулями конкретных фич: авторизация, каталог, боттомшиты. 

4. И наконец, Main Layer — точка входа в приложение.

Ключевое правило: модули связаны строго сверху вниз. Горизонтальных зависимостей нет — feature-модули не знают друг о друге. Каждый пакет можно менять, тестировать и даже заменять целиком, не трогая остальное приложение. Поддерживать и развивать такую систему значительно проще. Например, можно добавить новую фичу без затрагивания других слоев и модулей.

Мы полностью перешли на SwiftUI — современную технологию для вёрстки, которая хорошо совместима с новыми версиями iOS и ускоряет разработку типовых экранов.

Отдельного внимания заслуживает работа с DI (Dependency Injection) — технологиями для снижения технического долга и быстрой дальнейшей разработки. Внедрили контейнер Factory и сократили время на отладку техдолга с полугода до месяца.

Принципиально переработали логику работы с данными. В прежнем приложении при каждом запуске заново загружалась огромная база данных блюд — с модификаторами, связями групп, зависимостями. Мы перепроектировали подход: теперь приложение загружает с бэкенда только минимально необходимые данные. Потребность в массивном кэше отпала.

Теперь бэкенд отдаёт актуальные цены и информацию в реальном времени, а не вчерашние данные из локального хранилища. Отказ от тяжёлого кэша означает, что пользователи видят актуальные цены и информацию о блюдах в реальном времени, а не устаревшие данные.

Параллельно с iOS велась разработка для Android. Архитектура — также многомодульная, но со своей структурой, адаптированной под специфику платформы.

Здесь мы создали три уровня: 

1. App-модуль как точка входа;

2. Сервисные модули (Network, Database, Platform, Core, Core-UI) — общий функционал без бизнес-логики;

3. Feature-модули — бизнес-логика конкретных фич. Каждый Feature-модуль может включать до четырёх подмодулей. Внутри — разделение по слоям Clean Architecture. Для связи между фичами используются интерфейсные модули — это сохраняет независимость реализаций друг от друга.

Мы сделали ставку на Jetpack Compose как основной UI-фреймворк. Он позволяет реализовывать интерфейсы быстрее, делать сложные анимации и переходы, которые раньше потребовали бы непропорционально больше времени.

Использовали гибридный подход: фрагменты как контейнеры экранов, а весь UI рисуется на Compose. Это осознанное решение — оно обеспечивает совместимость с внешними библиотеками (например, Яндекс.Карты, которые пока не поддерживают чистый Compose) и стабильную навигацию.

Технологический стек собран из проверенных, актуальных решений: Ktor для работы с сетью (из коробки поддерживает SSE — больше не нужно писать кастомные решения), Coroutines для асинхронных операций (легковесные, быстрые, проще в освоении, чем RxJava), Hilt для DI, Coil для загрузки изображений, Kotlinx.serialization для сериализации, Surf Navigation на основе Cicerone. Каждый инструмент делает разработку быстрее, а приложение — стабильнее для пользователя.

Разработчики активно использовали AI в процессе: генерировали Compose-код по макетам из Figma — загружали ссылку на дизайн, и ИИ выдавал готовый UI-код. Это ускорило верстку в 2 раза и позволило быстрее выходить на ревью.

Внедрили новые функциональности:

1. Видеобаннеры и анимацию, чтобы пользователям было легче выбрать блюдо и оно совпало с их ожиданиями. 

Джекпот — эффектная анимированная рулетка с барабанами, где можно выиграть короны. Технически это именно тот случай, когда Compose раскрывается в полную силу: сложная анимация работает без костылей, не тормозит и эффективно использует ресурсы устройства пользователя.

Сборка комбо из меню — возможность собрать собственное комбо из разных блюд буквально в два шага, не проваливаясь в карточку комбо.

Функциональности с джек-потом и сборкой комбо — инструменты вовлечения, которые стимулируют повторные визиты и повышают активность в программе лояльности.

История покупок — простая фича, но её не было в предыдущей версии. Теперь пользователь видит полный список всех купленных товаров — удобно для повторных заказов.

Всё меню за короны. Раньше за бонусные короны можно было купить только определённые товары из специального раздела. Теперь — любое блюдо из всего меню. Это серьёзное изменение в логике лояльности, которое потребовало доработок и на фронтенде, и на бэкенде.

Более точечный онбординг — в новом приложении подсказки встроены в пользовательский путь и появляются в релевантные моменты взаимодействия с продуктом. Это помогает пользователю быстрее разобраться в ключевых сценариях, снижает нагрузку на старте и способствует удержанию новичков.

Реализация на Compose при этом получилась проще и элегантнее, чем в предыдущей версии.

При этом мы полностью сохранили весь функционал, к которому привыкли пользователи: авторизацию по номеру телефона, программу лояльности с коронами, купоны и множество способов оплаты — Яндекс Пэй, СБП, банковские карты и другие. Теперь пользователи быстрее оформляют покупки, а отмены составляют менее 1%.  

Новое приложение — не только свежий интерфейс. За ним стоит полностью переработанный бэкенд, спроектированный с нуля как система независимых доменных сервисов. Им занималась экспертная команда ZeBrains — лидер в цифровой трансформации и AI-решениях.

Работу начали с декомпозиции бизнес-логики совместно с командой Бургер Кинг. Определили доменные области и разделили их на независимые сервисы: заказы и корзина, каталог продуктов и рестораны, цены и конфигурации, пользователи и аутентификация, платежи и чеки, лояльность и CRM/CDP, уведомления, чат и отзывы, аналитика и экспорт данных. Каждый сервис получил чёткую зону ответственности и собственную базу данных.

Ключевой архитектурный элемент — Composition Layer (API Gateway), разработанный и поддерживаемый командой ZeBrains как прослойка между фронтендом и доменными сервисами. Это единая точка входа для мобильного приложения, которая изолирует клиентскую часть от внутренних изменений в сервисах: изменения бэкенда (новые фичи, оптимизации) не требуют правок на iOS/Android, если контракт API остаётся неизменным. Благодаря этому разработка ускоряется — команды фронтенда и бэкенда работают параллельно, что позволяет бизнесу выводить промо-механики и обновления в разы быстрее, сохраняя стабильность 99,95%.

Composition Layer решал ещё одну стратегическую задачу — обеспечивал безопасную параллельную работу старой и новой систем. Маршрутизация запросов прозрачна для пользователя: если что-то идёт не так — мгновенный откат на старую систему без последствий.

Бизнес-логику прорабатывали совместно с аналитиками: переводили требования в работающие сценарии, детально проработали граничные случаи и исключения, обеспечили согласованность данных между сервисами. Подготовили интеграции с внешними системами и партнёрами.

В архитектуру заложили принципы, которые определяют запас прочности на годы вперёд: нет единой точки отказа, независимое масштабирование сервисов, возможность держать нагрузку в 4 раза выше текущей, добавление новых доменов без переписывания ядра, возможность адаптации под другие платформы.

Со стороны Surf для параллельной разработки использовали собственный мок-сервер: пока бэкенд был в разработке, команда фронтенда работала без простоев. Контракт взаимодействия (API-contract) был согласован заранее — обе стороны следовали ему независимо, что исключило блокировки и сократило время интеграции.

На «Фениксе» тестирование не было финальным шагом — оно шло параллельно с разработкой, благодаря чему мы все успели в срок.

Скриншот-тесты (snapshot-тесты) — впервые внедрены на проекте, и сразу доказали свою ценность. Автоматически генерируются скриншоты каждого экрана и компонента. При внесении изменений новые скриншоты сравниваются с эталонными. Разработчик видит, где что-то пошло не так до момента, когда сборка попадёт к тестировщику. На Android более 50% UI уже покрыто скриншот-тестами — и этот показатель растёт. Особенно критично для Android с его огромным парком устройств: невозможно вручную проверить каждый экран на каждом разрешении, а snapshot-тесты делают это автоматически.

Реальный пример: одна из доработок потребовала увеличить шрифт у нескольких стилей текста. Разработчик посмотрел на новые сгенерированные скриншоты, сразу увидел, где вёрстка поехала, обратился к дизайнерам — и всё это без единого ручного прохода по приложению.

Unit-тесты — покрытие выросло с 20% до целевых 70%. Модульная архитектура сделала изолированное тестирование реальностью: каждый модуль тестируется отдельно, без зависимости от соседних фич или внешних данных.

UI-тесты — автоматические сценарии, которые прокликивают приложение и сверяют результат с ожидаемым. Ключевые пользовательские пути проходятся без ручного участия.

ИИ в тестировании. Наши разработчики используют AI для генерации unit-тестов — это ускоряет написание и наращивает покрытие без пропорционального роста трудозатрат. Инструмент уже стал частью повседневного процесса.

Нагрузочное тестирование бэкенда. Симуляция трафика миллионов пользователей, поиск узких мест, оптимизация критических путей. Нагрузочное тестирование идёт непрерывно — при каждом изменении система проходит проверку на устойчивость.

Конец декабря 2025 — выпустили новое приложение в Google Play. Точно в запланированный срок. Первая аудитория — 5% пользователей. Цель была в том, чтобы собрать обратную связь, отловить edge-кейсы в реальных условиях и убедиться в стабильности всей системы. На этом этапе пользователи нам помогли:

1. Отметили мелкий шрифт — мы его быстро увеличили. 

2. Обнаружили на Android нетривиальный кейс: устройства с Android 12 и ниже не имеют системного запроса разрешения на push-уведомления (он появился только в Android 13). Приложение ожидало ответа, который никогда не приходил — экран зависал на сплэш-скрине. Один из пользователей записал видео с проблемой, наши тестировщики разобрались в причине, и команда быстро добавила проверку с обходом. Пользователю, помогшему найти баг, начислили короны — потому что взаимодействие с реальной аудиторией для нас очень важный элемент разработки.

Непрерывно мониторим конверсионные и технические метрики. При обнаружении проблем останавливаем раскатку, исправляем ошибки, продолжаем.

Сроки и масштаб.

За 1 месяц провели аудит, спроектировали архитектуру и зафиксировали стратегию. За 10 месяцев с нуля разработали фронтенд под iOS и Android со всем функционалом. Команда ZeBrains за 16 месяцев спроектировали, разработали и протестировали новый бэкенд на микросервисной архитектуре. Релиз на 5% пользователей состоялся в декабре 2025 — точно в срок.

Качество.

Покрытие unit-тестами выросло с 20% до 70%. Более 50% UI покрыто скриншот-тестами — и этот показатель продолжает расти. Внедрена стратегия тестирования, выстроенная по классической пирамиде тестирования (test pyramid): фундамент составляют unit-тесты, обеспечивающие покрытие бизнес-логики, над ними — интеграционные и snapshot-тесты, на верхнем уровне — E2E/UI-тесты. Параллельно запущено непрерывное нагрузочное тестирование бэкенда. Такой подход гарантирует оптимальный баланс между скоростью обратной связи, стоимостью поддержки тестов и глубиной покрытия.

Технологии.

Обе платформы полностью переведены на современные UI-фреймворки: SwiftUI на iOS и Jetpack Compose на Android — это ускоряет разработку интерфейсов и делает возможными сложные анимации, которые раньше были бы нерентабельны по срокам.

Бэкенд перестроен в систему независимых микросервисов с собственными базами данных и единой точкой входа (Composition Layer). Архитектура выдерживает нагрузку в 4 раза выше текущей и допускает рост без переписывания ядра.

Бизнес-эффект.

Финансовые и продуктовые результаты:

— Инкрементальная выручка: +0,8 млрд руб.

— Средний чек: +6,8 руб.

— Конверсия в оформление заказа: +1,8 п.п.

— MAU: >6 млн

— Процент отмен: 95%

Команда разработки мобильного приложения осталась практически той же — масштабирования штата и дополнительных затрат не потребовалось. Время на отладку техдолга сократилось с полугода до месяца. Новые фичи и промо-механики запускаются быстро и безопасно — архитектура больше не является ограничителем для бизнеса.

Что дальше.

«Феникс» стал не просто приложением, а платформой, рассчитанной на годы развития. В ближайших планах — внедрение A/B-тестирования через Traffic Control, переписывание сервиса лояльности в связи с переходом на новую CDP-платформу и унификация бэкенда всех каналов Бургер Кинг: мобильное приложение, киоски, драйвы и веб-сайт переходят на единый бэкенд. Это первый шаг к цельной цифровой экосистеме бренда.