Bitrix Mobile Application Development Services

Mobile Applications for 1C-Bitrix

Service Worker on Bitrix is an adventure of its own. The composite cache (CPagesCache) serves HTML pages from the file cache, while the Service Worker on top of it caches resources via Cache API. Two caching layers that know nothing about each other. If you don't separate their strategies, the user sees a stale cart after adding a product. We start every PWA project on Bitrix by setting up the correct separation: Service Worker handles static assets (CSS, JS, fonts) via Cache First, while HTML and API responses always go Network First with a cache fallback. The Bitrix composite cache works server-side and doesn't overlap with the client-side one.

Mobile Solution Options

PWA (Progressive Web App) — a web application that looks native but lives in the browser. No store installation needed — just add to home screen.

React Native — cross-platform framework by Meta. JavaScript, single codebase — a native application for iOS and Android with full device API access.

Flutter — cross-platform framework by Google, built on Dart. Custom Skia rendering engine, stable 60/120 FPS.

Bitrix24 Mobile App — a ready-made corporate solution: CRM, tasks, chat, video calls.

*PWA can be wrapped in TWA for Google Play.

PWA for 1C-Bitrix: Implementation Details

PWA is the fastest way to establish a mobile presence. Minimal investment, maximum return at launch.

manifest.json — icon, name, display: standalone, theme_color, start_url. The user "installs" the site to their home screen. The file goes in the root directory and is linked via <link rel="manifest"> in the template's header.php.

Service Worker — the core of PWA. Registered in footer.php:

• Cache First for static assets: /bitrix/cache/, CSS, JS, fonts, product images
• Network First for HTML and API (/ajax/, /bitrix/services/). If the network is unavailable — serve from cache.
• Stale While Revalidate for the catalog — show cached content, update in the background
• Separate logic for the cart: always Network Only, otherwise the user sees phantom products

Key nuance — conflict with Bitrix composite cache. The composite module caches HTML on the server and serves static files. The Service Worker must not intercept these responses for authenticated users — otherwise a logged-out user will see someone else's cart. We solve this by checking the BX_USER_ID cookie in the fetch handler.

Push notifications — Firebase Cloud Messaging or OneSignal. Order status (OnSaleStatusOrder → trigger push), promotions, product restocking. The device token is stored in a user UF field.

Offline catalog — previously viewed products are available without internet. IndexedDB for product cards, Cache API for images.

Compatibility with "Proactive Protection" — the security module checks Referer and session tokens. During prefetch, the Service Worker may not pass the required headers — we configure exceptions in BX_SECURITY_SESSION_VIRTUAL.

React Native for 1C-Bitrix

When PWA isn't enough — React Native delivers a full-fledged native application with a single codebase.

Architecture:

• Backend: Bitrix serves data via REST API. Standard methods catalog.product.list, sale.order.add for catalog and orders. For custom entities — custom controllers via \Bitrix\Main\Engine\Controller.
• Middle layer: BFF (Backend for Frontend) on Node.js or GraphQL. We aggregate 3-5 requests to Bitrix API into a single response for the mobile client — mobile networks don't forgive extra round-trips.
• Frontend: React Native application.

E-commerce functionality:

• Catalog: search, filters, sorting — data from CIBlockElement::GetList via REST
• Product card: gallery (react-native-fast-image), description, specifications, reviews
• Cart and checkout with persistence via AsyncStorage
• Personal account: orders, favorites, profile, addresses
• Push: order status, promotions, abandoned cart — FCM/APNs, triggers on Bitrix events
• Native features: barcode scanner (react-native-camera), geolocation for pickup points, Face ID / Touch ID (react-native-biometrics)
• Offline: catalog and favorites via AsyncStorage / WatermelonDB
• Deep linking: react-navigation deep link → specific product from push or advertising

Why React Native:

• React developers already know 80% of what's needed
• Ecosystem: thousands of ready-made npm packages
• Hot Reload — instant feedback during development
• CodePush by Microsoft — JS bundle updates without Store publication. Bug fix in minutes, not 2-3 days of review.

Flutter for 1C-Bitrix

An alternative to React Native. We choose it when non-standard UI with heavy animations is required.

Strengths:

• Skia engine — 60/120 FPS on complex animations where React Native starts lagging on the bridge
• Pixel-perfect consistency on iOS and Android — custom rendering, not platform widgets
• Dart: strictly typed, errors at compile time, not in production on a user's device
• Material Design and Cupertino widgets out of the box

When to choose Flutter:

• Interface with complex animations and custom screen transitions
• Pixel-perfect UI consistency across both platforms is critical
• Plans for web and desktop (Flutter supports all three targets)
• The team knows Dart or is ready to invest in learning

Bitrix integration:

• REST API on the Bitrix side (same as React Native)
• dio package for HTTP with interceptors: automatic auth token injection, retry on 5xx
• State management: Riverpod or BLoC — depends on the project scale
• Local storage: Hive for key-value, sqflite for complex offline data queries

Bitrix24 Mobile App

For corporate needs — a ready-made solution, no need to build from scratch:

• CRM: deals, contacts, companies — in your pocket
• Tasks and projects — create, track on the go
• Corporate messenger + video calls
• Drive — files at your fingertips
• Customization via Bitrix24 REST API: custom sections, widgets, custom CRM cards via placement

API for Mobile Applications

A mobile application is only as good as its API.

Design:

• RESTful with versioning (/api/v1/, /api/v2/) — backward compatibility during updates
• JWT + refresh token. Access — 15 minutes, refresh — 30 days. Refresh token stored in Keychain (iOS) / EncryptedSharedPreferences (Android).
• Cursor-based pagination (?after=eyJ...) — stable loading without duplicates when new items are added
• Sparse fieldsets: ?fields=id,name,price,image — return only what the screen needs, save bandwidth

Optimization for mobile networks:

• Aggregated endpoints: one request per screen instead of five. /api/v1/home returns banners, recommendations, promotions, and categories in a single response
• Gzip compression — in Bitrix enabled via \Bitrix\Main\Config\Option::set('main', 'use_compression', 'Y')
• ETag / Last-Modified — 304 Not Modified saves bandwidth and time
• Retry with exponential backoff + offline queue (requests queue up and send when connectivity is restored)
• Images sized to device: CFile::ResizeImageGet() with parameters from the DPR header

Push notifications:

• FCM (Android) + APNs (iOS)
• Triggers on Bitrix events: OnSaleStatusOrder, OnCatalogStoreProductUpdate, OnSaleBasketSaved
• Segmentation: personalization based on CRM behavior data
• Funnel analytics: delivery → open → click → conversion

Timelines

We recommend starting with PWA — test the hypothesis in 2-3 weeks. If mobile traffic confirms demand — scale up to a native application with full device access.