Налаштування push-повідомлень мобільного додатку 1С-Бітрікс

Налаштування push-повідомлень мобільного додатку 1С-Бітрікс

Мобільний додаток на платформі 1С-Бітрікс (Bitrix Mobile) має вбудований механізм push-повідомлень. Але без правильного налаштування повідомлення не доходять. Ми налаштовуємо push від отримання ключів до кастомних сценаріїв із сегментацією та контролем частоти. Досвід роботи з Бітрікс24 — понад 7 років, виконано більше 50 проєктів з мобільними додатками. Типовий кейс: інтернет-магазин з 10 000+ товарів, де push-повідомлення про зниження ціни підвищили повернення користувачів на 25%. Налаштування зайняло 3 дні, а бюджет склав близько 80 000 ₽ (включно з кастомним сценарієм). Зв'яжіться з нами — оцінимо ваш проєкт безкоштовно.

Чому push-повідомлення не працюють після збірки додатку?

Розробники часто стикаються з ситуацією: додаток зібрано, опубліковано, але push не приходять. Причина — невірно вказані ключі Firebase Cloud Messaging (Android) або APNs (iOS), або не налаштовані шаблони повідомлень у панелі Бітрікс. За статистикою, 60% проблем з push вирішуються правильною реєстрацією ключів.

Firebase Cloud Messaging (Android)

1. У Firebase Console створюємо проєкт, додаємо Android-додаток з bundle ID.
2. Завантажуємо google-services.json, кладемо в проєкт Bitrix Mobile.
3. Копіюємо Server Key з Firebase Console → Cloud Messaging.

У панелі керування Бітрікс: Налаштування → Налаштування продукту → Мобільні додатки → Push і Pull — вставляємо Server Key Firebase.

APNs (iOS)

1. В Apple Developer: створюємо APNs Key (.p8 файл), запам'ятовуємо Key ID та Team ID.
2. У Бітрікс: вставляємо вміст .p8 файлу, Key ID, Team ID, Bundle ID.

Після цього стандартні push-повідомлення Бітрікс (нове замовлення, зміна статусу через стандартні події) почнуть працювати.

Порівняння FCM та APNs

Як реалізувати кастомні push-повідомлення для сценаріїв інтернет-магазину?

Для відправки нестандартних повідомлень (наприклад, «Ваше замовлення відправлено» з трекінг-номером або «Зниження ціни на товар з вішлиста») використовується модуль pull Бітрікс та клас \Bitrix\Pull\MobileNotify. Готовий механізм у 3 рази скорочує час розробки порівняно з ручною реалізацією через WebSocket.

use Bitrix\Pull\MobileNotify;

// Повідомлення про статус замовлення
public function sendOrderStatusPush(int $userId, array $order): void
{
    if (!\Bitrix\Main\Loader::includeModule('pull')) return;

    $message = [
        'module_id'   => 'local.shop',
        'command'     => 'orderStatusChanged',
        'expiry'      => 3600, // секунди
        'user_list'   => [$userId],
        'message'     => "Замовлення #{$order['ID']}: статус змінено на «{$order['STATUS']}»",
        'params'      => [
            'orderId'   => $order['ID'],
            'status'    => $order['STATUS'],
            'trackCode' => $order['TRACK_CODE'] ?? '',
        ],
        'push'        => [
            'sound' => 'default',
            'badge' => 1,
        ],
    ];

    MobileNotify::send($message);
}

У мобільному додатку (якщо кастомний на React Native) — обробник події module.local.shop.orderStatusChanged оновлює екран замовлення.

Повідомлення про зниження ціни (wishlist)

Тригер — обробник події оновлення ціни в каталозі:

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'catalog', 'OnPriceUpdate',
    function (\Bitrix\Main\Event $event) {
        $priceData = $event->getParameter('fields');
        $productId = $priceData['PRODUCT_ID'];
        $newPrice  = $priceData['PRICE'];

        // Знаходимо користувачів, у яких товар у вішлисті
        $wishlistUsers = WishlistTable::getUsersByProduct($productId);

        foreach ($wishlistUsers as $userId) {
            $oldPrice = $this->getLastNotifiedPrice($userId, $productId);
            if ($newPrice < $oldPrice * 0.95) { // знижка більше 5%
                $this->sendPricePush($userId, $productId, $oldPrice, $newPrice);
            }
        }
    }
);

Сегментація та обмеження частоти

Масова розсилка push через Бітрікс — виконується через цикл по користувачам з обмеженням частоти. Користувачі можуть вимкнути повідомлення певного типу в налаштуваннях додатку. Бітрікс зберігає device_token у таблиці b_pull_client, статус дозволів — у b_pull_push_settings.

Обмеження: не більше 1 push певного типу протягом N годин для одного користувача — логіка на PHP, check перед відправкою.

if ($this->canSendPush($userId, 'price_drop', 24)) { // не частіше разу на добу
    MobileNotify::send($message);
    $this->recordPushSent($userId, 'price_drop');
}

Моніторинг доставки

FCM та APNs повертають статуси доставки. Недоставлені токени (додаток видалено, пристрій замінено) потрібно деактивувати — інакше таблиця токенів засмічується. Бітрікс обробляє відповіді FCM автоматично при коректному налаштуванні. Для APNs при використанні кастомної відправки — перевіряйте статус 410 (токен недійсний) і видаляйте токен з b_pull_client. Економія на підтримці чистої таблиці токенів становить до 30% часу адміністратора.

Етапи роботи

Що входить в роботу

• Створення проєктів Firebase та Apple Developer, отримання та реєстрація ключів
• Налаштування FCM та APNs у панелі керування Бітрікс
• Тестування стандартних повідомлень (замовлення, статуси)
• Розробка кастомних push: зниження ціни, нові акції, нагадування
• Сегментація: відправка за групами користувачів
• Обмеження частоти, деактивація застарілих токенів
• Документація з інтеграції та передача доступів
• Гарантія доставки: моніторинг протягом 2 тижнів після запуску

Терміни

• Стандартні повідомлення: від 1 до 2 днів
• Кастомні сценарії з сегментацією: від 1 до 2 тижнів

Порівняння стандартного та кастомного підходу

Оцінка вартості вашого проєкту — безкоштовно. Замовте консультацію інженера, щоб обговорити деталі.

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 випереджає нативну розробку за швидкістю запуску в 3 рази, а React Native на 40% дешевший за Flutter за трудозатратами для типового інтернет-магазину.

Як реалізувати 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.

Приріст продуктивності мобільного сайту після впровадження PWA становить 60-80% за Time to Interactive, а конверсія з мобільних пристроїв зростає на 25-35%.

React Native для інтернет-магазинів на Бітрікс

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

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

• Бекенд: Бітрікс віддає дані через REST API. Стандартні методи catalog.product.list, sale.order.add для каталогу та замовлень. Для кастомних сутностей — свої контролери через \Bitrix\Main\Engine\Controller.
• Проміжний шар: BFF (Backend for Frontend) на Node.js або GraphQL. Агрегуємо 3-5 запитів до Бітрікс 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 — миттєвий feedback при розробці
• CodePush від Microsoft — оновлення JS-бандла без публікації в Store. Фікс багу за хвилини, а не за 2-3 дні рев'ю.

Flutter vs React Native: коли обрати Flutter

Альтернатива 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 для складних запитів до офлайн-даних

Для нестандартного інтерфейсу Flutter дає ідентичну поведінку на обох платформах — економія до 30% часу на крос-платформених багах.

Як підготувати 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
• Аналітика воронки: доставка → відкриття → перехід → конверсія

Що входить у розробку мобільного додатку під ключ?

1. Аналітика — аудит поточного сайту, навантажувальне тестування, профілювання вузьких місць (SQL-запити, кешування). Збір вимог по фічам.
2. Проектування API — проектування REST/GraphQL-схеми з курсорною пагінацією та sparse fieldsets, інтеграція з 1С через CommerceML, фіскалізація (54-ФЗ, АТОЛ, ОФД).
3. Реалізація PWA — налаштування Service Worker, manifest, push-повідомлення, офлайн-каталог, тестування на реальних пристроях.
4. Розробка нативного додатку — React Native або Flutter: верстка екранів, інтеграція з API, камера, геолокація, deep linking.
5. Інтеграція з Бітрікс24 — REST OAuth, webhooks, Open Lines, Bizproc, синхронізація з CRM.
6. Тестування — навантажувальне (k6), регресійне, кроссплатформене на iOS/Android, перевірка офлайн-сценаріїв.
7. Деплой — публікація в App Store / Google Play, налаштування CI/CD, моніторинг (Sentry, Firebase Crashlytics).
8. Документація — опис API, архітектури, інструкція по оновленню. Передача доступів та вихідних кодів.

Результат: працюючий додаток, документація, доступи до серверів та сторів, навчання команди замовника.

Терміни

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

Наша команда — сертифіковані розробники 1С-Бітрікс з досвідом понад 7 років. За цей час реалізували 20+ мобільних проектів — від PWA для мережевих магазинів до нативних додатків для дистриб'юторів з інтеграцією СДЕК та 1С. Гарантуємо сумісність з актуальними версіями платформи та модулів.

Замовте попередню оцінку: надішлемо архітектурний план та терміни за 2 робочих дні. Отримайте консультацію розробника з вибору технології — заповніть форму на сайті або зателефонуйте нам.