Development of a mobile application for the 1C-Bitrix online store

Development of a Mobile App for an E-commerce Store on 1C-Bitrix

Mobile traffic in e-commerce has long exceeded desktop traffic, and responsive design is often not enough. A native or hybrid app provides push notifications, offline catalog access, and noticeably faster interface performance. For an e-commerce store on 1C-Bitrix, there are three fundamentally different approaches: PWA, cross-platform development via REST API, and the ready-made "1C-Bitrix: Mobile App" module. Each has its own limitations and area of application.

Approach 1: PWA

Progressive Web App — the quickest path to a "mobile app" without publishing to stores. Bitrix starting with version 20.0 contains built-in PWA support: Service Worker for caching, Web App Manifest for home screen icon, push via Push API.

What PWA provides out of the box from Bitrix:

• Installation on home screen without App Store / Google Play.
• Offline access to previously loaded pages (catalog, product cards).
• Push notifications via browser (limited on iOS — Safari supports Web Push only from version 16.4).
• Static caching via Service Worker, configurable in sw.js in the site root.

Limitations: no access to NFC, Bluetooth, contacts, camera with advanced settings. On iOS, PWAs run in a WebKit container with limited capabilities. Apple still restricts PWA storage to ~50 MB. For a simple catalog with cart, this is enough; for an app with offline order synchronization — it's not.

Approach 2: React Native / Flutter + REST API

Cross-platform development with React Native or Flutter provides a full-featured native app with a unified codebase. Bitrix acts as the backend, providing data via REST API.

Bitrix REST API covers main entities:

Authentication is implemented via OAuth 2.0 — the app receives access_token and refresh_token. For mobile apps, the authorization_code flow with PKCE is used.

Interaction architecture:

Mobile app → HTTPS → Bitrix REST API → ORM → PostgreSQL/MySQL

It's critical not to call REST directly for each screen — Bitrix REST API has a limit of 2 requests per second per user (for cloud version). For self-hosted, the limit depends on server settings, but load is still significant. The solution is an intermediate API layer (middleware on Node.js or Go) that aggregates data and caches responses.

Catalog in a mobile app — the most resource-intensive part. Products with images, filters, and sorting. For fast performance:

• Implement pagination via start and limit in REST requests.
• Cache the section tree on the client — it changes rarely.
• Serve images via CDN with resizing (Bitrix stores originals in /upload/, resizing is done by the resize_image module).

Cart and checkout via REST work reliably, but there's a nuance: cart discount rules (sale.discount) are applied server-side when calling sale.basket.addProduct. The client receives already recalculated prices. However, displaying intermediate states (coupon applied, quantity changed) requires a new server request.

Payment — a separate topic. Acquiring (YuKassa, CloudPayments) usually works via WebView: the app opens the payment page, the user enters card details, after payment control returns to the app via deep link. Native Apple Pay / Google Pay integration requires a separate Bitrix module and corresponding SDK in the app.

Approach 3: 1C-Bitrix: Mobile App

A ready-made solution from the vendor. It's a native shell (iOS + Android) that loads the mobile version of the site in a WebView with extended capabilities via a JavaScript bridge.

What's included:

• A mobile site template optimized for WebView.
• Native push notifications via the pull module (Firebase Cloud Messaging for Android, APNs for iOS).
• Camera integration for barcode scanning.
• Ready-made builds for publishing to App Store and Google Play (via Bitrix developer cabinet).

Limitations: design is constrained by the template; customization is via CSS and JavaScript inside WebView. You can't add a screen with native animation or complex UI without modifying the shell. Performance depends on mobile site load speed — essentially, it's a packaged browser.

Comparison of Approaches

Push Notifications

The pull module in Bitrix provides the server-side push infrastructure. For mobile apps, it integrates with Firebase Cloud Messaging (Android) and Apple Push Notification service (iOS). Sending a push from code:

\Bitrix\Pull\Push::add($userId, [
    'module_id' => 'sale',
    'push' => [
        'message' => 'Your order #1234 has been shipped',
        'params' => ['ORDER_ID' => 1234],
    ],
]);

For segmented campaigns (abandoned cart, personal discounts), the sender + pull combination is used: a marketer creates a segment in CRM, and sender initiates a push via pull.

Offline Mode

Full offline for the catalog is only implemented in a native app. The scheme: on first launch or on schedule, the app downloads the catalog via REST (catalog.product.list with pagination) and saves it to a local database (SQLite for React Native, Hive/Isar for Flutter). Images are cached on the device's file system. Synchronization follows the delta principle: only products with DATE_MODIFY greater than the last synchronization are requested.

Cart in offline mode is formed locally and when network appears, syncs with the server via sale.basket.addProduct. Conflicts (product out of stock, price changed) are handled by notifying the user.

Publishing to App Store and Google Play

For React Native / Flutter — standard process: build via Xcode / Android Studio, sign with certificates, upload to developer console.

For the Bitrix "Mobile App" module, Bitrix provides a build service: you upload icons, splash screens, and configuration to the cabinet, get ready .ipa and .aab files. You publish independently via your own developer account (Apple Developer Program — $99/year, Google Play — $25 one-time).

Important: Apple regularly tightens rules for WebView wrapper apps. If the app doesn't provide significant native functionality on top of the web version, there's a risk of rejection during review.