מנוי לאותות מסחר: אספקה בזמן אמת ללא עיכובים
משתמש שילם עבור מנוי לאותות מסחר אך קיבל התראת push 40 שניות לאחר יצירת האות — עד אז המחיר כבר זז. ההבדל בין 500 אלפיות השנייה ל-40 שניות קובע את תוצאת העסקה. WebSocket מהיר פי 100 מ-push כאשר האפליקציה פעילה, אך דורש ארכיטקטורה מתאימה. אנו מתכננים ערוצים כך שהשהייה תישאר מתחת ל-500 אלפיות השנייה במצב פעיל ומתחת ל-5 דקות ברקע (גיבוי push). חיסכון בתשתית push על ידי העדפת WebSocket יכול להגיע ל-30%. יש לנו ניסיון של 10+ שנים בפיתוח מובייל ומעל 50 אפליקציות שפורסמו — זה מבטיח פתרון אמין.
כיצד מנוי לאותות מסחר דרך WebSocket מבטיח אספקה תוך 100–500 אלפיות השנייה
FCM ו-APNS לבדם אינם אמינים לאספקת אותות. אפל וגוגל אינן מבטיחות השהיית התראות push — בזמני עומס, העיכובים יכולים להגיע ל-1–5 דקות. התכנית הנכונה היא שני ערוצים מקבילים:
-
WebSocket (ראשי). בזמן שהאפליקציה בחזית, היא שומרת על חיבור WebSocket (
URLSessionWebSocketTaskב-iOS,OkHttp WebSocketבאנדרואיד). האות מגיע תוך 100–500 אלפיות השנייה מיצירתו. במקרה של ניתוק חיבור — חיבור מחדש עם backoff אקספוננציאלי (1 שנייה → 2 שניות → 4 שניות → 8 שניות → מקסימום 30 שניות). אנו משתמשים ב-Protocol Buffers לסריאליזציה של הודעות כדי למזער את גודל המטען ולהפחית השהיה. -
Push (גיבוי). כאשר האפליקציה ברקע או סגורה, FCM/APNS Data Message (push שקט ב-iOS) מעיר את האפליקציה דרך
BGProcessingTaskאוUNNotificationServiceExtension.NSEרץ על כל push ויכול להציג התראה עם תוכן מפוענח — אנו מוסיפים טיקר, כיוון (קנייה/מכירה), מחיר כניסה.
| ערוץ | השהיה (מצב פעיל) | השהיה (רקע) | אמינות |
|---|---|---|---|
| WebSocket | 100–500 אלפיות השנייה | — | גבוהה |
| Push FCM/APNS | — | 1–5 דקות | בינונית |
עלויות התראות push: Firebase Cloud Messaging טיפוסי גובה $0.00 עבור 100k ההתראות הראשונות, ולאחר מכן $0.0005 לכל התראה נוספת. עבור מיליון התראות בחודש, זה $450. עם WebSocket, עלות רוחב הפס של השרת זניחה, וחוסכת עד $400 בחודש. ארכיטקטורה זו יכולה להפחית משמעותית הוצאות תפעוליות.
ניואנס חשוב ב-iOS: ל-UNNotificationServiceExtension יש כ-30 שניות לעבד. אם contentHandler לא נקרא בזמן, המערכת מציגה את ה-push המקורי. NSE לא אמור לבצע בקשות רשת כבדות.
כיצד ליישם מנוי בתשלום לאותות מסחר עם תקופת חסד
מודל: גישה בתשלום דרך Auto-Renewable Subscription באמצעות StoreKit 2 ב-iOS ו-Play Billing Library 6+ באנדרואיד. משתמש ללא מנוי פעיל רואה אותות עם עיכוב (מצב הדגמה) או לא רואה כלל.
אימות זכאות בשרת דרך App Store Server Notifications V2 (אירועי JWT חתומים על ידי APNS של אפל) ו-Google Play Real-time Developer Notifications (Pub/Sub). אנו לא מסתמכים על אימות בצד הלקוח — שרת ה-WebSocket בודק את subscription_status ממסד הנתונים שלו, המעודכן על ידי webhooks בצד השרת מהחנויות.
תקופת חסד: אם מנוי לא מתחדש עקב בעיות חיוב — אנו לא מפסיקים את הגישה מיד. StoreKit 2 Transaction.currentEntitlements מחזיר עסקה עם סטטוס inGracePeriod — אנו מציגים באנר "בעיית תשלום, עדכן את הכרטיס" ומעניקים 3–6 ימים. זה מפחית נטישה לא רצונית. לדוגמה, הפחתת נטישה לא רצונית ב-15% חוסכת עד $8,000 בהכנסה חודשית לאפליקציה עם 10,000 מנויים.
| פלטפורמה | ספרייה | אימות שרת | תקופת חסד |
|---|---|---|---|
| iOS | StoreKit 2, Transaction.currentEntitlements | App Store Server Notifications V2 | inGracePeriod |
| אנדרואיד | Play Billing Library 6+, BillingClient.queryPurchasesAsync | Google Play Real-time Developer Notifications | accountHold |
מדוע יש צורך באימות זכאות בצד השרת למנוי לאותות מסחר
אימות מנוי בצד הלקוח ניתן לעקוף. בשרת, אנו אוספים אירועים מהחנויות ושומרים את הסטטוס הנוכחי. חיבור ה-WebSocket מאומת על ידי טוקן שנבדק מול מסד הנתונים. זה מגן מפני עקיפות jailbreak וזיוף תגובות. בנוסף, עומס התמיכה מופחת — פחות מחלוקות חיוב.
מה כלול בעבודה
- תיעוד ארכיטקטוני — תכנית מנויים, בחירת מסלול, תיאור תקופת חסד וניסיון.
- פיתוח שרת WebSocket — יישום ערוץ אספקה עם backoff אקספוננציאלי.
- שילוב ערוץ push — FCM/APNS עם NSE ל-iOS וטיפול בהתראות רקע.
- יישום StoreKit 2 / Play Billing — רכישות במכשיר, אימות שרת, שילוב webhook.
- ממשק משתמש לעדכון אותות — עדכונים בזמן אמת דרך DiffableDataSource / Paging 3.
- בדיקות — מדידות השהיה, מבחני עומס עם 10k+ חיבורי WebSocket במקביל.
- פריסה וניטור — התראות תקלות, לוח מחוונים להשהיה.
- תמיכה לאחר השקה — 30 יום לתיקוני באגים וייעוץ.
תהליך
- עיצוב תכנית המנויים (מסלולים, ניסיון, תקופת חסד)
- פיתוח שרת WebSocket ושילוב ערוץ push
- יישום מנוי StoreKit 2 / Play Billing עם אימות שרת
- פיתוח ממשק משתמש לעדכון אותות בזמן אמת
- בדיקת השהיית אספקה והקמת ניטור
- תיעוד API ותהליך עבודה
- תמיכה לאחר השקה
לוחות זמנים
יישום מנוי + עדכון אותות WebSocket + גיבוי push — 3–5 ימי עסקים אם ה-API מוכן. אם זה כולל ארכיטקטורת צד שרת (שרת WebSocket, שילוב Pub/Sub עם החנות) — 2–3 שבועות.
מה הופך את היישום שלנו לאמין
אנו מתמחים בפיתוח מובייל עם ניסיון של 10+ שנים, ופרסמנו מעל 50 אפליקציות ב-App Store וב-Google Play. הבנה עמוקה של רכישות בתוך האפליקציה ותקשורת בזמן אמת מאפשרת לנו למזער השהיה ולעמוד בהנחיות סקירת App Store. הזמינו יישום — המשתמש שלכם לא יפספס אף אות. קבלו ייעוץ על מודל המנויים.