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

Як розробити мобільний додаток для інтернет-магазину на Бітрікс?

Запит на мобільний додаток виникає, коли адаптивна верстка вже є, конверсія з мобільного трафіку — 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: «Ціна на товар змінилася.»

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