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

Наша компания занимается разработкой, поддержкой и обслуживанием решений на Битрикс и Битрикс24 любой сложности. От простых одностраничных сайтов до сложных интернет магазинов, CRM систем с интеграцией 1С и телефонии. Опыт разработчиков подтвержден сертификатами от вендора.
Услуги, которые мы предлагаем
Показано 1 из 1Все 1626 услуг
Настройка push-уведомлений мобильного приложения 1С-Битрикс
Простой
~1 день
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1357
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    943
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Разработка на базе Битрикс, Битрикс24, 1С для компании Development of an Online Appointment Booking Widget for a Medical Center
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    829
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    1074

Настройка 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

Характеристика 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% времени администратора.

Этапы работы

Развернуть подробный план работ
  1. Аудит текущей инфраструктуры — проверка версии Битрикс, модуля pull, существующих токенов.
  2. Получение ключей — регистрация в Firebase Console и Apple Developer, выпуск ключей.
  3. Настройка панели Битрикс — ввод Server Key, APNs-ключей, тестовый запуск.
  4. Разработка кастомных сценариев — написание команд, событий, интеграция с мобильным приложением.
  5. Тестирование — проверка на Android и iOS, эмуляция сбоев доставки.
  6. Деплой и мониторинг — включение в боевую среду, отслеживание доставки 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
  • Аналитика воронки: доставка → открытие → переход → конверсия

Что входит в разработку мобильного приложения под ключ?

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