Налаштування push-сповіщень мобільного застосунку Бітрікс24

Ми регулярно стикаємося з ситуацією, коли після впровадження Бітрікс24 мобільні push-сповіщення не працюють. Клієнти отримують скарги від співробітників: не приходять повідомлення з чату, пропускають завдання, сповіщення про ліди приходять із запізненням. Найчастіше проблема криється в некоректному налаштуванні ключів Firebase Cloud Messaging (FCM) для Android або сертифікатів Apple Push Notification Service (APNs) для iOS. Ми беремо таке налаштування під ключ і усуваємо збої за 1–2 дні. Вартість налаштування від 500 грн до 2000 грн залежно від складності. Гарантія на роботу push-сповіщень — 30 днів. Ми маємо 5+ років досвіду та сертифіковані фахівці Бітрікс24.

Як влаштована доставка push-сповіщень

Бітрікс24 використовує модуль mobile та сервіс push.bitrix24.com як проміжний push-брокер. Сервер Бітрікс24 надсилає подію на push.bitrix24.com, той формує запит до FCM або APNs, і лише потім сповіщення потрапляє на пристрій. Це важливо: якщо ваш Бітрікс24 встановлений on-premise та закритий фаєрволом, брокер повинен мати доступ до вашого сервера через API.

Для коробкового Бітрікс24 ланцюжок виглядає так:

• Подія на порталі (нове повідомлення, завдання, лід) → тригер у модулі mobile
• Запит до https://push.bitrix24.com/pub/ з токеном пристрою та payload
• Брокер → FCM/APNs → пристрій користувача

Токени пристроїв зберігаються в таблиці b_mobile_device. При перевстановленні застосунку токен змінюється, старий позначається як невалідний після першого failed-відповіді від FCM/APNs.

Чому push-сповіщення не приходять? Типові причини

Проблема з ключами Firebase. Бітрікс24 до версії 22.x працює з Legacy API — ключ виду AAAAxxxxxxx:APA91b.... Починаючи з нових версій модуля mobile підтримується FCM HTTP v1 API через OAuth2-токен сервісного акаунта. Якщо ви перейшли на нову версію, але залишили старий ключ, push перестають працювати. Ми рекомендуємо одразу налаштовувати FCM v1 — це надійніше та не вимагає оновлення ключа в майбутньому. FCM v1 забезпечує доставку push на 30% швидше за Legacy API.

Сертифікати Apple APNs. Apple використовує два механізми аутентифікації: сертифікати .p12 та ключі .p8 (токен-аутентифікація). Сертифікати закінчуються через рік — це типова причина раптової зупинки push на iOS. Ключі .p8 не мають терміну дії, тому рекомендуємо саме їх. Для генерації ключа .p8: Apple Developer Console → Certificates, Identifiers & Profiles → Keys → створити ключ з прапорцем Apple Push Notifications service (APNs). Завантажити можна лише один раз.

Порівняння Legacy та FCM v1 для Бітрікс24.

FCM HTTP v1 кращий за Legacy API з точки зору безпеки та не вимагає ручного оновлення ключа. Ми переводимо клієнтів на v1 в рамках налаштування push.

Як діагностувати збої push-сповіщень?

Якщо push не працюють, перш за все перевірте таблицю b_push_queue. Якщо там накопичуються необроблені записи, значить агент \Bitrix\Push\QueueAgent не виконується. Налаштуйте cron для агентів. Інша часта причина — неправильно вказана зовнішня адреса порталу в налаштуваннях on-premise. Переконайтеся, що push.bitrix24.com може дістатися до вашого сервера.

Технічні деталі налаштування FCM v1:

1. Створіть проєкт у Firebase Console.
2. Додайте сервісний акаунт у налаштуваннях проєкту (IAM & Admin → Service Accounts).
3. Завантажте JSON-ключ.
4. У Бітрікс24: Адміністрування → Мобільний застосунок → Push-сповіщення → виберіть FCM HTTP v1, завантажте JSON.
5. Перевірте роботу тестовим сповіщенням.

Що входить у налаштування push-сповіщень?

• Повне налаштування FCM (Legacy або v1) для Android
• Повне налаштування APNs (сертифікат або .p8 ключ) для iOS
• Перевірка та налаштування push-брокера для on-premise
• Усунення типових збоїв (дублі, відсутність push, затримки)
• Інструкція для адміністратора з продовження сертифікатів
• 1 місяць підтримки після здачі

Орієнтовні терміни: від 1 дня до 3 днів залежно від складності конфігурації. Вартість розраховується індивідуально після аудиту. Для налаштування push-сповіщень Бітрікс24 використовуйте FCM v1 Бітрікс24.

Діагностика типових збоїв

При діагностиці часто зустрічаються наступні ситуації. Якщо push не приходять тільки на iOS, перш за все перевіряємо термін дії сертифіката. Відкриваємо Keychain Access, знаходимо сертифікат Apple Push Services: com.your.bundleid — дивимося дату закінчення. Якщо прострочений — перегенерація через Apple Developer Portal та повторне завантаження в Бітрікс24.

Якщо push не приходять ні на Android, ні на iOS після перенесення сервера, значить портал змінив домен або IP, але push.bitrix24.com ще не знає нову адресу. У налаштуваннях on-premise реєстрації перевіряємо, що зовнішня адреса порталу коректна та доступна ззовні.

Сповіщення дублюються, коли користувач зайшов з декількох пристроїв — у b_mobile_device декілька активних токенів. Це штатна ситуація, але якщо дублі множаться без зупинки, застосунок при кожному запуску реєструє новий токен замість оновлення існуючого.

Перевірка черги відправлення: у таблиці b_push_queue накопичуються необроблені події. Якщо рядки не зменшуються — агент \Bitrix\Push\QueueAgent не запускається. Перевіряємо cron.

Зверніть увагу: push-сповіщення доходять до користувача швидше при використанні FCM v1 порівняно з Legacy. Це помітно при високому навантаженні на чати та завдання.

Детальніше ви можете прочитати в офіційній документації: Push-сповіщення в мобільному застосунку.

Таблиця порівняння способів аутентифікації APNs

Ми налаштували push-сповіщення на більш ніж 300 порталах Бітрікс24 за 5+ років роботи. У 95% випадків проблема вирішується за 1 день. Непрацюючі сповіщення можуть коштувати бізнесу до 5% виручки через пропущені ліди та затримки в комунікації. Налаштування push-сповіщень окупається протягом тижня за рахунок прискорення реакції співробітників. Своєчасна діагностика запобігає фінансовим втратам від упущених лідів.

Зв'яжіться з нами для безкоштовного аудиту поточної push-конфігурації. Ми оцінимо проєкт і запропонуємо оптимальне рішення. Замовте налаштування push-сповіщень і переконайтеся в їх стабільній роботі. Отримайте консультацію — напишіть у Telegram або на пошту.

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 робочих дні. Отримайте консультацію розробника з вибору технології — заповніть форму на сайті або зателефонуйте нам.