אם אתם בונים את האפליקציה שלכם מול ה-SDK של iOS 27 בלי לאמץ את ה-UIScene lifecycle, האפליקציה פשוט לא תעלה. ואפליקציה שלא עולה אף פעם לא נרשמת ל-push, כך שההתראות שלכם משתתקות בלי שום crash report שמצביע על push כסיבה. הסימפטום נראה כמו בעיית delivery. בפועל זו בעיית launch.
הפינה הזו תופסת צוותים לא מוכנים בדיוק כי push ועליית האפליקציה חיים בשני עולמות נפרדים לגמרי — גם בקוד וגם בראש של מי שכותב אותו. iOS 27 מחבר בין השניים. המדריך הזה מכסה מה בדיוק נשבר, השרשרת המדויקת שמשתיקה את ההתראות שלכם, מי נמצא בטווח הפגיעה, וצ’קליסט ה-migration לתיקון. Pushwoosh היא פלטפורמת customer engagement, וה-iOS SDK שלנו כבר מטפל במעבר הזה, אבל התיקון למטה רלוונטי בין אם אתם משתמשים בנו ובין אם לא.
חלק ממדריך ה-iOS 27 המלא שלנו. כל עוד עובדים על ה-SDK, שווה גם לבדוק את טווח המכשירים האמיתי שלכם.
מה באמת נשבר
Apple הודיעה ב-WWDC25 שהגרסה שאחרי iOS 26 תחייב UIScene lifecycle בכל אפליקציית UIKit שנבנית עם ה-SDK העדכני ביותר. iOS 27 היא הגרסה הזו. הדרישה כבר נאכפת.
הטריגר הוא הדבר הכי חשוב, ורוב הדיונים המבוהלים טועים בו: האכיפה קורית כשאתם בונים מול ה-SDK של iOS 27 ב-Xcode 27, ולא סתם כשמשתמש מריץ את האפליקציה הקיימת שלכם על iPhone עם iOS 27. ה-build שכבר בחנות ממשיך לעבוד על מכשירים מעודכנים. השבירה מגיעה עם ה-release הבא שלכם, שקומפל עם ה-SDK החדש. ההבחנה הזו קונה לכם זמן, אבל רק עד ההגשה הבאה.
מה שכן נשאר בדיוק כפי שהיה, ופה כתבות ה-scare נוטות להגזים: זרימת ה-APNs עצמה לא נגעו בה בכלל. אתם עדיין מבקשים authorization, עדיין קוראים ל-registerForRemoteNotifications(), ועדיין מקבלים את ה-device token ב-didRegisterForRemoteNotificationsWithDeviceToken. ה-callback הזה נשאר ב-AppDelegate, ונכון להיום אין ב-iOS 27 מקבילה מבוססת scene להעביר אותו אליה. מנגנון ה-push תקין לגמרי. מה ש-Apple שינתה זה את ה-launch.
השרשרת שמשתיקה את ה-push שלכם
כשאפליקציה בלי scene manifest נבנית מול ה-SDK של iOS 27, הכשל מתרחש בסדר הזה:
- UIKit דורש scene adoption בעת ההפעלה ולא מוצא
UIApplicationSceneManifestב-Info.plist שלכם. - האפליקציה מסתיימת לפני שאף method ב-AppDelegate מתבצע.
- מכיוון ש-
application(_:didFinishLaunchingWithOptions:)אף פעם לא רץ, גםregisterForRemoteNotifications()לא נורה. - בלי רישום,
didRegisterForRemoteNotificationsWithDeviceTokenאף פעם לא נקרא, כך שהאפליקציה אף פעם לא מקבלת token של APNs. - בלי token, אין delivery. ומכיוון שהאפליקציה קרסה בעת ה-launch, ה-logs מצביעים על ההפעלה, לא על ה-pipeline של ההתראות.
הסיבה שזה גוזל כל כך הרבה זמן דיבוג היא שהסימפטום והגורם יושבים רחוק מאוד זה מזה. אתם רואים delivery חסר ומתחילים לבדוק את ספק ה-push, את ה-payloads, את הסרטיפיקטים. התקלה האמיתית נמצאת שלוש שכבות מעל, בקובץ manifest שאין לו שום קשר להתראות.
מי נמצא בטווח הפגיעה
הדרישה פוגעת באפליקציות UIKit, אבל עד כמה — תלוי ב-stack שלכם.
| Stack | רמת חשיפה |
|---|---|
| UIKit נטיבי | ישירה. אם אתם הבעלים של ה-AppDelegate lifecycle, אתם הבעלים של ה-migration. |
| SwiftUI | סיכון נמוך יותר אם אתם משתמשים ב-App protocol וב-WindowGroup, שכבר מבוססים על scene. אפליקציות שעדיין נשענות על UIApplicationDelegateAdaptor עם לוגיקת חלון מותאמת אישית צריכות בדיקה. |
| Flutter | ה-framework מבצע migration אוטומטי לאפליקציות עם AppDelegate לא ששונה בגרסאות האחרונות, אבל כל לוגיקה נטיבית מותאמת אישית חייבת migration ידני. |
| React Native | תלוי במודולים הנטיביים שלכם ובכל wrapper של SDK צד שלישי שמתחבר ל-AppDelegate. |
App protocol וב-WindowGroup, שכבר מבוססים על scene. אפליקציות שעדיין נשענות על UIApplicationDelegateAdaptor עם לוגיקת חלון מותאמת אישית צריכות בדיקה.הנקודה הרגישה עבור צוותים cross-platform היא לא ה-framework, אלא ה-SDKs שיושבים מעליו. כל SDK של push או analytics שמתקין את עצמו על ידי עטיפת ה-AppDelegate שלכם עלול לחסום את ה-migration ל-scene עד שהספק הזה ישחרר תמיכה משלו. אם dependency מסוים הוא הבעלים של נקודת הכניסה @main שלכם, אתם ממתינים ל-release שלו, לא רק לשלכם. ראינו migration שנתקע שבועיים בדיוק בגלל זה — dependency אחד לא משתף פעולה, בזמן שכל מה שהצוות שלט בו בפועל כבר היה מוכן. תבדקו את התאימות ל-scene של ה-notification SDK שלכם לפני שאתם מניחים שה-migration הוא עניין של יום אחד. אם אתם על ה-Flutter plugin שלנו, דף בעיות ה-migration הידועות הוא הדבר הראשון שכדאי לקרוא.
צ’קליסט ה-migration
התיקון לא השתנה מאז שה-scenes הוצגו ב-2019. מה שהשתנה הוא שהוא הפסיק להיות אופציונלי.
- הוסיפו scene manifest. הוסיפו
UIApplicationSceneManifestל-Info.plist, או הגדירו scenes בקוד דרך המתודות של UIApplicationDelegate ו-UISceneDelegate. - צרו SceneDelegate. אם אין לכם, הוסיפו אחד וודאו שהוא באמת מקומפל לתוך ה-target שלכם. SceneDelegate שקיים בפרויקט אבל מעולם לא נוסף ל-build sources הוא מלכודת נפוצה.
- העבירו את יצירת החלון. בעלות החלון עוברת מחוץ ל-AppDelegate. החליפו את
UIWindow(frame:)ב-UIWindow(windowScene:)ואחסנו את ה-root view מתוך ה-scene. - העבירו את טיפול ה-UI lifecycle. מעברי foreground, background ו-active/inactive עוברים ל-UISceneDelegate. אחרי ה-migration, UIKit מפסיק לקרוא למתודות מצב UI על ה-AppDelegate, כך שכל מה שנשאר שם מפסיק לפעול בשקט.
- השאירו את רישום ה-push במקומו. רישום ה-token וה-callbacks שלו נשארים ב-AppDelegate. אל תעבירו אותם בשם סימטריה.
- בצעו migration לטיפול ב-URL ו-deep link. URLs נכנסים מגיעים כעת דרך מתודות scene. אם ה-push שלכם פותח מסכים ספציפיים, זה החלק ששומר על ה-deep links שלכם פעילים.
- בנו מחדש ואמתו הנפקת token. בנו עם ה-SDK של iOS 27, הפעילו, וודאו שהאפליקציה מקבלת token של APNs. אם לא, המדריך לפתרון תקלות ב-iOS הוא נקודת ההתחלה. אמתו על build אמיתי לפני ה-release, לא אחריו.
השאירו את ה-AppDelegate. זו הנקודה שצוותים מפספסים כשהם קוראים ש”ה-AppDelegate נעלם”. הוא לא נעלם. התפקיד שלו מצטמצם לאירועי process ו-app-level, בזמן שה-UI lifecycle עובר ל-scene. רישום push הוא עניין ברמת האפליקציה, ובדיוק בגלל זה הוא נשאר במקומו.
למה הסתמכות רק על push היא שברירית
צעד אחורה. key אחד ויחיד ב-manifest, בקובץ שכמעט אף אחד בצוות לא פותח, יכול להפיל את כל ערוץ ה-push שלכם ב-release הבא. זו הרבה שבריריות שנשענת על ערוץ delivery יחיד.
וזה מעבר למגבלה שכבר קיימת ל-push מטבעו: opt-in. גם עם אסטרטגיית בקשת הרשאה טובה, חלק ניכר מהמשתמשים שלכם אף פעם לא מעניקים הרשאת push מלכתחילה, כך שביום טוב push מגיע רק לחלק מבסיס המשתמשים שלכם. תקלות פלטפורמה כמו זו רק מרחיבות את הפער בין מי שאתם יכולים להגיע אליו לבין מי שאתם באמת מגיעים אליו.
הצוותים ששורדים שינויים כאלה הם אלה שלא תלויים בערוץ יחיד. כשה-push הוא רק אמצעי delivery אחד לצד email, SMS ו-in-app, רגרסיה ב-launch של פלטפורמה אחת פוגעת בהיקף שלכם ולא מוחקת אותו. כך אתם קונים לעצמכם את המרווח בדיוק לסוג ההפתעה הזו ש-Apple שחררה עכשיו.
כל עוד העבודה על ה-SDK פתוחה, זה גם רגע טוב לבחון מחדש מה הופך התראה לכזו ששווה לשלוח.
בקשו מ-Pushwoosh לבדוק את הגדרת ה-push שלכם ל-iOS 27
ה-SDK של Pushwoosh כבר תומך ב-scene lifecycle של iOS 27, וההגדרה המולטי-ערוצית שלו אומרת שתקלה בפלטפורמה אחת אף פעם לא מפילה איתה את כל אסטרטגיית ההתראות שלכם. אם אתם באמצע migration ומשהו לא נרשם, ה-FAQ של iOS SDK מכסה את התקלות הנפוצות. ואם תרצו זוג עיניים נוסף שיבדוק אם רישום ה-push שלכם שורד את המעבר, נשמח לעבור איתכם על האינטגרציה.
שאלות נפוצות
didRegisterForRemoteNotificationsWithDeviceToken נשארים ב-AppDelegate שלכם. ב-iOS 27 אין מקבילה מבוססת scene להעביר אותם אליה, וניסיון להעביר אותם הוא טעות. רק ה-UI lifecycle עובר ל-scene.
מאמרים קשורים
הצג הכל