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

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

Мобільний трафік в e-commerce давно перевищив десктопний, а адаптивна вёрстка часто недостатня. Нативний або гібридний додаток дає push-сповіщення, офлайн-доступ до каталогу й ощутимо швидший інтерфейс. Для інтернет-магазину на 1С-Бітрікс існує три принципово різних підходи: PWA, кросплатформна розробка через REST API та готовий модуль «1С-Бітрікс: Мобільний додаток». У кожного — свої обмеження та область застосування.

Підхід 1: PWA

Progressive Web App — найшвидший шлях до «мобільного додатка» без публікації в сторах. Бітрікс з версії 20.0 містить вбудовану підтримку PWA: Service Worker для кешування, Web App Manifest для іконки на домашньому екрані, push через Push API.

Що дає PWA з коробки Бітрікс:

• Встановлення на домашній екран без App Store / Google Play.
• Офлайн-доступ до раніше завантажених сторінок (каталог, карточки товарів).
• Push-сповіщення через браузер (обмежені на iOS — Safari підтримує Web Push тільки з версії 16.4).
• Кешування статики через Service Worker, настроюване у файлі sw.js кореня сайту.

Обмеження: немає доступу до NFC, Bluetooth, контактів, камери з розширеними настройками. На iOS PWA працюють у контейнері WebKit з урізаними можливостями. Apple досі обмежує сховище PWA на рівні ~50 МБ. Для простого каталогу з кошиком цього вистачить, для додатка з офлайн-синхронізацією замовлень — ні.

Підхід 2: React Native / Flutter + REST API

Кросплатформна розробка з React Native або Flutter дає повнофункціональний нативний додаток з єдиною кодовою базою. Бітрікс виступає бекендом, надаючи дані через REST API.

REST API Бітрікс покриває основні сутності:

Авторизація реалізується через OAuth 2.0 — додаток отримує access_token та refresh_token. Для мобільного додатка використовується flow authorization_code з PKCE.

Архітектура взаємодії:

Мобільний додаток → HTTPS → REST API Бітрікс → ORM → PostgreSQL/MySQL

Критично важливо не звертатися до REST прямо для кожного екрана — у Бітрікс REST API є ліміт 2 запити на секунду на користувача (для хмарної версії). Для коробки ліміт залежить від налаштувань сервера, але навантаження все одно суттєве. Рішення — проміжний API-шар (middleware на Node.js або Go), який агрегує дані й кешує відповіді.

Каталог в мобільному додатку — найресурсомісна частина. Товари з зображеннями, фільтрами та сортуванням. Для швидкої роботи:

• Реалізуйте пагінацію через start та limit в REST-запитах.
• Кешуйте дерево розділів на клієнті — воно змінюється рідко.
• Зображення віддавайте через CDN з ресайзом (Бітрікс зберігає оригінали в /upload/, ресайз виконує модуль resize_image).

Кошик та оформлення замовлення через REST працюють надійно, але є нюанс: правила знижок кошика (sale.discount) застосовуються серверної стороною при виклику sale.basket.addProduct. Клієнт отримує вже перераховані ціни. Однак відображення проміжних станів (застосований купон, змінилась кількість) потребує повторного запиту до сервера.

Оплата — окрема тема. Еквайринг (ЮKassa, CloudPayments) зазвичай працює через WebView: додаток відкриває платіжну сторінку, користувач вводить дані карти, після оплати управління повертається в додаток через deep link. Нативна інтеграція Apple Pay / Google Pay потребує окремого модуля на стороні Бітрікс та відповідного SDK в додатку.

Підхід 3: 1С-Бітрікс: Мобільний додаток

Готове рішення від вендора. Являє собою нативну оболонку (iOS + Android), яка завантажує мобільну версію сайту в WebView з розширеними можливостями через JavaScript-мост.

Що входить:

• Шаблон мобільного сайту, оптимізований під WebView.
• Нативні push-сповіщення через модуль pull (Firebase Cloud Messaging для Android, APNs для iOS).
• Інтеграція з камерою для сканування штрих-кодів.
• Готові зібрані для публікації в App Store та Google Play (через кабінет розробника Бітрікс).

Обмеження: дизайн обмежений рамками шаблону, кастомізація — через CSS і JavaScript всередині WebView. Додати екран з нативною анімацією або складним UI можна лише з модифікацією оболонки. Продуктивність залежить від швидкості завантаження мобільного сайту — по суті, це упакований браузер.

Порівняння підходів

Push-сповіщення

Модуль pull у Бітрікс забезпечує серверну частину push-інфраструктури. Для мобільних додатків він інтегрується з Firebase Cloud Messaging (Android) та Apple Push Notification service (iOS). Відправлення push з коду:

\Bitrix\Pull\Push::add($userId, [
    'module_id' => 'sale',
    'push' => [
        'message' => 'Ваше замовлення #1234 відправлено',
        'params' => ['ORDER_ID' => 1234],
    ],
]);

Для сегментованих рассилок (покинутий кошик, персональні знижки) використовується связка модулів sender + pull: маркетолог створює сегмент у CRM, а sender ініціює push через pull.

Офлайн-режим

Повнофункціональний офлайн для каталогу реалізується тільки в нативному додатку. Схема: при першому запуску або за розкладом додаток завантажує каталог через REST (catalog.product.list з пагінацією) й зберігає в локальну БД (SQLite для React Native, Hive/Isar для Flutter). Зображення кешуються на файловій системі пристрою. Синхронізація — за delta-принципом: запитуються тільки товари з DATE_MODIFY більше останної синхронізації.

Кошик в офлайні формується локально, а при появі мережі — синхронізується з сервером через sale.basket.addProduct. Конфлікти (товар закінчився, ціна змінилась) обробляються сповіщенням користувачу.

Публікація в App Store та Google Play

Для React Native / Flutter — стандартний процес: збірка через Xcode / Android Studio, підписання сертифікатами, завантаження в консолях розробника.

Для модуля «Мобільний додаток» Бітрікс надає сервіс збірки: ви завантажуєте іконки, сплеш-скрини та конфігурацію в кабінет, отримуєте готові .ipa та .aab файли. Публікуєте самостійно через свій акаунт розробника (Apple Developer Program — $99/рік, Google Play — $25 одноразово).

Важливо: Apple регулярно ужесточує правила для додатків-обгорток навколо WebView. Якщо додаток не надає значимої нативної функціональності поверх веб-версії — є ризик відхилення при ревю.