MCBUY: как связали приложение для iOS и Android с интернет-магазином

У MCBUY уже работал интернет-магазин, созданный командой. Новому приложению для iOS и Android нужны были те же каталог, заказы, оплата и доставка. Команда использовала торговую основу сайта и общий мобильный интерфейс на Vue и Apache Cordova.

Покажу на пути от каталога к заказу, как приложение взаимодействует с магазином, что удалось использовать от сайта и какие задачи остались отдельными для каждой платформы.

Торговая основа уже была на сайте

Приложение должно было сделать выбор одежды удобным и дать магазину канал маркетинговых сообщений при разумном бюджете. У сайта и приложения общие торговые задачи: показать сведения о товаре, обработать корзину, рассчитать заказ с учётом доставки и скидок. Общая основа — backend сайта на «1С-Битрикс» и база данных (БД). Backend обменивается с 1С данными о товарах и заказах в обе стороны; к нему же подключены интеграции с оплатой и доставкой.

Мобильный интерфейс написан на Vue. Он показывает экраны и реагирует на действия покупателя — это frontend, клиентская часть. Backend — серверная часть — обрабатывает данные магазина и заказы. С ним работают два клиента: веб-интерфейс магазина и приложение на Vue для iOS и Android. Мобильный клиент обменивается с backend запросами и ответами через API — интерфейс взаимодействия программ.

В центре — backend сайта и БД. Два клиента используют эту основу; обмен с 1С двусторонний, оплата и доставка подключены к backend.

Один интерфейс для двух платформ

Чтобы этот интерфейс работал на iOS и Android, использовали Apache Cordova. Она запускает HTML, CSS и JavaScript внутри WebView — встроенного браузерного компонента мобильного приложения. У каждой платформы своя оболочка, а веб-код остаётся общим.

В MCBUY каталог, карточка товара, корзина и навигация разрабатываются в одной кодовой базе Vue. Исправление общего компонента можно включить в обе сборки. Это сокращает дублирование работы над интерфейсом и помогает поддерживать одинаковые сценарии покупки.

Связь с возможностями устройства обеспечивают плагины Cordova. Например, в клиенте предусмотрен переход к связанному экрану после нажатия на push-уведомление: сообщение магазина может привести покупателя к конкретному содержимому приложения.

При этом сборки, разрешения, плагины и проверка на устройствах требуют отдельной работы для iOS и Android. Общий код объединяет разработку интерфейса; платформенные задачи остаются частью проекта.

От каталога к товару: переход и ожидание данных

Покупатель открывает товар из каталога. В обычном переходе между веб-страницами браузер загружает новый документ. Клиент MCBUY работает как SPA — Single Page Application: после запуска JavaScript управляет переходами и обновляет нужные части интерфейса.

За выбор экрана отвечает Vue Router. Он выбирает компонент карточки товара, клиент получает данные через API, а Vue показывает их. Общая навигация остаётся частью приложения; серверу не требуется заново отправлять целую HTML-страницу для этого перехода.

Пока данные загружаются, покупатель видит прелоадер — вращающийся круг на полупрозрачном фоне. CSS-анимация связана с состоянием запроса: ожидание сменяется содержимым, а при ошибке предусмотрено сообщение. Так у действия есть видимый отклик. Индикатор показывает ожидание ответа; сам по себе он не ускоряет API и не подгружает следующие экраны заранее.

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

Браузерная версия приложения на 15 сентября 2026 года. На экране показана типовая таблица размеров; обмеры конкретного изделия — отдельная функция.

От действия покупателя к расчёту заказа

При оформлении заказа одного обновления экрана уже недостаточно. Если покупатель меняет доставку или применяет промокод, приложению нужен результат серверного расчёта. Vue передаёт выбор через API и отображает ответ.

Здесь появляется второй роутер. Vue Router выбирает экран на устройстве, а роутер «Битрикс» направляет запрос к серверному обработчику. Это две разные задачи в одном действии покупателя.

На сервере используются штатные механизмы Bitrix Framework:

• RoutingConfigurator из Bitrix\Main\Routing связывает HTTP-метод и шаблон адреса с обработчиком. В API проекта есть маршруты чтения и изменения данных.
• Controller из Bitrix\Main\Engine служит основой контроллеров. Их действия вызывают торговую логику и возвращают результат клиенту.
• JSON — формат, в котором клиент получает данные, статус и ошибки для дальнейшего отображения.

Путь запроса: действие в Vue → запрос API → маршрут → действие контроллера → торговая логика → JSON → обновление экрана.

Так разработчик может отдельно работать с представлением заказа и с его серверной обработкой. Пока формат обмена сохраняется, изменение интерфейса не обязательно требует изменения API. Если меняется сам формат, работу клиента и сервера нужно согласовать. Проверки доступа и входных данных также относятся к серверной части.

Что можно обновлять вместе, а что отдельно

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

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

Получаются два уровня переиспользования: общий клиент для iOS и Android и общие серверные возможности для сайта и приложения. На каждом уровне остаётся своя работа: интерфейс, платформенная оболочка, торговая логика или содержание магазина.

Как это влияет на нагрузку

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

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

Есть и цена начальной загрузки: приложению нужно загрузить JavaScript и запустить клиент. Поэтому первый показ и последующие переходы оценивают отдельно. Эффект такой архитектуры оценивают по времени запуска приложения, числу и длительности запросов, а также нагрузке на сервер.

Что получил MCBUY

Новое приложение выпущено в мае 2025 года взамен прежнего и доступно в App Store и Google Play. Приложение использует общий код клиентской части для двух платформ и связано с действующей торговой системой магазина. Покупатель переходит между экранами без полной перезагрузки и видит индикатор, пока загружаются данные. При возврате из карточки товара назад в каталог восстанавливается прежняя позиция прокрутки: можно продолжить просмотр с того же участка списка.

В отзывах App Store за июнь–июль 2025 года пользователи отмечали удобство поиска, избранного, корзины и оформления заказа.

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