Феникс для Бургер Кинг

Новая архитектура мобильного приложения для одной из крупнейших сетей бургерных в мире

Что сделали — главное

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

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

Как сделали продукт уникальным

Мы не начинали с технологий. Мы начали с вопросов: что мешает бизнесу двигаться быстрее? Почему каждая фича — это боль? Где узкие места?

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

• Модульность вместо монолита. Каждая бизнес-фича — отдельный модуль со своей логикой, моделями, экранами. Корзина не знает про меню. Меню не знает про купоны. Изменения локализованы, влияние на остальной продукт предсказуемо.
• Прозрачные зависимости. Все связи между модулями — только сверху вниз. Никаких горизонтальных «шорткатов». Чтобы использовать что-то из другого модуля, нужно явно его подключить. Это видно на ревью. Это контролируемо.
• Параллельная разработка. Несколько команд могут работать над разными фичами одновременно, не мешая друг другу. Нет сложных мердж-конфликтов. Нет «подождите, пока мы закончим».

Вынесли архитектуру на внешний аудит. Получили рекомендации экспертов и адаптировали решение: на iOS перешли с MVP на MVVM для совместимости с SwiftUI, на Android закрепили MVI как единый подход с Compose и Coroutines.

Модульность: быстрее релизы, меньше багов

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

Если бэкенд меняет формат ответа для корзины, мы меняем только модуль корзины. Не трогаем экраны. Не трогаем другие фичи. Это снижает риски и ускоряет релизы.

Структура для масштабирования команд

Мы спроектировали архитектуру из трёх уровней:

• App-модуль — точка входа, соединяет всё вместе
• Сервисные модули — общий функционал без бизнес-логики: сеть, геолокация, аналитика
• Feature-модули — бизнес-логика конкретных фич

Такая структура масштабируется. Новые разработчики быстрее погружаются. Команды работают автономно.

Гибкая навигация: легко менять пути пользователя и запускать A/B-тесты

Раньше логика навигации была вплетена в сами экраны. Это усложняло работу с диплинками и A/B-тестами.

Теперь навигация — отдельный модуль. На iOS — координаторы. На Android — Surf Navigation, построенная на тех же принципах, что и популярная Cicerone. Экраны не знают, куда ведут переходы. Навигацию можно менять, не трогая UI.

Современный UI: быстрее разработка типовых экранов

На iOS используем SwiftUI для простых экранов и UIKit со SnapKit для сложных. Выбор MVVM упрощает совместную работу обоих фреймворков и готовит почву для полного перехода на SwiftUI в будущем.

На Android — Jetpack Compose как основной UI-фреймворк в паре с MVI. Управление состоянием предсказуемо. Разработка быстрее.

Технологии под задачи: проще поддержка, быстрее онбординг

Мы не собирали стек ради стека. Каждый выбор обоснован:

• Coroutines вместо RxJava — это часть языка Kotlin, проще в поддержке, легче онбординг новых разработчиков
• NodeKit на iOS — гибкий сетевой слой поверх URLSession, не нужно писать обёртки с нуля
• SPM как основной менеджер зависимостей — Cocoapods оставили временно только для Firebase, планируем полный переход
• Factory для DI — легковесный, гибкий, быстрее Swinject на старте приложения

Тестирование модулей: предсказуемые релизы без критичных багов

Каждый модуль можно тестировать отдельно. Для UI — Snapshot-тесты компонентов. Для логики — Unit-тесты ключевых сервисов.

Snapshot-тесты работают только с локальной ViewModel, без зависимости от дата-слоя. Фичи не привязаны к конкретным данным.

Цель — поднять покрытие с 20% до 70%. Не ради красивых цифр, а ради предсказуемых релизов без критичных багов.

Управление фичами с сервера: релизы без обновления в сторе

В продукт заложили систему Feature Toggle: включать и выключать фичи с сервера, без релиза в стор.

Полноценный Server-Driven UI не планируем — это избыточно для задач клиента. Но точечное применение SDUI там, где нужно (порядок блоков на экране, конфигурация промо) — да.

Плавная миграция: бизнес работает, пока мы переводим трафик

За 9 месяцев мы не просто собрали новое приложение. Мы спланировали, как аккуратно перевести трафик с монолита.

Бизнес продолжал работать. Требования менялись — архитектура позволяла гибко работать со скоупом, не обнуляя уже сделанное.

Первая версия выходит на часть пользователей в конце 2025 года. Полная раскатка — начало 2026.

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

Бургер Кинг

Команда digital-развития