Налаштування мобільного додатку Бітрікс24 під ключ

Налаштування мобільного додатку Бітрікс24

Мобільний додаток Бітрікс24 доступний з коробки для всіх тарифних планів, але без правильного налаштування співробітники втрачають до 30% робочого часу. Пропускають сповіщення про нові угоди, не бачать календарні зустрічі, не можуть синхронізувати корпоративну пошту. Особливо гостро це проявляється в коробкових версіях: потрібно вручну підключати SSL-сертифікат, налаштовувати Firebase для Android та APNs для iOS. Ми налаштовуємо мобільний додаток вже понад 10 років, виконали 50+ проєктів для хмарних і коробкових версій. За цей час виявили типові вузькі місця та розробили швидкі скрипти для їх усунення.

Які проблеми вирішує налаштування?

Тихі канали зв'язку. Без push-сповіщень менеджери витрачають до 2 годин на реакцію на заявку. Керівники не бачать завершення завдань. Налаштування Firebase та APNs вирішує це за 30 хвилин.

Неповний доступ до CRM. Мобільний додаток може показувати чужі угоди або приховувати потрібні поля. Налаштування прав і представлень — 1 година роботи.

Розрізнені календарі. IMAP-синхронізація не передає зустрічі з Outlook. Перехід на Exchange Web Services або OAuth2 для Google Workspace дає 100% двосторонню синхронізацію.

Налаштування push-сповіщень для коробкової версії

Push-сповіщення працюють через Firebase Cloud Messaging (Android) та Apple Push Notification Service (iOS). Для коробкового Бітрікс24 налаштування виконується в розділі "Налаштування → Налаштування продукту → Push і Pull". Необхідно:

• Створити проект у Firebase Console, отримати Server Key.
• Для iOS — сертифікат APNs з Apple Developer Account.
• Внести ключі в налаштування модуля pull.

Ми використовуємо готові скрипти для швидкої інтеграції Firebase та APNs, що скорочує час налаштування до 30 хвилин. Результат: сповіщення приходять протягом 3 секунд — у 10 разів швидше, ніж стандартна IMAP-перевірка. В одному з проєктів це підвищило швидкість обробки заявок на 25%.

Чому важлива синхронізація календаря?

Якщо пошта налаштована через IMAP, зустрічі з корпоративного календаря не синхронізуються. Перехід на Exchange Web Services або OAuth2 для Google Workspace вирішує проблему: після налаштування зустрічі з'являються в мобільному додатку в обидва боки. Налаштування через Exchange вдвічі швидше, ніж через IMAP, і підтримує повну двосторонню синхронізацію без затримок. В одному з кейсів це зекономило відділу продажів 10 годин на місяць на узгодженні зустрічей.

CRM у мобільному додатку: налаштування полів і прав

За замовчуванням у мобільному доступні: ліди, угоди, контакти, компанії, дзвінки. Налаштування видимості полів — через "CRM → Налаштування → Поля" з окремими профілями для мобільного представлення. Для автоматичного відкриття картки абонента під час вхідного дзвінка вмикається ідентифікація дзвінка в налаштуваннях телефонії. Додаток показує картку контакту з CRM при вхідному дзвінку на мобільний, якщо номер знайдено в b_crm_contact_detail. У 95% випадків це прискорює обробку дзвінків на 30%. Для кастомізації полів використовуємо REST API — додаємо поля в представлення «Мобільний додаток».

Як налаштувати права доступу?

У розділі "Налаштування → Структура компанії → Ролі" для мобільного пристрою актуально: обмежити експорт даних CRM, заборонити видалення записів, налаштувати доступ до розділу «Диск» тільки до корпоративного сховища (не особистого). Це критично важливо для дотримання політик безпеки. Наші сертифіковані спеціалісти з 10-річним досвідом проводять аудит прав і надають рекомендації. За статистикою, 70% компаній знаходять у себе надлишкові права вже після першого аналізу.

Що входить у налаштування

Порівняння конфігурацій

Процес роботи над проєктом

1. Аналітика — вивчаємо поточну конфігурацію, виявляємо вузькі місця.
2. Проєктування — визначаємо склад push, права, списки синхронізації.
3. Налаштування — конфігуруємо SSL, Firebase, APNs, ролі, поля CRM.
4. Тестування — перевіряємо push, синхронізацію, доступність усіх розділів.
5. Деплой — передаємо інструкції та закріплюємо результат.

Типові помилки при самостійному налаштуванні

• Невірний Server Key Firebase — сповіщення не працюють взагалі.
• Відсутність SSL-сертифікату — додаток не підключається до коробки.
• Забуті права доступу — співробітники бачать особисті дані інших.
• Не включений модуль pull — push не проходить.

Чек-лист перед запуском:

• [ ] SSL-сертифікат (для коробки) встановлений і перевірений.
• [ ] Серверний ключ Firebase доданий у налаштування pull.
• [ ] APNs сертифікат завантажений.
• [ ] Включений модуль calendar для синхронізації.
• [ ] Налаштовані ролі для мобільного доступу.
• [ ] Проведено тестове сповіщення на Android та iOS.

Терміни та вартість

Базове налаштування займає від 2 до 4 годин, розширене з інтеграцією Exchange або Google Workspace — 1-2 дні. Вартість базового налаштування стартує від 200 у.о., розширеного — від 500 у.о. Ми працюємо з хмарними та коробковими редакціями. Оцінимо ваш проєкт безкоштовно — пишіть нам для консультації. Ми гарантуємо стабільну роботу всіх компонентів після налаштування. Замовте налаштування мобільного додатку Бітрікс24 під ключ — і ваші співробітники завжди будуть на зв'язку.

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