How to Develop a Mobile App for a Bitrix Online Store?
The request for a mobile app arises when responsive layout is already in place, mobile traffic converts at 0.8% vs. 2.5% on desktop, and marketing wants push notifications that don't work in mobile Safari. The question is not "why an app," but which approach to choose — PWA, cross-platform with React Native, or native development — and how to properly connect it to Bitrix. We select the approach based on specific budget and goals, leveraging 9+ years of Bitrix experience and 50+ completed projects. With the right choice, payback is 6–12 months, and development cost varies by functionality.
Why React Native Is the Choice for Most Stores
React Native delivers 2–3x faster launch compared to native development while maintaining native UX. Bitrix acts as the backend, serving data via REST API. If custom API endpoints (headless) are already written for the web version, the app reuses them unchanged.
Architecture:
React Native App → HTTPS → API Gateway → Bitrix REST API → ORM → MySQL Key REST methods: catalog.product.list, sale.basket.addItem, sale.order.add. But standard REST is insufficient. We write custom endpoints via \Bitrix\Main\Engine\Controller:
-
/api/mobile/catalog/list— lightweight response for listings (ID, name, price, preview) -
/api/mobile/catalog/detail— full card with SKUs -
/api/cart/calculate— recalculate cart with discounts -
/api/checkout/delivery-options— calculate shipping costs
Why separate endpoints? Response size. On 3G, a catalog with 50 fields per item kills UX. A mobile endpoint returns 7–8 fields for listings.
How Cursor Pagination Solves Duplicate Problems
On the web, page-based pagination (page=3&limit=20) works. On mobile, users scroll infinitely. If a new product is added between requests — duplicates appear. The solution is cursor pagination. Each response contains a cursor (ID+timestamp of the last item). The next request passes cursor instead of a page number.
GET /api/mobile/catalog/list?section_id=15&cursor=...&limit=20 On the Bitrix side, the cursor is decoded into WHERE ID < 1500 ORDER BY ID DESC LIMIT 20 — stable selection regardless of new products.
Push Notifications: Architecture and Scenarios
Push is the main advantage of an app. Architecture:
- Device token — the app registers with FCM or APNs, gets a token, sends it to the server via
/api/push/register. - Token storage — custom table in Bitrix:
USER_ID,DEVICE_TOKEN,PLATFORM,CREATED_AT. - Event generation — a handler for
OnSaleStatusOrderor an agent for abandoned carts builds the payload. - Sending — HTTP POST to FCM API v1 with the token, title, text, and deeplink.
Scenarios:
- Order status — event
OnSaleStatusOrder - Abandoned cart — 30 minutes after adding (agent
CAgent) - Price drop — a favorited item’s price decreased
- Personalized promotions — via CRM segmentation
We use @react-native-firebase/messaging to receive pushes, react-native-push-notification for local display.
What Offline Mode Provides
On first launch, the app downloads the catalog via REST API in batches of 100 items and stores it in local SQLite. Images are cached via react-native-fast-image. Then delta synchronization. Endpoint /api/catalog/delta?since=... returns only changed products. On the Bitrix side:
SELECT ID, NAME, PREVIEW_PICTURE, DETAIL_PAGE_URL FROM b_iblock_element WHERE IBLOCK_ID = 15 AND TIMESTAMP_X > ? AND ACTIVE = 'Y' Plus a separate request for deleted items. The cart offline is saved locally; when connectivity returns, it syncs with the server and checks current prices. The app shows a diff: "Price for item changed from 1500 to 1350 rub."
Checkout and Payment In-App
Checkout is technically complex. Sequence:
- Delivery address — autocomplete via DaData or saved address
- Delivery calculation — request to
/api/checkout/delivery-optionswith address and cart. Bitrix calls handlers (CDEK, Boxberry), returns options with prices and terms - Payment method selection — list from
sale.paySystem.getList - Promo code — verification via custom endpoint, recalculates total
- Confirmation —
sale.order.add
Card payment — via payment gateway SDK (YooKassa, Apple Pay, Google Pay). The SDK opens a native payment screen, handles 3D Secure, returns the result. After payment, Bitrix receives a callback from the gateway at /bitrix/tools/sale_ps_result.php and sets PAYED = 'Y' in b_sale_order.
Comparison of Approaches
| Characteristic | PWA | React Native | Native |
|---|---|---|---|
| Complexity | Low | Medium | High |
| Access to native APIs | Limited | Good | Full |
| Push on iOS | With limitations | Full | Full |
| Performance | Medium | High | Maximum |
| Development time | 2–3 days | 3–12 weeks | 8–20 weeks |
PWA is 5x faster to develop than React Native, but not suitable for complex scenarios. React Native is the sweet spot for 90% of stores. Native development is needed only for extreme performance requirements.
What Is Included in the Work
When ordering turnkey development:
- technical specification with architecture and prototypes
- code repository (GitHub/GitLab), configured CI/CD
- deployment and integration documentation for Bitrix
- instructions for publishing to App Store and Google Play
- training for administrators on push notifications and content updates
- code warranty — 12 months of free bug fixes
Timeline by Scale
| Scale | What's Included | Time (React Native) |
|---|---|---|
| PWA | Manifest, service worker, offline page | 2–3 days |
| MVP | Catalog, product card, cart, checkout, push | 3–5 weeks |
| Standard | + Account, history, favorites, offline catalog | 6–8 weeks |
| Advanced | + Scanner, AR try-on, chat, Apple Pay/Google Pay | 8–12 weeks |
Contact us for a project assessment — we'll select the optimal stack and timeline. Get a consultation on choosing the approach — we'll compare options for your budget.