Настройка 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)
- В Firebase Console создаём проект, добавляем Android-приложение с bundle ID.
- Скачиваем
google-services.json, кладём в проект Bitrix Mobile.
- Копируем Server Key из Firebase Console → Cloud Messaging.
В панели управления Битрикс: Настройки → Настройки продукта → Мобильные приложения → Push и Pull — вставляем Server Key Firebase.
APNs (iOS)
- В Apple Developer: создаём APNs Key (.p8 файл), запоминаем Key ID и Team ID.
- В Битрикс: вставляем содержимое .p8 файла, Key ID, Team ID, Bundle ID.
После этого стандартные push-уведомления Битрикс (новый заказ, смена статуса через стандартные события) начнут работать.
Сравнение FCM и APNs
| Характеристика |
FCM (Android) |
APNs (iOS) |
| Тип ключа |
Server Key (строка или JSON) |
.p8-файл с Key ID и Team ID |
| Безопасность |
Требуется дополнительная настройка SHA |
Встроенная проверка сертификата |
| Доставка в фоне |
WorkManager/JobScheduler |
Background Task Framework |
| Срок действия токена |
Может меняться при обновлении приложения |
Стабилен до удаления приложения |
| Деактивация устаревших токенов |
Автоматическая при ответе FCM |
Ручная при статусе 410 от 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% времени администратора.
Этапы работы
Развернуть подробный план работ
-
Аудит текущей инфраструктуры — проверка версии Битрикс, модуля pull, существующих токенов.
-
Получение ключей — регистрация в Firebase Console и Apple Developer, выпуск ключей.
- Настройка панели Битрикс — ввод Server Key, APNs-ключей, тестовый запуск.
- Разработка кастомных сценариев — написание команд, событий, интеграция с мобильным приложением.
- Тестирование — проверка на Android и iOS, эмуляция сбоев доставки.
- Деплой и мониторинг — включение в боевую среду, отслеживание доставки 2 недели.
Что входит в работу
- Создание проектов Firebase и Apple Developer, получение и регистрация ключей
- Настройка FCM и APNs в панели управления Битрикс
- Тестирование стандартных уведомлений (заказы, статусы)
- Разработка кастомных push: снижение цены, новые акции, напоминания
- Сегментация: отправка по группам пользователей
- Ограничение частоты, деактивация устаревших токенов
- Документация по интеграции и передача доступов
- Гарантия доставки: мониторинг в течение 2 недель после запуска
Сроки
- Стандартные уведомления: от 1 до 2 дней
- Кастомные сценарии с сегментацией: от 1 до 2 недель
Сравнение стандартного и кастомного подхода
| Параметр |
Стандартные push |
Кастомные push |
| Время настройки |
1–2 дня |
1–2 недели |
| Гибкость |
Только системные события |
Любые сценарии бизнеса |
| Сегментация |
Нет |
По группам, частоте, интересам |
| Контроль доставки |
Через логи Битрикс |
Кастомный мониторинг, ретраи |
| Бюджет |
от 30 000 ₽ |
от 120 000 ₽ |
Оценка стоимости вашего проекта — бесплатно. Закажите консультацию инженера, чтобы обсудить детали.
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 |
React Native |
Flutter |
| Стоимость |
Низкая |
Средняя |
Средняя |
| Запуск |
1-3 недели |
2-4 месяца |
2-4 месяца |
| App Store / Google Play |
Нет (TWA) |
Да |
Да |
| Push |
Да (iOS 16.4+) |
Да |
Да |
| Офлайн |
Базовый |
Полный |
Полный |
| Камера, GPS |
Ограничено |
Полный |
Полный |
| Производительность |
Средняя |
Высокая |
Высокая |
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
- Аналитика воронки: доставка → открытие → переход → конверсия
Что входит в разработку мобильного приложения под ключ?
-
Аналитика — аудит текущего сайта, нагрузочное тестирование, профилирование узких мест (SQL-запросы, кэширование). Сбор требований по фичам.
-
Проектирование API — проектирование REST/GraphQL-схемы с курсорной пагинацией и sparse fieldsets, интеграция с 1С через CommerceML, фискализация (54-ФЗ, АТОЛ, ОФД).
-
Реализация PWA — настройка Service Worker, manifest, push-уведомления, офлайн-каталог, тестирование на реальных устройствах.
-
Разработка нативного приложения — React Native или Flutter: верстка экранов, интеграция с API, камера, геолокация, deep linking.
-
Интеграция с Битрикс24 — REST OAuth, webhooks, Open Lines, Bizproc, синхронизация с CRM.
-
Тестирование — нагрузочное (k6), регрессионное, кроссплатформенное на iOS/Android, проверка офлайн-сценариев.
-
Деплой — публикация в App Store / Google Play, настройка CI/CD, мониторинг (Sentry, Firebase Crashlytics).
-
Документация — описание API, архитектуры, инструкция по обновлению. Передача доступов и исходных кодов.
Результат: работающее приложение, документация, доступы к серверам и сторам, обучение команды заказчика.
Сроки
| Задача |
Сроки |
| PWA для существующего сайта |
2-4 недели |
| REST API для мобильного приложения |
3-6 недель |
| MVP на React Native / Flutter |
2-3 месяца |
| Полнофункциональное приложение |
4-6 месяцев |
| Публикация в App Store / Google Play |
1-2 недели |
| Кастомизация приложения Б24 |
2-4 недели |
Рекомендуем стартовать с PWA — проверить гипотезу за 2-3 недели. Если мобильный трафик подтверждает спрос — наращивать нативное приложение с полным доступом к устройству.
Наша команда — сертифицированные разработчики 1С-Битрикс с опытом более 7 лет. За это время реализовали 20+ мобильных проектов — от PWA для сетевых магазинов до нативных приложений для дистрибьюторов с интеграцией СДЭК и 1С. Гарантируем совместимость с актуальными версиями платформы и модулей. Progressive Web Apps, React Native, Flutter.
Закажите предварительную оценку: пришлём архитектурный план и сроки за 2 рабочих дня. Получите консультацию разработчика по выбору технологии — заполните форму на сайте или позвоните нам.