עוברים מ-OneSignal? 9 כלים להחלפת push SDK בטוחה באפליקציות גדולות

באפליקציה קטנה, מיגרציה מה-SDK של OneSignal פירושה להחליף קריאת init 1 ו-click handler. באפליקציה גדולה, OneSignal יושב בעשרות מקומות: tags שנקבעים במודול הפרופיל, external user ID ב-auth, click handlers בניווט, טריגרים של in-app איפשהו ב-checkout.

פספסתם אחת מהקריאות האלה, ושום דבר לא קורס. ה-segments זזים בשקט, deep links פותחים את מסך הבית, והפוש שהחזיר משתמשים פשוט מפסיק להגיע.

המדריך הזה מכסה 9 כלים שהופכים את ההחלפה לבטוחה, מקובצים לפי 5 שלבי המיגרציה: מיפוי, החלפה, בדיקה, rollout וניטור. הוא מיועד לצוותי פיתוח שמחפשים חלופה ל-OneSignal ולא רוצים לשבור את ה-retention בדרך.

לצד של הספק, ראו את המדריך המלא למיגרציה מ-OneSignal ל-Pushwoosh.

למה מיגרציות push SDK נשברות באפליקציות גדולות

push SDK נוגע ביותר חלקים בקוד מרוב ספריות הצד השלישי. בדרך כלל 4 דברים משתבשים:

• קריאות מפוזרות. tags, external user IDs ו-click handlers יושבים במודולים שונים, לפעמים בריפוזיטוריז שונים. חיפוש טקסט של ״OneSignal״ מוצא את הקריאות הברורות ומפספס wrappers.
• תלויות נסתרות. אירועי אנליטיקס, deep links ובדיקות A/B תלויים לעיתים קרובות ב-callbacks של ה-SDK. מסירים את ה-callback, ודשבורד במורד הזרם נעשה שטוח.
• 2 SDKs, build 1. שני push SDKs באפליקציה אחת מתחרים על אותם notification callbacks. לכן מדריך המיגרציה של Pushwoosh אומר להסיר את ה-SDK של OneSignal באותו release שמוסיף את החדש.
• כשלים שקטים. פוש שלא נמסר לא זורק שגיאה. דוחות הקריסה נשארים נקיים.

תהליך המיגרציה, שלב אחר שלב

לכל שלב יש אופן כשל משלו וכלים משלו.

9 כלים למיגרציה בטוחה מה-SDK של OneSignal

שלב 1. ממפים כל קריאה של OneSignal

1. CodeAlive: הכי מתאים למיפוי קריאות SDK בבסיסי קוד גדולים ומרובי ריפוזיטוריז

CodeAlive נותן לסוכני קוד מבוססי AI הקשר מדויק על כל בסיס הקוד ומקצץ את הטוקנים שהם מבזבזים בחיפוש אחריו. זה מנוע הקשר שבנוי לבסיסי קוד של 1M+ שורות: חיפוש סמנטי ועוד גרף קשרים של קבצים, סמלים, קריאות, תלויות ובדיקות, שמוגש דרך MCP ו-API.

מה הוא עושה במיגרציה: לפני שמישהו נוגע בקוד, שואלים את CodeAlive איפה משתמשים ב-OneSignal ומה תלוי בו. גרף הקשרים מראה קריאות מעבר לברורות: wrappers, callbacks שהאנליטיקס תלוי בהם, בדיקות שעושות mock ל-SDK. אותו הקשר עובר לסוכן ה-AI שמבצע את ההחלפה.

פיצ׳רים מרכזיים:

• אחזור היברידי: חיפוש סמנטי, התאמה לקסיקלית ומעבר על הגרף בשאילתה 1
• האינדקס מתעדכן בכל push, כך שהמפה נשארת עדכנית בזמן שענף המיגרציה זז
• כלי MCP, כולל semantic_search, ‏grep_search ו-chat, עבור Cursor, Claude Code, Codex, Windsurf, Zed, Continue ו-Cline
• סקירת pull requests עם AI שמביאה בחשבון את כל המערכת
• ספקי Git: GitHub, GitLab, Bitbucket, Azure DevOps, Gitea. סביבות פיתוח: VS Code ו-JetBrains

יתרונות:

שלב 2. מחליפים את ה-SDK ומעבירים את הקהל

2. Pushwoosh: הכי מתאים כפלטפורמת יעד עם ייבוא קהל

Pushwoosh היא פלטפורמת מעורבות לקוחות עם push, in-app, email, SMS ו-WhatsApp. במיגרציה, צוות Pushwoosh מייבא את הקהל שלכם בזמן שהמפתחים שלכם משחררים את ה-SDK החדש.

מה היא עושה במיגרציה: push tokens של iOS, ‏Android ו-Huawei מיובאים וממשיכים לעבוד, כי ה-tokens שייכים לאפליקציה שלכם ולמפתחות שלכם. גם מנויי אימייל ו-SMS עוברים בייבוא. ה-external_user_id ממופה ל-User ID של Pushwoosh (בקשו את העמודה הזו בייצוא מ-OneSignal, היא לא נמצאת בייצוא ברירת המחדל), וה-tags נוצרים מחדש מהייצוא שלכם. Web push הוא היוצא מן הכלל: אף ספק לא יכול להעביר מנויי דפדפן, ולכן ה-Web SDK של Pushwoosh רושם מחדש את המבקרים בשקט.

פיצ׳רים מרכזיים:

• SDKs ל-iOS ול-Android, ובנוסף React Native, Flutter, Unity, Capacitor, Cordova, MAUI, Expo ועוד
• ייבוא קהל שרץ במקביל ל-release של ה-SDK, כך שהמכשירים זמינים עוד לפני שהמשתמשים מעדכנים
• מכשירי בדיקה לתצוגה מקדימה של פוש על מכשיר אמיתי לפני השליחה

יתרונות:

תמחור: מסלול ה-push-only עולה $7 לכל 1,000 MAU, ו-1,000 ה-MAU הראשונים חינם. השוו את החשבון הנוכחי שלכם עם מחשבון העלויות של OneSignal.

שלב 3. בודקים רישום ו-delivery

3. Apple Push Notifications Console: הכי מתאים לבדיקת delivery ב-iOS דרך APNs

ה-Push Notifications Console הוא כלי הווב של Apple לשליחת התראות בדיקה דרך APNs. זו דרך מהירה לשלול את הספק כשפוש ב-iOS לא מגיע. בישראל, שבה חדירת ה-iOS מהגבוהות בעולם, זו בדיקה שלא כדאי לדלג עליה.

מה הוא עושה במיגרציה: שולחים פוש ישירות ל-device token ובודקים אם APNs קיבל ומסר אותו. אם הוא מגיע מכאן אבל לא מהספק החדש, בדקו קודם את קונפיגורציית הספק.

פיצ׳רים מרכזיים:

• התראות בדיקה למכשיר, עם שליחה חוזרת אחרי שינוי מאפיינים
• Delivery logs שמראים את המסלול של התראה דרך APNs, בסביבת ה-development
• אימות tokens לסביבה ולסוג פוש מסוימים
• מדדי delivery להתראות בדיקה ו-production

יתרונות:

4. Firebase Cloud Messaging: הכי מתאים לבדיקת פושים ב-Android לפי token

פושים ב-Android במכשירים עם Google Play services עוברים דרך Firebase Cloud Messaging (מכשירי Huawei בלי שירותי Google משתמשים ב-HMS Push Kit). קונסולת Firebase יכולה לשלוח הודעת בדיקה ל-registration token 1, וזה הופך אותה לכלי פשוט לבדיקת push notifications ב-builds של Android.

מה הוא עושה במיגרציה: אחרי שה-SDK החדש רושם מכשיר, מדביקים את ה-FCM token שלו בקונסולה ושולחים בדיקה. אם היא מגיעה, ה-token והגדרות Firebase תקינים.

פיצ׳רים מרכזיים:

• Send test message ל-FCM registration token מסוים מתוך הקונסולה
• בלי קוד לבדיקה מהירה, מלבד קריאת ה-token מהמכשיר

יתרונות:

5. Proxyman: הכי מתאים לבדיקת התעבורה וה-payloads של ה-SDK

Proxyman הוא פרוקסי לדיבוג HTTP ל-macOS, ‏Windows ו-Linux. הוא מראה מה ה-push SDK באמת שולח: קריאות רישום, עדכוני user ID, בקשות tags.

מה הוא עושה במיגרציה: מריצים את האפליקציה עם ה-SDK החדש ועוקבים אחרי הבקשות שלה. אם tag אף פעם לא יוצא מהמכשיר, רואים את זה כאן, הרבה לפני ש-segment יוצא ריק.

פיצ׳רים מרכזיים:

• לכידת תעבורת HTTPS מאפליקציות במכשירים, בסימולטורים ובאמולטורים
• לכידה בקליק אחד מ-iOS Simulator ומ-Android Emulator במסלולים בתשלום
• Breakpoints ו-Map Local/Remote לעריכת בקשות ותגובות

שלב 4. משחררים בשלבים

6. fastlane: הכי מתאים לאוטומציה של releases הדרגתיים

fastlane היא פלטפורמת קוד פתוח לאוטומציה של deployment ל-iOS ול-Android. במיגרציה, הערך שלה הוא ב-2 פרמטרים שאפשר לכתוב לתוך ה-release lane.

מה היא עושה במיגרציה: upload_to_app_store מקבל phased_release: true, שמשחרר את העדכון לאורך 7 ימים. upload_to_play_store מקבל ערך rollout, החלק מהמשתמשים שמקבלים את ה-build (0.1 עבור 10%; 1 משלים את ה-rollout). ה-release של המיגרציה עובר כל פעם באותו מסלול הדרגתי, ואף אחד לא שוכח לסמן את התיבה.

פיצ׳רים מרכזיים:

• deliver / upload_to_app_store עם phased_release
• supply / upload_to_play_store עם rollout ו-release_status (כולל halted)
• lane 1 לשתי החנויות

יתרונות:

7. App Store phased release ו-Google Play staged rollouts: הכי מתאים להגבלת רדיוס הפגיעה

שתי החנויות מאפשרות לשחרר עדכון קודם לחלק מהמשתמשים. לא משנה באילו כלי release אתם משתמשים, זו רשת הביטחון להחלפת push SDK.

מה הן עושות במיגרציה: ה-build החדש עם Pushwoosh מגיע לחלק קטן מהמשתמשים. אם ה-deliveries או שיעורי הקריסה נראים לא תקינים, עוצרים את ה-rollout לפני שהוא מגיע לכולם. בינתיים OneSignal ממשיך לשלוח למשתמשים שעוד לא עדכנו, כך שאף אחד לא מפספס קמפיין.

פיצ׳רים מרכזיים:

• App Store: שחרור לאורך 7 ימים ל-1%, ‏2%, ‏5%, ‏10%, ‏20%, ‏50% ואז 100% מהמשתמשים עם עדכונים אוטומטיים. אפשר להשהות עד 30 יום בסך הכול או לשחרר לכולם בכל רגע
• Google Play: אתם קובעים את האחוז ומעלים אותו ידנית. אפשר לעצור ולחדש את ה-rollout, ומשתמשים שכבר עדכנו נשארים עם ה-build
• דגימה אקראית של משתמשים בשתי החנויות

יתרונות:

שלב 5. מנטרים קריסות ו-delivery

8. Firebase Crashlytics: הכי מתאים לתפיסת קריסות אחרי ההחלפה

Firebase Crashlytics מדווח על קריסות ושגיאות non-fatal מאפליקציות Android, ‏Apple, ‏Flutter ו-Unity. הריצו אותו לאורך כל ה-rollout והשוו את ה-build החדש לקודם.

מה הוא עושה במיגרציה: קריסה ב-notification handler או בזמן init של ה-SDK מופיעה כאן ראשונה. אירועי non-fatal עוזרים בבעיות השקטות יותר: רשמו non-fatal כשרישום הפוש נכשל, ותראו אותו לפי build.

פיצ׳רים מרכזיים:

• דוחות קריסה מקובצים ל-issues, עם סינון לפי build
• אירועי non-fatal, שנרשמים במכשיר ונשלחים בהפעלה הבאה של האפליקציה
• SDKs רשמיים ל-Android, ‏Apple, ‏Flutter ו-Unity

9. סטטיסטיקות הודעות של Pushwoosh: הכי מתאים לזיהוי ירידות שקטות ב-delivery

דוחות קריסה לא יגידו לכם שפושים הפסיקו להגיע. סטטיסטיקות הפוש של Pushwoosh כן.

מה הן עושות במיגרציה: לכל פוש רואים את המשפך מהקהל ועד שליחות, deliveries ופתיחות, לפי פלטפורמה, ובנוסף לשונית נפרדת לשגיאות. השוו את הקמפיינים הראשונים אחרי המעבר למספרים שלכם מ-OneSignal מלפני כן. אם ה-deliveries ב-iOS מפגרים אחרי Android, בדקו credentials לפני שאתם בודקים קוד.

תוכנית מיגרציה ב-5 שלבים לאפליקציות גדולות

עושים אינוונטר של כל קריאה ל-OneSignal לפני שנוגעים בקוד

רשמו כל קריאת SDK, ‏wrapper, ‏callback ובדיקה, בכל הריפוזיטוריז. הרשימה הזו הופכת לצ׳קליסט להחלפה ול-code review.

עוטפים את הפוש מאחורי ממשק פנימי 1

נתבו כל קריאת פוש דרך שירות פנימי יחיד: login, ‏logout, ‏tags, טיפול בהתראות. כך המיגרציה משנה מימוש 1 במקום 50 נקודות קריאה, וגם החלפת הספק הבאה נעשית קלה יותר.

protocol PushService {
    func login(userId: String)
    func setTags(_ tags: [String: Any])
    func handleNotificationOpen(_ payload: [AnyHashable: Any])
}

מחליפים SDKs ב-release 1

הוסיפו את ה-SDK של Pushwoosh והסירו את ה-SDK של OneSignal באותו build. שני push SDKs באפליקציה אחת מתחרים על notification callbacks. בזמן שה-build החדש מתגלגל, המשיכו לשלוח מ-OneSignal למשתמשים בגרסה הישנה.

משחררים בשלבים ומשווים מדדי delivery

התחילו עם חלק קטן מהמשתמשים דרך phased release או staged rollout. עקבו אחרי קריסות ב-Crashlytics ואחרי deliveries בסטטיסטיקות של Pushwoosh, ואז הרחיבו את ה-rollout.

עוצרים שליחות מ-OneSignal רק אחרי שה-delivery אומת

עד שמפסיקים לשלוח מ-OneSignal, rollback פירושו להמשיך לשלוח מ-OneSignal. נתקו אותו ברגע שגם ה-delivery של Pushwoosh וגם ייבוא הקהל אושרו.

שאלות נפוצות