אפל הכריזה על iPhone Duo, ה-iPhone המתקפל הראשון שלה, ב-9 בספטמבר 2026. Pre-order נפתח ב-16 באוקטובר, והמכשיר יוצא למכירה ב-23 באוקטובר עם iOS 27.1. הרצף מוזר: אפל פרסמה את הכללים באותו יום, אבל ה-SDK עם סימולטור Duo מגיע רק “מאוחר יותר בספטמבר”. יש תיעוד וכמעט אין hardware — בדיוק החלון הזה כדי למצוא באפליקציה שלכם את הנחות ה-layout שכבר הפסיקו להיות נכונות.
המדריך הזה מדלג על סקירת המכשיר — יהיו כבר מאות כאלה. ה-push notification עצמו מצויר על ידי המערכת, אז שם אין מה לשנות. כל מה שהאפליקציה שלכם מציירת בעצמה הוא מה שצריך עכשיו לשרוד מסך שמשנה צורה ו-aspect ratio באמצע session פעיל: הודעות in-app, rich media, ה-push primer, מסכי טעינה. זו המשטח שאפל כתבה עליו כללים חדשים, וזה בדיוק מה שרוב הצוותים עומדים לפספס.
מה בעצם השתנה ב-iOS 27 על iPhone מתקפל
ל-iPhone Duo יש 2 מסכים עם aspect ratio כמעט זהה. הפנימי הוא 7.6 אינץ’, בערך 50% יותר שטח מסך מ-iPhone 18 Pro Max; החיצוני הוא 5.4 אינץ’, בערך 90% משטח המסך של iPhone 18 Pro. הפרופורציות קרובות אך לא זהות — עוד סיבה להריץ layout לפי size classes, ולא לפי יחס שאתם מניחים שנשמר בשני המסכים.
כל אפליקציה משתתפת ב-Split View. Duo הוא ה-iPhone הראשון שמריץ כמה instances של ה-UI של האפליקציה שלכם במקביל, מה שאומר שה-in-app messaging שלכם עלול למצוא את עצמו בחצי מסך, לצד אפליקציה של מישהו אחר.
והצורה משתנה גם באמצע session. המשתמש פותח את המכשיר, או חצי-פותח אותו, בזמן שהמודל שלכם פתוח על המסך. layout מפסיק להיות משהו שמחליטים עליו פעם אחת ב-launch.
3 רמות תאימות, ואיפה רוב האפליקציות נמצאות
הכלל של אפל ברור: האפליקציה שלכם רצה על Duo בלי recompile. השאלה כמה מהמסך היא מקבלת היא התפיסה, וזה תלוי באיזה SDK בניתם.
- SDK ישן: האפליקציה רצה, אבל התוכן נשאר תחום לאזור בגודל של iPhone רגיל.
- iOS 27 SDK: ה-UI שלכם מתפרס משמאל לאזור ה-status bar במסך הפנימי.
- iOS 27.1 SDK: ה-UI שלכם מגיע עד קצה המסך, וניווט וכפתורי toolbar סטנדרטיים מסתדרים אנכית.
כלומר צוות שלא עושה כלום שולח את הודעות ה-in-app שלו בקופסה בגודל טלפון, על מסך של 7.6 אינץ’. לא שבור. פשוט בעליל לא טופל, לצד מתחרים שכן טרחו.
למה ה-layout של ה-in-app messaging שלכם מפסיק לעבוד
3 סיבות, וכולן מצטברות.
Aspect ratio. רוב תבניות ה-in-app וה-rich-media תוכננו לפי הפרופורציות של iPhone רגיל. הפרופורציות של המסך הפנימי שונות, ותבניות שנבנו לפי הישנות לא ינחתו איפה שציירתם אותן.
Orientation הוא הסיגנל הלא נכון. המסך הפנימי הוא regular בשני ה-size classes, ולא מכבד interface orientations נתמכים. כל layout branch שמבוסס על orientation קורא סיגנל שהמסך הפנימי מתעלם ממנו. ההנחיה של אפל ישירה: להחליט layout לפי size classes, לא לפי orientation.
Safe area אסימטרי. ה-insets ומרווחי ה-layout ב-Duo שונים לרוב בכל צד, אז מטפלים בכל edge בנפרד במקום להניח frame סימטרי. ואז בודקים את זה שוב ב-Split View, שם ה-frame נהיה צר שוב.
הודעת in-app שפתוחה כשהטלפון נפתח
זה המקרה ששווה לחשוב עליו, כי אף סימולטור עדיין לא נתן למישהו לראות אותו: הודעת in-app מודאלית פתוחה על המסך, והמשתמש פותח את הטלפון. ה-frame משתנה מתחת ל-view שכבר מוצג.
אפל נותנת לכם כאן 2 כלים, והבלבול ביניהם הוא הטעות הקלה.
ה-hinge APIs — onHingeChange ב-SwiftUI ו-UIHingeInteraction ב-UIKit — מדווחים על state דיסקרטי (closed, partially open, fully open) וזווית רציפה. הם נועדו למעקב חי ולהניע interactions ואפקטים. ה-demo של אפל עצמה משתמש בזווית הקיפול כדי לכופף את הצליל של כלי נגינה וירטואלי. זה המשלב שהם מיועדים לו — לא הזזת כפתורים.
Layout עובר בדלת אחרת. אפל מפנה אתכם ל-arrangement וה-region APIs מההרצאה “Strike a pose with adaptive layouts on iPhone Duo”, שמציגה reserved regions, arrangement views עם split ו-overlay layouts, ו-displacement: ריפריימינג של אלמנטים קיימים לתוך השטח שבאמת זמין, כך שתוכן נשאר גלוי ונגיש כשהמכשיר נסגר. iOS 27.1 מוסיף את ReservedRegion ב-SwiftUI ו-UIViewReservedRegion ב-UIKit, כך שה-UI המותאם אישית שלכם יכול לתבוע את השטח שהוא צריך בלי להתנגש ב-system UI. שואלים אותם עם reservedRegions(kind:), כאשר .division הוא הקיפול עצמו ו-.occlusion היא המצלמה.
עבור מודל, זה מסתכם בכלל אחד: אל תשתמשו בזווית ה-hinge כדי למקם אותו מחדש. תנו לו להגיב ל-arrangement ול-reserved region, כך שכשהמסך נפתח התוכן שלכם נוחת איפה שהוא אמור להיות, במקום להיאחז ב-frame שכבר לא קיים.
הודעות in-app ב-Split View
מכיוון שכל אפליקציה נמצאת עכשיו בבריכת ה-multitasking, הודעות ה-in-app שלכם עלולות למצוא את עצמן בחצי מסך, לצד אפליקציה זרה. זה frame הרבה יותר צר מהמסך הפנימי המלא, וזו הסיבה לבדוק ברוחב חצי. מודל שנראה טוב במסך מלא ייחתך או יתדחס כשהוא מאבד חצי מהמקום שלו.
יש גם קיר קשיח שכדאי לדעת עליו: אי אפשר לפתוח חלונות חדשים על המסך החיצוני, הוא שמור לחוויה הפנימית. כל לוגיקת הצגה שפותחת חלונות צריכה לקחת את זה בחשבון.
המסך החיצוני: ה-layout הקומפקטי שלכם, בתוספת widgets ו-Live Activities
המסך החיצוני מתנהג כמו כל מסך iPhone אחר. האפליקציה שלכם רצה שם, וכך גם כל מה שהיא מציירת, כולל הודעות in-app. המסגור של אפל הוא שהמסך החיצוני הוא compact-width layout, בדיוק כמו iPhone רגיל, בעוד המסך הפנימי הוא regular בשני הממדים. ב-5.4 אינץ’ זה ה-frame המלא הכי צר שה-in-app messaging שלכם מקבל על המכשיר הזה, אז המקום שלו הוא במטריצת הבדיקות, לא בערימת ה”לא רלוונטי”.
יש עוד שכבה מעל זו. ב-Duo, StandBy רץ על כל אחד מהמסכים גם כשהמכשיר לא נטען: מניחים את הטלפון והמסך החיצוני נשאר דלוק ומופנה לחדר. אפליקציה בלי widget ובלי Live Activity פשוט נעדרת מהרגע הזה. נוכחות שם מגיעה דרך widget או Live Activity — אותה עבודה שכבר הייתם עושים בשביל מסך הנעילה וה-Dynamic Island. אם בניתם Live Activities, זה המקום השני שההשקעה הזו מחזירה את עצמה. אם לא — הנה עוד סיבה.
רשימת תיוג לתאימות עם iPhone מתקפל לפני 23 באוקטובר
לא ניתן עדיין לגעת בחומרה, אבל כל מה שקצר מזה נמצא על השולחן:
- צרו inventory לתבניות ה-in-app וה-rich-media שלכם. מצאו כל אחת שמקבעת frame, aspect ratio, או קופסה בגודל טלפון.
- בדקו את ה-creatives ביחס 16:9. כל דבר שנבנה ליחס קבוע צריך תוכנית עבור המסך הפנימי.
- מצאו את ה-orientation branches שלכם. layout שמבוסס על interface orientation קורא סיגנל שהמסך הפנימי מתעלם ממנו, אז העבירו אותו ל-size classes.
- בדקו כל safe-area edge בנפרד. הניחו אסימטריה; אל תניחו inset סימטרי.
- חפשו
UIScreen.mainבקוד. במכשיר עם שני מסכים זה דו-משמעי, ואפל אומרת שזה יוצא משימוש. קראו את המסך מ-window?.windowScene?.screenואת ה-scale מ-traitCollection.displayScale. - בדקו ברוחב קומפקטי, לא רק פתוח. המסך החיצוני הוא המקום שבו הודעות ה-in-app שלכם מקבלות הכי פחות מקום, וזה משטח אמיתי בשבילן.
- התאימו את בדיקת ה-Device Hub שלכם. כשה-beta של Xcode 27.1 יוצא, סימולטור ה-Duo נמצא ב-Device Hub: פתחו אותו, סגרו אותו, סובבו אותו, חצי-קפלו אותו עם הודעה על המסך.
- בצעו סגמנטציה לפי מודל מכשיר. תנו לעצמכם דרך למקד משתמשי Duo לבדיקה נפרדת ברגע שהם בשטח.
- עברו שוב על טקסט ה-push notification וה-onboarding primer. ה-permission prompt שהמשתמשים רואים ב-onboarding עדיין מצויר על ידי המערכת, אבל כל מסך pre-permission מותאם אישית שמוביל אליו יורש את אותם כללי layout כמו ה-in-app messaging שלכם.
אף אחד מזה לא צריך את המכשיר. כל זה צריך להיעשות לפני שהמכשיר מגיע לידיים של המשתמשים שלכם, לא אחרי.
שילחו את ה-in-app messaging שלכם מוכן ל-Duo
לתקן את זה ידנית על פני הודעות in-app, rich media ו-push primers, בכל מסך שהמשתמשים שלכם מחזיקים, הוא בדיוק סוג הדבר שקל יותר על אינטגרציה אחת מאשר על שש. זה הטיעון בעד לנהל הודעות in-app ו-push notifications דרך פלטפורמת mobile engagement אחת כמו Pushwoosh — SDK אחד, API אחד, dashboard אחד, בלי vendor lock-in ובלי לשלם על שכבת שיווק נפרדת לכל ערוץ: התחילו בחינם או דברו עם הצוות שלנו על הכנת ה-messaging שלכם ל-Duo לפני 23 באוקטובר.
