בדיקה מזורזת ב-App Store: איך לבקש אותה מ-Apple

בדיקה מזורזת קיימת, אבל Apple שומרת אותה לנסיבות חריגות, והיא מזכירה שתיים: תיקון באג קריטי בגרסה שכבר פורסמה, או השקת גרסה שמתוזמנת לאירוע שהאפליקציה שלך קשורה אליו ישירות. קודם מגישים את הגרסה, מסבירים את הדחיפות בהערות לבודק (Notes), ואז שולחים את טופס הבקשה. Apple בוחנת כל בקשה ומזרזת לפי הזמינות שלה: זו אף פעם לא התחייבות.

האפליקציות שלי, Solys, TradaZen ו-Nolera, בנויות עם Expo. כשבאג מגיע מקוד ה-JavaScript, התיקון יוצא כעדכון מרחוק, בלי לעבור דרך App Review. אז בדיקה מזורזת רלוונטית אצלי רק לבילד נייטיב, וזו גם השאלה הראשונה שכדאי לשאול את עצמך לפני שמבקשים אותה. המדריך הזה מבוסס על דף העזרה של Apple על בדיקה מזורזת, שנקרא מחדש ב-6 בנובמבר 2026.

מה Apple מזכירה, ומה לא יעבור

Apple מדברת על נסיבות חריגות ומבקשת לשמור את הבקשות למקרי חירום אמיתיים. דף ה-App Review שלה נותן שתי דוגמאות ומה צריך לספק לכל אחת. שלוש השורות שנדחות בטבלה הן הפרשנות שלי לדפים האלה, לא רשימה של Apple.

סיבה	אצל Apple	מה צריך לספק, או להבין
באג קריטי בגרסה שבאוויר	מוזכר כדוגמה	שלבי שחזור, הגרסה הנוכחית
השקה שקשורה לאירוע	מוזכר כדוגמה	האירוע, התאריך שלו, הקשר בינו לאפליקציה
פרסום ראשון שמתעכב	לא, לדעתי	שום דבר לא הופך אותו לדחוף בעיני Apple
תאריך שיווקי בלי אירוע	לא, לדעתי	קמפיין הוא לא אירוע שקשור לאפליקציה
המתנה ארוכה מהרגיל	לא, לדעתי	זמן המתנה רגיל הוא לא מקרה חירום

Apple לא מגדירה את המונח. בפועל, באג קריטי זה אפליקציה שקורסת, שחוסמת פונקציה מרכזית או שמונעת תשלום, אצל משתמשים אמיתיים, בגרסה שבאוויר. שגיאת הקלדה במסך היא לא באג קריטי. ואם האפליקציה שלך עדיין בבדיקה כשאירוע מתקרב, Apple מציינת שאפשר לבקש זירוז גם מהסיבה הזאת.

התהליך בשלושה שלבים

1. הגש את הגרסה ב-App Store Connect. אפשר לזרז רק הגשה שכבר נשלחה. אם יש פונקציות שדורשות התחברות, הזן חשבון דמו בחלק App Review Information.
2. מלא את השדה Notes בזמן ההגשה. לבאג קריטי, תאר את הבאג שתוקן ואיך לשחזר אותו בגרסה הנוכחית. לאירוע, תן את השם שלו, התאריך ומה מקשר את האפליקציה שלך אליו.
3. שלח את הטופס Request an Expedited App Review, שנגיש מדף העזרה של Apple אחרי התחברות לחשבון המפתח שלך. בוחרים שם את האפליקציה והפלטפורמה הרלוונטיות, ושולחים.

Apple בוחנת את הבקשה ועונה לך, ואז עוקבים אחרי ההגשה ב-App Store Connect. אם הבקשה מתקבלת, הגרסה עוברת ל-In Review מוקדם יותר ממה שהתור היה מאפשר. אם היא נדחית, הבדיקה ממשיכה כרגיל: לא הפסדת כלום.

הכפתור Reply to App Review ב-App Store Connect לא נועד לבקש בדיקה מזורזת. דף יצירת הקשר עם App Review שומר אותו להתכתבות על הגשה פעילה; לבקשת זירוז ולערעור יש טופס נפרד לכל אחד.

מה לכתוב: שתי תבניות

App Review קוראים אנגלית. הנה שני הטקסטים שאני שומר מוכנים, להתאמה בשדה Notes, ובטופס אם יש בו שדה חופשי. הם באורך חמש שורות כי בודק צריך להבין את הדחיפות בלי לפתוח את האפליקציה.

באג קריטי בגרסה שבאוויר:

Version 2.0.3, currently live, crashes at launch for users who enabled notifications on iOS 26.1. Steps to reproduce: install 2.0.3, allow notifications, force quit, relaunch. The app closes immediately. Version 2.0.4 fixes the crash (notification permission is now read after the first screen loads). No other change in this build.

השקה שקשורה לאירוע:

This version adds the official schedule and live results for the Nantes Trail Festival on June 5, 2027. Our app is the event's official companion app (see the link to the organizer's page in the App Review Information section). Attendees need the update before the start on June 5 at 8:00 AM CEST.

שני הטקסטים האלה הם דוגמאות, לא בקשות ששלחתי. שני כללים לטקסטים שלך. עובדות שאפשר לבדוק: גרסה, מערכת, שלבים, תאריך, קשר לאירוע. רק הדחיפות, שום דבר אחר: אם הבילד כולל גם פיצ'ר חדש, תגיד את זה במשפט אחד, אבל אל תנסה להצדיק אותו.

לפני שמבקשים, בדוק שאתה באמת צריך

Apple מבקשת לשמור את זה למקרי חירום אמיתיים. שלוש שאלות, ומלכודת אחת, לפני ששולחים את הטופס.

האם התיקון יכול לעבור בלי בדיקה? עם Expo, עדכון מרחוק מחליף את קוד ה-JavaScript באפליקציות שכבר מותקנות, בלי בילד חדש. זו הדרך שבה אני משתמש לתיקונים שלי. היא לא מכסה קוד נייטיב, הרשאות או תלויות נייטיב: בשבילם צריך בילד ובדיקה. והתוכן שלה חייב להישאר במסגרת מה ש-Apple אישרה, כמו שמזכירה הסקירה של EAS Update: עדכון מרחוק לא משנה את מטרת האפליקציה. המדריך על פריסה הדרגתית של עדכון iOS מפרט מה עובר דרך מה.

האם ההמתנה חריגה? Apple אומרת שבדרך כלל היא בודקת לפחות 50% מההגשות תוך פחות מ-24 שעות ו-90% תוך פחות מ-48 שעות. אם הגרסה שלך ממתינה לבדיקה כבר יום, אתה בתוך הנורמה של זמן האישור ב-App Store. דף המעקב אחרי הגשה מזכיר גם מה מאריך בדיקה: אפליקציה ראשונה בלי היסטוריה, מסמכים שצריך לבדוק, תחום מפוקח.

האם ההגשה מלאה? בדיקה מזורזת להגשה חלקית לא מזרזת כלום. Apple מזהירה שהגשה חלקית מעכבת את הבדיקה או נכשלת. חשבון דמו, הערות, מסמכים: הכל צריך להיות שם לפני הטופס.

ובעיקר, אל תמשוך את הגרסה כדי לשלוח אותה מחדש. גרסה שנמשכה יוצאת מהתור ומתחילה מאפס. אם Apple שואלת אותך משהו במהלך הבדיקה, תענה ב-App Store Connect במקום להגיש מחדש, כמו שמסביר המדריך על מענה ל-App Review ב-Resolution Center.

אם Apple דוחה את הזירוז

אתה שומר על המקום שלך בתור: דחיית זירוז לא משנה כלום בבדיקה הנוכחית. כדי לא לחזור על המצב הזה:

• תזמן את ההשקות שלך. לאירוע, Apple ממליצה לבחור פרסום מתוזמן ב-App Store Connect: הגרסה נבדקת מראש ויוצאת בתאריך שבחרת. את אפשרות הפרסום של גרסה מגדירים בדף הגרסה, בחלק App Store Version Release.
• הגש מוקדם. גרסה שמוכנה שבוע לפני האירוע משאירה זמן לבדיקה רגילה, ואפילו לדחייה שמתקנים.
• שמור ערוץ בלי בדיקה ל-JavaScript. עם Expo, זה מה שהופך באג קריטי לתיקון של כמה דקות.

תבניות ההערות שלי לבודק, הצ'קליסט שלי לפני שליחה והתשובות לדחיות הנפוצות ביותר מרוכזים ב-Review Kit. ואם אתה רוצה לדעת מה חסר בהגשה שלך לפני ששולחים אותה, האבחון החינמי יגיד לך וישלח לך את הצ'קליסט שלי נגד דחיות של Apple. כל שלבי הפרסום נמצאים בפרסום אפליקציה ב-App Store.

שאלות נפוצות

כמה זמן לוקחת בדיקה מזורזת ב-App Store?

Apple לא נותנת שום לוח זמנים. היא מציינת שהיא בוחנת כל בקשה ומזרזת את הבדיקה לפי הזמינות שלה והביקוש באותו רגע. בקשה שמתקבלת מעבירה את הגרסה ל-In Review לפני התור שלה, בלי הבטחה לשעה.

אפשר לבקש בדיקה מזורזת לאפליקציה ראשונה?

שום דבר לא אוסר את זה, אבל Apple שומרת את הזירוז למקרי חירום אמיתיים ומזכירה שתי דוגמאות: באג קריטי בגרסה שכבר באוויר, או השקה שקשורה לאירוע עם תאריך. פרסום ראשון שמאחר ביחס לתוכנית שלך לא נכנס, לדעתי, לאף אחת מהן.

כמה פעמים אפשר לבקש בדיקה מזורזת?

Apple לא מפרסמת מספר. היא מבקשת לשמור את הבקשות למקרי חירום אמיתיים. לדעתי, כל בקשה בלי סיבה אמיתית הופכת את הבאה לפחות אמינה: שמור אותה לבאג שפוגע במשתמשים שלך.

צריך למשוך את ההגשה לפני שמבקשים זירוז?

לא, ההפך. אפשר לזרז רק הגשה שכבר נשלחה, וגרסה שנמשכה מאבדת את המקום שלה בתור. הגש, מלא את ה-Notes, ואז שלח את הטופס.

איפה נמצא הטופס לבדיקה מזורזת?

באתר המפתחים של Apple, אחרי התחברות לחשבון שלך: דף העזרה על בדיקה מזורזת מוביל אליו דרך הקישור Request an Expedited App Review. בוחרים שם את האפליקציה והפלטפורמה הרלוונטיות.

בדיקה מזורזת מבטיחה שהאפליקציה תאושר?

לא. היא משנה רק את המיקום בתור. הגרסה חייבת לעמוד ב-App Review Guidelines כמו כל גרסה אחרת, ודחייה עדיין אפשרית.

אפשר לתקן באג בלי לעבור דרך App Review?

עם Expo או React Native, עדכון מרחוק מחליף את קוד ה-JavaScript בלי בילד חדש ובלי בדיקה. קוד נייטיב, הרשאות ותלויות נייטיב תמיד דורשים בילד שמוגש ל-Apple.