Послуги з розробки мобільних додатків на Бітрікс

Мобільні застосунки для 1С-Бітрікс

Service Worker на Бітріксі — окрема пригода. Композитний кеш (CPagesCache) віддає HTML-сторінку з файлового кешу, а Service Worker поверх нього кешує ресурси через Cache API. Два шари кешування, які нічого не знають один про одного. Якщо не розділити їхні стратегії — користувач бачить застарілий кошик після додавання товару. Ми починаємо будь-який PWA-проєкт на Бітріксі з налаштування правильного розмежування: Service Worker бере статику (CSS, JS, шрифти) через Cache First, а HTML та API-відповіді завжди йдуть Network First з fallback на кеш. Композитний кеш Бітрікса при цьому працює на серверній стороні й не перетинається з клієнтським.

Варіанти мобільних рішень

PWA (Progressive Web App) — вебзастосунок, який виглядає як нативний, але працює у браузері. Встановлення зі стору не потрібне — додавання на домашній екран.

React Native — кросплатформа від Meta. JavaScript, одна кодова база — нативний застосунок для iOS та Android з повним доступом до API пристрою.

Flutter — кросплатформа від Google на Dart. Власний рушій рендерингу Skia, стабільні 60/120 FPS.

Мобільний застосунок Бітрікс24 — готове корпоративне рішення: CRM, задачі, чат, відеодзвінки.

*PWA можна обгорнути у TWA для Google Play.

PWA для 1С-Бітрікс: деталі реалізації

PWA — найшвидший спосіб забезпечити мобільну присутність. Мінімальні витрати, максимальна віддача на старті.

manifest.json — іконка, назва, display: standalone, theme_color, start_url. Користувач «встановлює» сайт на домашній екран. Файл кладемо в корінь і підключаємо через <link rel="manifest"> у header.php шаблону.

Service Worker — ядро PWA. Реєструємо у footer.php:

• Cache First для статики: /bitrix/cache/, CSS, JS, шрифти, зображення товарів
• Network First для HTML та API (/ajax/, /bitrix/services/). Якщо мережа недоступна — віддаємо кеш.
• Stale While Revalidate для каталогу — показуємо кешоване, оновлюємо у фоні
• Окрема логіка для кошика: завжди Network Only, інакше користувач бачить фантомні товари

Ключовий нюанс — конфлікт з композитом Бітрікс. Модуль composite кешує HTML на сервері й віддає статичні файли. Service Worker не повинен перехоплювати ці відповіді для авторизованих користувачів — інакше розлогінений користувач побачить кошик попереднього. Вирішуємо через перевірку cookie BX_USER_ID у fetch-обробнику.

Push-сповіщення — Firebase Cloud Messaging або OneSignal. Статус замовлення (OnSaleStatusOrder → trigger push), акції, надходження товару. Токен пристрою зберігаємо в UF-полі користувача.

Офлайн-каталог — раніше переглянуті товари доступні без інтернету. IndexedDB для карток, Cache API для зображень.

Сумісність із «Проактивним захистом» — модуль security перевіряє Referer та сесійні токени. Service Worker при prefetch може не передати потрібні заголовки — налаштовуємо винятки у BX_SECURITY_SESSION_VIRTUAL.

React Native для 1С-Бітрікс

Коли PWA замало — React Native дає повноцінний нативний застосунок з єдиною кодовою базою.

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

• Бекенд: Бітрікс віддає дані через REST API. Стандартні методи catalog.product.list, sale.order.add для каталогу й замовлень. Для кастомних сутностей — власні контролери через \Bitrix\Main\Engine\Controller.
• Проміжний шар: BFF (Backend for Frontend) на Node.js або GraphQL. Агрегуємо 3-5 запитів до Bitrix API в одну відповідь для мобільного клієнта — мобільний інтернет не прощає зайвих round-trip.
• Фронтенд: React Native застосунок.

Функціонал інтернет-магазину:

• Каталог: пошук, фільтри, сортування — дані з CIBlockElement::GetList через REST
• Картка товару: галерея (react-native-fast-image), опис, характеристики, відгуки
• Кошик і чекаут з persistence через AsyncStorage
• Особистий кабінет: замовлення, обране, профіль, адреси
• Push: статус замовлення, акції, покинутий кошик — FCM/APNs, тригери на подіях Бітрікс
• Нативні функції: сканер штрихкодів (react-native-camera), геолокація для ПВЗ, Face ID / Touch ID (react-native-biometrics)
• Офлайн: каталог та обране через AsyncStorage / WatermelonDB
• Deep linking: react-navigation deep link → конкретний товар з push або реклами

Чому React Native:

• React-розробники вже знають 80% того, що потрібно
• Екосистема: тисячі готових пакетів у npm
• Hot Reload — миттєвий зворотний зв'язок під час розробки
• CodePush від Microsoft — оновлення JS-бандлу без публікації у Store. Виправлення бага за хвилини, а не за 2-3 дні ревʼю.

Flutter для 1С-Бітрікс

Альтернатива React Native. Обираємо, коли потрібен нестандартний UI з важкими анімаціями.

Сильні сторони:

• Skia engine — 60/120 FPS на складних анімаціях, де React Native починає підгальмовувати на bridge
• Піксельна ідентичність на iOS та Android — власний рендеринг, а не платформні віджети
• Dart: строго типізований, помилки на етапі компіляції, а не в проді на пристрої користувача
• Material Design та Cupertino віджети з коробки

Коли Flutter:

• Інтерфейс зі складними анімаціями та кастомними переходами між екранами
• Критично важлива однаковість UI на обох платформах
• Плани на web і desktop (Flutter підтримує всі три цілі)
• Команда знає Dart або готова інвестувати в навчання

Інтеграція з Бітрікс:

• REST API на боці Бітрікс (аналогічно React Native)
• Пакет dio для HTTP з interceptors: автоматичне додавання auth-токена, retry на 5xx
• Стан: Riverpod або BLoC — залежить від масштабу
• Локальне сховище: Hive для key-value, sqflite для складних запитів до офлайн-даних

Мобільний застосунок Бітрікс24

Для корпоративних задач — готове рішення, не потрібно писати з нуля:

• CRM: угоди, контакти, компанії — у кишені
• Задачі й проєкти — створення, трекінг на ходу
• Корпоративний месенджер + відеодзвінки
• Диск — файли під рукою
• Кастомізація через REST API Б24: власні розділи, віджети, кастомні CRM-картки через placement

API для мобільних застосунків

Мобільний застосунок рівно настільки добрий, наскільки добрий API.

Проєктування:

• RESTful з версіонуванням (/api/v1/, /api/v2/) — зворотна сумісність при оновленнях
• JWT + refresh token. Access — 15 хвилин, refresh — 30 днів. Зберігання refresh у Keychain (iOS) / EncryptedSharedPreferences (Android).
• Пагінація курсором (?after=eyJ...) — стабільне довантаження без дублів при додаванні нових елементів
• Sparse fieldsets: ?fields=id,name,price,image — віддаємо лише потрібне екрану, економимо трафік

Оптимізація під мобільні мережі:

• Агреговані ендпоінти: один запит на екран замість п'яти. /api/v1/home повертає банери, рекомендації, акції та категорії однією відповіддю
• Gzip-стиснення — у Бітрікс вмикається через \Bitrix\Main\Config\Option::set('main', 'use_compression', 'Y')
• ETag / Last-Modified — 304 Not Modified економить трафік і час
• Retry з exponential backoff + offline queue (запити накопичуються й відправляються при відновленні мережі)
• Зображення за розміром пристрою: CFile::ResizeImageGet() з параметрами із заголовка DPR

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

• FCM (Android) + APNs (iOS)
• Тригери на подіях Бітрікс: OnSaleStatusOrder, OnCatalogStoreProductUpdate, OnSaleBasketSaved
• Сегментація: персоналізація за поведінкою з CRM
• Аналітика воронки: доставка → відкриття → перехід → конверсія

Терміни

Рекомендуємо стартувати з PWA — перевірити гіпотезу за 2-3 тижні. Якщо мобільний трафік підтверджує попит — нарощувати нативний застосунок із повним доступом до пристрою.