Разработка мобильного приложения для интернет-магазина на Битрикс

Как разработать мобильное приложение для интернет-магазина на Битрикс?

Запрос на мобильное приложение возникает, когда адаптивная вёрстка уже есть, конверсия с мобильного трафика — 0.8% против 2.5% на десктопе, а маркетинг хочет push-уведомления, которые в мобильном Safari не работают. Вопрос не «зачем приложение», а какой подход выбрать — PWA, кроссплатформа на React Native, или нативная разработка — и как правильно связать это с Битрикс. Мы выбираем подход под конкретный бюджет и цели, опираясь на 9+ лет опыта в Битрикс и 50+ реализованных проектов. При правильном выборе подхода окупаемость составляет 6-12 месяцев, а стоимость разработки варьируется в зависимости от функциональности.

Почему React Native — выбор для большинства магазинов?

React Native даёт в 2-3 раза более быстрый запуск по сравнению с нативной разработкой при сохранении нативного UX. Битрикс выступает бэкендом, отдаёт данные через REST API. Если для веб-версии уже написаны кастомные API-эндпоинты (headless), приложение переиспользует их без изменений.

Архитектура:

React Native App → HTTPS → API Gateway → REST API Битрикс → ORM → MySQL 

Ключевые REST-методы: catalog.product.list, sale.basket.addItem, sale.order.add. Но стандартного REST недостаточно. Пишем кастомные эндпоинты через \Bitrix\Main\Engine\Controller:

• /api/mobile/catalog/list — облегчённый ответ для списка (ID, название, цена, превью)
• /api/mobile/catalog/detail — полная карточка с торговыми предложениями
• /api/cart/calculate — пересчёт корзины с учётом скидок
• /api/checkout/delivery-options — расчёт стоимости доставки

Почему отдельные эндпоинты? Размер ответа. На 3G каталог из 50 полей на товар убивает UX. Мобильный эндпоинт возвращает 7–8 полей для списка.

Как курсорная пагинация решает проблему дублей?

На вебе пагинация по страницам (page=3&limit=20) работает. На мобильном — пользователь листает ленту бесконечным скроллом. Если между запросами добавляется новый товар — дубли. Решение — курсорная пагинация. Каждый ответ содержит cursor (ID+timestamp последнего). Следующий запрос передаёт cursor вместо номера страницы.

GET /api/mobile/catalog/list?section_id=15&cursor=...&limit=20 

На стороне Битрикс курсор декодируется в WHERE ID < 1500 ORDER BY ID DESC LIMIT 20 — стабильная выборка независимо от новых товаров.

Push-уведомления: архитектура и сценарии

Push — главное преимущество приложения. Архитектура:

1. Device-токен — приложение регистрируется в FCM или APNs, получает токен, отправляет на сервер через /api/push/register.
2. Хранение токенов — кастомная таблица в Битрикс: USER_ID, DEVICE_TOKEN, PLATFORM, CREATED_AT.
3. Генерация события — обработчик OnSaleStatusOrder или агент для брошенных корзин формирует payload.
4. Отправка — HTTP POST в FCM API v1 с токеном, заголовком, текстом и deeplink.

Сценарии:

• Статус заказа — событие OnSaleStatusOrder
• Брошенная корзина — через 30 минут после добавления (агент CAgent)
• Снижение цены — товар из избранного подешевел
• Персональные акции — через сегментацию CRM

Используем @react-native-firebase/messaging для приёма push, react-native-push-notification для локального отображения.

Что даёт офлайн-режим?

При первом запуске приложение загружает каталог через REST API порциями по 100 товаров и сохраняет в локальную SQLite. Изображения кешируются через react-native-fast-image. Дальше — дельта-синхронизация. Эндпоинт /api/catalog/delta?since=... возвращает только изменённые товары. На стороне Битрикс:

SELECT ID, NAME, PREVIEW_PICTURE, DETAIL_PAGE_URL FROM b_iblock_element WHERE IBLOCK_ID = 15 AND TIMESTAMP_X > ? AND ACTIVE = 'Y' 

Плюс отдельный запрос на удалённые товары. Корзина в офлайне — сохраняется локально, при появлении сети синхронизируется с сервером с проверкой актуальных цен. Приложение показывает diff: «Цена на товар изменилась с 1500 на 1350 руб.»

Checkout и оплата из приложения

Оформление заказа — технически сложный экран. Последовательность:

1. Адрес доставки — автодополнение через DaData или сохранённый адрес
2. Расчёт доставки — запрос к /api/checkout/delivery-options с адресом и корзиной. Битрикс вызывает обработчики (СДЭК, Boxberry), возвращает варианты с ценами и сроками
3. Выбор оплаты — список из sale.paySystem.getList
4. Промокод — проверка через кастомный endpoint, пересчёт суммы
5. Подтверждение — sale.order.add

Оплата картой — через SDK платёжного шлюза (ЮKassa, Apple Pay, Google Pay). SDK открывает нативный экран оплаты, обрабатывает 3D Secure, возвращает результат. После оплаты Битрикс получает callback от шлюза на /bitrix/tools/sale_ps_result.php и выставляет PAYED = 'Y' в b_sale_order.

Сравнение подходов

PWA обходится в 5 раз быстрее React Native, но не подходит для сложных сценариев. React Native — золотая середина для 90% магазинов. Нативная разработка нужна только при экстремальных требованиях к производительности.

Что входит в работу

При заказе разработки под ключ:

• техническое задание с архитектурой и прототипами
• репозиторий с кодом (GitHub/GitLab), настроенный CI/CD
• документация по развёртыванию и интеграции с Битрикс
• инструкция по публикации в App Store и Google Play
• обучение администраторов push-уведомлениям и обновлению контента
• гарантия на код — 12 месяцев бесплатного исправления ошибок

Сроки по масштабу

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

PWA — MDN Web Docs: Progressive Web Apps