פרסום עדכון לאפליקציית iOS: Phased Release ב-App Store
מאת Mehdi Azizi
פורסם ב-, 10 דק׳
פרסום עדכון iOS: גרסה חדשה, build חדש, טקסט What's New, ואז שחרור ידני, אוטומטי או הדרגתי לאורך 7 ימים.
כדי לפרסם עדכון לאפליקציית iOS, יוצרים גרסה חדשה ב-App Store Connect עם מספר גבוה יותר. מצרפים אליה build חדש, כותבים את הטקסט "What's New" ושולחים ל-App Review. כל גרסה חדשה עוברת שוב את הבדיקה של Apple, גם אם זה תיקון קטן. לפני השליחה בוחרים איך היא תצא אחרי האישור: ידנית, מיד, לא לפני תאריך מסוים, או בשחרור הדרגתי לאורך 7 ימים.
השחרור ההדרגתי משפיע רק על עדכונים אוטומטיים: 1% מהמשתמשים האלה ביום הראשון, כולם ביום השביעי. אפשר לעצור אותו עד 30 יום בסך הכול, או לסיים אותו בבת אחת. המדריך הזה מבוסס על דפי העזרה של Apple, שעברתי עליהם שוב ב-3 בנובמבר 2026.
אני מפרסם את העדכונים של אפליקציות ה-iOS שלי עם Expo ו-EAS, ביניהן Solys, TradaZen ו-Nolera. המקרים שמופיעים בהמשך לקוחים מהשחרורים האלה.
פרסום עדכון iOS: השלבים לפי הסדר
העזרה של App Store Connect על גרסאות חדשות מתארת את המסלול הזה:
- ב-Apps, בוחרים את האפליקציה ולוחצים על כפתור ה-+ ליד הפלטפורמה.
- מזינים מספר גרסה גבוה מהקודם ולוחצים על Create.
- עוברים על המטא-דאטה: זו של הגרסה שבאוויר מועתקת אוטומטית.
- שולחים build חדש, עם מספר build מוגדל.
- בודקים את ה-build ב-TestFlight, מוסיפים אותו לגרסה ושולחים ל-App Review.
שני תנאים לפני שמתחילים. הגרסה שבאוויר צריכה להיות בסטטוס Ready for Distribution. וצריך אחד מהתפקידים האלה: Account Holder, Admin, App Manager או Marketing.
אין דרך לחזור אחורה. Apple כותבת את זה באותו דף: אם גרסה עושה בעיות, אי אפשר לחזור לקודמת. צריך ליצור ולשלוח גרסה חדשה.
מספר גרסה ומספר build
הגרסה היא המספר שהלקוחות רואים בדף האפליקציה. ה-build מזהה כל שליחה. הצירוף של גרסה ו-build חייב להיות ייחודי: הכללים והשגיאות הקשורות מופיעים ב-גרסה ומספר build.
השיטה שלי, שהיא לא כלל של Apple: הספרה האחרונה עולה בתיקון, מ-1.4.0 ל-1.4.1. האמצעית עולה בפיצ'ר חדש, מ-1.4.1 ל-1.5.0. מספר ה-build רק עולה, מגרסה לגרסה. ב-Expo, הגרסה נמצאת ב-app.json ו-EAS יכול להגדיל את ה-build בכל קומפילציית production. ההגדרה מוסברת ב-פרסום אפליקציית Expo עם EAS.
הטקסט "What's New": מה Apple דורשת
דף פרטי הגרסה מתאר את השדה What's New in This Version:
- עד 4,000 תווים.
- לא קיים בגרסה הראשונה, חובה בכל הגרסאות שאחריה.
- אפשר לתרגם אותו לכל שפה בדף האפליקציה.
סעיף 2.3.12 ב-App Review Guidelines מוסיף דרישה: לתאר בבירור את הפיצ'רים החדשים והשינויים במוצר. ניסוח כללי מספיק לתיקוני באגים, אבטחה או ביצועים פשוטים. שינוי משמעותי חייב להופיע ברשימה. כלומר "תיקוני באגים ושיפורים" לא מספיק לגרסה שמשנה את המנוי או את המסך הראשי.
Apple גם ממליצה, ב-דף שלה על דירוגים וביקורות, לציין בהערות את הבעיות שתוקנו ושלקוחות תיארו בביקורות שלהם.
הנה שלוש תבניות להתאמה, אחת לכל סוג גרסה.
לתיקון:
תיקונים ויציבות.
- [פיצ'ר]: [מה שלא עבד] תוקן.
- [מסך] נטען מהר יותר.
תודה לכל מי שדיווח.
לפיצ'ר חדש:
חדש: [הפיצ'ר, בחמש מילים].
[מה אפשר לעשות עכשיו, במשפט אחד.]
איפה למצוא: [לשונית] > [כפתור].
עוד בגרסה הזו:
- [שיפור שרואים].
- תיקוני באגים.
למסלול שמשתנה:
[מסך או מסלול] משתנה.
- מה משתנה בשבילך: [השפעה מוחשית].
- מה נשאר: [נתונים, הגדרות, רכישה].
יש שאלה? [הגדרות] > [עזרה].
השורה האחרונה בתבנית התיקון רלוונטית רק אם מישהו באמת דיווח על הבעיה. אף פעם אל תכתבו חידוש שלא נמצא ב-build: סעיף 2.3 דורש מטא-דאטה שנאמנה לאפליקציה.
שחרור ידני, אוטומטי או בתאריך
העזרה על אפשרויות השחרור מציעה שלוש:
| אפשרות | אחרי האישור של Apple |
|---|---|
| ידני | סטטוס Pending Developer Release, מפרסמים מתי שרוצים |
| אוטומטי | הגרסה יוצאת מיד עם האישור |
| אוטומטי, לא לפני... | היא מחכה לתאריך שנבחר ואז יוצאת לבד |
בשחרור ידני, פותחים את הגרסה בסטטוס Pending Developer Release, לוחצים על Release This Version ומאשרים. Apple מזהירה שזה יכול לקחת עד 24 שעות עד שהיא מופיעה ב-App Store. הודעה בדף הגרסה מציעה Cancel This Release לביטול. אם הגרסה נשארת בהמתנה יותר מ-30 יום, Apple שולחת תזכורת במייל.
שחרור ידני נועד לבחור את הרגע, למשל כדי לפרסם ביום של הכרזה. Solys 2.0.0, שכללה גרסה חדשה של המנוי השנתי, נשלחה לבדיקה בסוף ספטמבר 2026 עם שחרור ידני.
לגרסה שגרתית אני משאיר שחרור אוטומטי. Nolera 1.0.2, שאושרה ב-12 באוקטובר 2026, הופיעה ב-App Store פחות מדקה אחרי המייל של Apple, לפי ה-API הציבורי של החיפוש ב-iTunes. זו תצפית אחת בלבד: תשאירו מרווח.
שחרור הדרגתי לאורך 7 ימים
העזרה של Apple על שחרור הדרגתי נותנת את לוח הזמנים המדויק:
| יום | אחוז מהמשתמשים |
|---|---|
| 1 | 1% |
| 2 | 2% |
| 3 | 5% |
| 4 | 10% |
| 5 | 20% |
| 6 | 50% |
| 7 | 100% |
העדכון יוצא למדגם אקראי של משתמשים שהפעילו עדכונים אוטומטיים, במכשירים תואמים. הם לא מקבלים הודעה שהם חלק ממנו.
השחרור ההדרגתי מאט רק עדכונים אוטומטיים. Apple מבהירה שכל אחד יכול להוריד את הגרסה החדשה מה-App Store בכל רגע. מי שמתקין את האפליקציה, או לוחץ על Update בדף שלה, יכול לקבל אותה כבר ביום הראשון. זה לא ניסוי על 1% מהמשתמשים: זה בלם על כל השאר.
כדי להפעיל, פותחים את הגרסה, יורדים לסעיף Phased Release for Automatic Updates, מסמנים את "Release update over a 7-day period using phased release" ושומרים. צריך תפקיד Account Holder, Admin או App Manager. האפשרות זמינה עד הסטטוס Pending Developer Release: אפשר להפעיל אותה גם אחרי האישור של Apple, כל עוד הגרסה מחכה לשחרור הידני שלכם.
אחרי שהגרסה מאושרת, הסטטוס Ready for Distribution שלה מציג את הכיתוב "Phased Release". בסוף 7 הימים, ה-Admin וה-App Manager של האפליקציה מקבלים התראה.
עצירה, המשך ושחרור לכולם
- עצירה: עד 30 יום בסך הכול, בכמה פעמים שרוצים. עצירה של 10 ימים משאירה 20 יום לבאות.
- המשך: השחרור ממשיך מהיום שבו עצרתם.
- שחרור לכולם: הכפתור Release to All Users, בפינה הימנית העליונה של הגרסה, שולח את העדכון לכל המכשירים עם עדכון אוטומטי.
- הסרה ממכירה: עוצרת את השחרור סופית, כולל אם החברות שלכם בתוכנית המפתחים פגה. אם האפליקציה חוזרת למכירה, הגרסה זמינה לכולם בבת אחת.
אחרי שחרור לכולם, אי אפשר לשנות יותר כלום, כך לפי טבלת המאפיינים שניתנים לעריכה.
Nolera 1.0.2 יצאה בלי שחרור הדרגתי. ככה הייתי משתמש בו במהלך השבוע:
| מה רואים | מה עושים | מה קורה |
|---|---|---|
| קריסות או ביקורות מדאיגות | עצירה | העדכונים האוטומטיים נעצרים |
| התיקון מוכן | גרסה חדשה | היא עוברת שוב בדיקה, עם שחרור משלה |
| שום דבר חריג אחרי 3 או 4 ימים | Release to All Users | כולם מקבלים אותה |
| מחכים לתשובה מ-Apple | עצירה, 30 יום בסך הכול | המשך מהיום שבו עצרתם |
בזמן עצירה, הורדות ידניות ממשיכות. סמנו שחרור הדרגתי לכל גרסה שנוגעת בתשלום או בהפעלה הראשונה: שם באג עולה הכי ביוקר, ואי אפשר לחזור אחורה.
כשהתיקון דחוף: בדיקה מזורזת
Apple מאפשרת לבקש בדיקה מזורזת. היא שמורה למקרים דחופים באמת: באג קריטי שצריך לתקן, או שחרור שקשור לאירוע.
- קודם שולחים את הגרסה. מתארים את הבאג בשדה Notes שמיועד ל-reviewer.
- ממלאים את הטופס לבקשת בדיקה מזורזת, ובוחרים את האפליקציה והפלטפורמה.
- Apple מזרזת את הבדיקה לפי הזמינות שלה. אין שום הבטחה.
לאירוע, ציינו בהערות את התאריך שלו ואת הקשר שלכם אליו. זמני ההמתנה הרגילים מופיעים ב-זמן האישור ב-App Store.
מה עובר שוב בדיקה ומה לא
| שינוי | מה צריך |
|---|---|
| קוד נייטיב, הרשאות, גרסת SDK | build חדש, גרסה חדשה, בדיקה מלאה |
| צילומי מסך, תיאור, מילות מפתח, חידושים | גרסה חדשה, שנבדקים יחד איתה |
| טקסט קידום מכירות | כלום: משתנה בלי שליחה חדשה |
| עצירה, המשך, שחרור לכולם | כלום: אלה הגדרות שחרור |
| כותרת דף אפליקציה ב-iOS 27 | לבד ב-Asset Library, או עם גרסה |
| תיקון JavaScript, עם Expo | אפשר עדכון מרחוק |
טקסט קידום המכירות משתנה בלי שליחה חדשה, לפי דף פרטי הגרסה. עם Expo, עדכון מרחוק משנה JavaScript, טקסטים ותמונות בלי לעבור דרך ה-App Store. התיעוד של Expo קובע שתי מגבלות: קוד נייטיב, הרשאות וגרסת SDK דורשים בינארי חדש, והעדכונים חייבים לעמוד בכללי ה-App Store.
המקרה שלי: תיקון מרחוק שה-reviewer לא ראה אף פעם
בספטמבר 2026, build של Nolera חיכה לבדיקה. תיקנתי באג במסך הסריקה ופרסמתי את התיקון כעדכון מרחוק בזמן ההמתנה. ה-build נדחה בכל זאת, בגלל אותו באג שכבר תוקן.
ההסבר נמצא ב-תיעוד של expo-updates: כברירת מחדל, האפליקציה מורידה את העדכון בהפעלה ומחילה אותו בהפעלה הבאה. ה-reviewer מתקין את האפליקציה, מפעיל אותה פעם אחת ובודק את הקוד שמוטמע ב-build. אותו כלל חל על משתמשים חדשים: הסשן הראשון שלהם רץ על הקוד של ה-build.
מאז, כל שינוי במסך הבית, ב-paywall או בפיצ'ר המרכזי יוצא ב-build חדש. העדכון מרחוק משמש רק את מי שכבר יש לו את האפליקציה.
לאפס את הדירוג עם גרסה
כל גרסה חדשה מציעה את האפשרות Reset rating when this version is released. לפי העזרה של Apple על איפוס, היא חלה על כל המדינות, שומרת את הביקורות הכתובות ואי אפשר לבטל אותה אחרי השחרור. Apple ממליצה להשתמש בה במשורה, כי דף עם מעט דירוגים יכול להרתיע.
צ'קליסט לפני שליחת העדכון
- מספר הגרסה גבוה יותר, ה-build הוגדל.
- ה-build נבדק ב-TestFlight, על אייפון קטן ועל iPad אם האפליקציה רצה עליו.
- החידושים כתובים בכל שפה, והשינויים המשמעותיים מופיעים ברשימה.
- צילומי המסך מראים את הממשק הנוכחי אם הוא השתנה.
- ההערות ל-reviewer מסבירות מה השתנה ואיפה למצוא את זה.
- אפשרות השחרור נבחרה: ידני אם צריך לעמוד בתאריך.
- שחרור הדרגתי מסומן אם הגרסה נוגעת בתשלום או בהפעלה הראשונה.
- אתם יודעים אם תיקון עתידי יכול לצאת מרחוק, או שיצטרך build.
לעבור את הבדיקה בכל עדכון
כל עדכון עובר שוב את App Review, ודחייה תוקעת את התיקון שלכם. ה-Review Kit מרכז את הצ'קליסט שלי לפני שליחה, את הדחיות שתיקנתי ושני skills של Claude Code שעוברים על הפרויקט ועל דף האפליקציה, ואז מכינים את התשובה שלכם אם Apple דוחה. המסלול המלא נמצא בדף פרסום אפליקציה ב-App Store.
אם אתם מכינים את השחרור הראשון, עשו את האבחון החינמי: הוא מסדר את השלבים לפי הסדר ושולח לכם את הצ'קליסט שלי נגד דחיות של Apple.
שאלות נפוצות
כמה זמן נמשך שחרור הדרגתי ב-App Store?
שבעה ימים: 1% מהמשתמשים עם עדכון אוטומטי ביום הראשון, אחר כך 2, 5, 10, 20 ו-50%, ו-100% ביום השביעי. אפשר לעצור אותו עד 30 יום בסך הכול, או לסיים אותו בכל רגע עם Release to All Users.
האם עדכון לאפליקציית iOS עובר שוב בדיקה של Apple?
כן. כל גרסה חדשה, עם ה-build והמטא-דאטה שלה, עוברת App Review. את טקסט קידום המכירות ואת הגדרות השחרור, לעומת זאת, משנים בלי שליחה חדשה.
אפשר לחזור לגרסה הקודמת של אפליקציה ב-App Store?
לא. צריך ליצור גרסה חדשה עם התיקון ולשלוח אותה לבדיקה. בגלל זה השחרור ההדרגתי והאפשרות לעצור אותו שימושיים.
האם משתמשים חדשים מקבלים את העדכון במהלך שחרור הדרגתי?
כן, אם הם מורידים את האפליקציה מה-App Store. השחרור ההדרגתי שולט רק בעדכונים אוטומטיים: כל אחד יכול להוריד את הגרסה החדשה בכל רגע.
אפשר להפעיל שחרור הדרגתי אחרי האישור של Apple?
כן, כל עוד הגרסה בסטטוס Pending Developer Release, כלומר בשחרור ידני ועדיין לא פורסמה. אחרי שהגרסה יצאה, זה מאוחר מדי בשביל הגרסה הזו.
מה לכתוב בהערות הגרסה של עדכון?
את הפיצ'רים החדשים ואת השינויים המשמעותיים, ברשימה ברורה: זה סעיף 2.3.12. לתיקון פשוט של באגים, אבטחה או ביצועים, מספיק ניסוח כללי. השדה מקבל 4,000 תווים ואפשר לתרגם אותו לכל שפה.

