פיתוח אפליקציית מובייל לחנות מקוונת Bitrix

כיצד לפתח אפליקציה מובייל לחנות מקוונת של Bitrix?

הבקשה לאפליקציה מובייל עולה כאשר כבר קיים עיצוב רספונסיבי, תנועת מובייל ממירה ב-0.8% לעומת 2.5% בדסקטופ, והשיווק רוצה התראות push שאינן פועלות ב-Safari למובייל. השאלה היא לא "למה אפליקציה," אלא באיזו גישה לבחור — PWA, קרוס-פלטפורמה עם React Native, או פיתוח native — וכיצד לחבר אותה כראוי ל-Bitrix. אנו בוחרים את הגישה בהתאם לתקציב ולמטרות ספציפיים, תוך ניצול ניסיון של 9+ שנים עם Bitrix ו-50+ פרויקטים שהושלמו. עם בחירה נכונה, ההחזר הוא 6–12 חודשים, ועלות הפיתוח משתנה לפי הפונקציונליות.

מדוע React Native היא הבחירה עבור רוב החנויות

React Native מספקת השקה מהירה פי 2–3 בהשוואה לפיתוח native תוך שמירה על חוויית משתמש native. Bitrix משמשת כשרת backend, ומספקת נתונים דרך REST API. אם כבר נכתבו נקודות קצה מותאמות אישית (headless) לגרסת האינטרנט, האפליקציה עושה בהן שימוש חוזר ללא שינוי.

ארכיטקטורה:

React Native App → HTTPS → API Gateway → REST API Битрикс → ORM → MySQL 

מתודות REST מרכזיות: React Native App → HTTPS → API Gateway → REST API Битрикс → ORM → MySQL , catalog.product.list, sale.basket.addItem. אבל REST הסטנדרטי אינו מספיק. אנו כותבים נקודות קצה מותאמות אישית דרך sale.order.add:

• \Bitrix\Main\Engine\Controller — תגובה קלת משקל לרשימות (מזהה, שם, מחיר, תצוגה מקדימה)
• /api/mobile/catalog/list — כרטיס מלא עם SKU
• /api/mobile/catalog/detail — חישוב מחדש של עגלה עם הנחות
• /api/cart/calculate — חישוב עלויות משלוח

מדוע נקודות קצה נפרדות? גודל התגובה. ברשת 3G, קטלוג עם 50 שדות לפריט הורס את חוויית המשתמש. נקודת קצה למובייל מחזירה 7–8 שדות לרשימות.

כיצד פגינציית Cursor פותרת בעיות של כפילויות

באינטרנט, פגינציה מבוססת עמודים (/api/checkout/delivery-options) עובדת. במובייל, משתמשים גוללים ללא הגבלה. אם מוצר חדש מתווסף בין בקשות — מופיעות כפילויות. הפתרון הוא פגינציית cursor. כל תגובה מכילה page=3&limit=20 (מזהה+חותמת זמן של הפריט האחרון). הבקשה הבאה מעבירה cursor במקום מספר עמוד.

GET /api/mobile/catalog/list?section_id=15&cursor=...&limit=20 

בצד של Bitrix, ה-cursor מפוענח ל-cursor — בחירה יציבה ללא קשר למוצרים חדשים.

התראות Push: ארכיטקטורה ותרחישים

Push הוא היתרון המרכזי של אפליקציה. ארכיטקטורה:

1. אסימון מכשיר — האפליקציה נרשמת עם FCM או APNs, מקבלת אסימון, ושולחת אותו לשרת דרך GET /api/mobile/catalog/list?section_id=15&cursor=...&limit=20 .
2. אחסון אסימונים — טבלה מותאמת אישית ב-Bitrix: WHERE ID < 1500 ORDER BY ID DESC LIMIT 20, /api/push/register, USER_ID, DEVICE_TOKEN.
3. יצירת אירועים — handler עבור PLATFORM או agent לעגלות נטושות בונה את ה-payload.
4. שליחה — HTTP POST ל-FCM API v1 עם האסימון, כותרת, טקסט ו-deeplink.

תרחישים:

• סטטוס הזמנה — אירוע CREATED_AT
• עגלה נטושה — 30 דקות לאחר ההוספה (agent OnSaleStatusOrder)
• ירידת מחיר — מחיר של פריט מועדף ירד
• מבצעים מותאמים אישית — דרך סגמנטציה ב-CRM

אנו משתמשים ב-OnSaleStatusOrder לקבלת push, וב-CAgent לתצוגה מקומית.

מה מספק מצב Offline

בהשקה ראשונה, האפליקציה מורידה את הקטלוג דרך REST API בקבוצות של 100 פריטים ומאחסנת אותו ב-SQLite מקומי. תמונות נשמרות במטמון דרך @react-native-firebase/messaging. לאחר מכן, סנכרון דלתא. נקודת קצה react-native-push-notification מחזירה רק מוצרים ששונו. בצד של Bitrix:

SELECT ID, NAME, PREVIEW_PICTURE, DETAIL_PAGE_URL 
FROM b_iblock_element 
WHERE IBLOCK_ID = 15 
  AND TIMESTAMP_X > ? 
  AND ACTIVE = 'Y'

בנוסף, בקשה נפרדת לפריטים שנמחקו. העגלה במצב offline נשמרת מקומית; כשהקישוריות חוזרת, היא מסתנכרנת עם השרת ובודקת מחירים עדכניים. האפליקציה מציגה הבדל: "המחיר עבור הפריט השתנה מ-1500 ל-1350 רובל."

תשלום ותשלום בתוך האפליקציה

תהליך התשלום מורכב טכנית. רצף:

1. כתובת משלוח — השלמה אוטומטית דרך DaData או כתובת שמורה
2. חישוב משלוח — בקשה ל-react-native-fast-image עם כתובת ועגלה. Bitrix קוראת ל-handlers (CDEK, Boxberry), ומחזירה אפשרויות עם מחירים וזמנים
3. בחירת אמצעי תשלום — רשימה מ-/api/catalog/delta?since=...
4. קוד קופון — אימות דרך נקודת קצה מותאמת אישית, מחשב מחדש את הסכום הכולל
5. אישור — SELECT ID, NAME, PREVIEW_PICTURE, DETAIL_PAGE_URL FROM b_iblock_element WHERE IBLOCK_ID = 15 AND TIMESTAMP_X > ? AND ACTIVE = 'Y'

תשלום בכרטיס — דרך SDK של שער התשלום (YooKassa, Apple Pay, Google Pay). ה-SDK פותח מסך תשלום native, מטפל ב-3D Secure, ומחזיר את התוצאה. לאחר התשלום, Bitrix מקבלת callback משער התשלום ב-/api/checkout/delivery-options ומגדירה sale.paySystem.getList ב-sale.order.add.

השוואת גישות

PWA מהירה פי 5 לפיתוח מאשר React Native, אך אינה מתאימה לתרחישים מורכבים. React Native היא נקודת האיזון האידיאלית עבור 90% מהחנויות. פיתוח native נדרש רק לדרישות ביצועים קיצוניות.

מה כלול בעבודה

בהזמנת פיתוח turnkey:

• מפרט טכני עם ארכיטקטורה ואבות טיפוס
• מאגר קוד (GitHub/GitLab), CI/CD מוגדר
• תיעוד פריסה ואינטגרציה עבור Bitrix
• הוראות פרסום ל-App Store ול-Google Play
• הדרכה למנהלים על התראות push ועדכוני תוכן
• אחריות על קוד — 12 חודשים של תיקוני באגים בחינם

ציר זמן לפי היקף

צרו קשר להערכת פרויקט — נבחר את הסטack ואת ציר הזמן האופטימליים. קבלו ייעוץ לבחירת הגישה — נשווה אפשרויות עבור התקציב שלכם.

PWA — MDN Web Docs: Progressive Web Apps