זמן אישור אפליקציה ב-App Store: כמה זמן מחכים
מאת Mehdi Azizi
עודכן ב-, 9 דק׳
Apple בודקת 50% מההגשות תוך 24 שעות ו-90% תוך 48 שעות. מה שבאמת מאריך את ההמתנה זה הדחיות, וככה עונים עליהן ב-Resolution Center.
על הנייר, זמן האישור ב-App Store קצר: Apple מודיעה שהיא בודקת לפחות 50% מההגשות תוך פחות מ-24 שעות, ו-90% תוך פחות מ-48 שעות. הנתון הזה מגיע מהדף הרשמי של App Review. אז אם האפליקציה שלך עוברת בניסיון הראשון, אפשר לצפות לתשובה תוך יום בערך.
הזמן האמיתי נמדד אחרת: זה הזמן מההגשה הראשונה שלך ועד שהאפליקציה זמינה למכירה. ומה שמפוצץ אותו זה כמעט אף פעם לא ההמתנה בתור, אלא הדחיות. כל דחייה מתחילה מחזור שלם מחדש: לקרוא את הסיבה, לתקן, לשלוח שוב, לחכות שוב, כולל דחייה אוטומטית בזמן ההעלאה כמו ITMS-90338. המדריך הזה מסביר מה מאריך את הזמן, איך לטפל בדחייה בלי לאבד ימים, ואילו סיבות דחייה הכי נפוצות באפליקציה ראשונה.
אני מדבר מתוך ההגשות שלי. אפליקציות ה-iOS שלי, ביניהן Solys (שעון מעורר עם מיני-משחקים) ו-TradaZen (סימולטור מסחר), נמצאות ב-App Store, וחטפתי לא מעט דחיות בדרך, גם ב-Solys וגם בשתי אפליקציות אחרות, Clic ו-Nolera. הסיבות מפורטות בהמשך.
זמן אישור ב-App Store: מה Apple באמת מבטיחה
אחרי שהעלית את ה-build, בלי שגיאה אוטומטית כמו ITMS-90725, ודף האפליקציה שלך מלא, אתה שולח אותו לבדיקה מתוך App Store Connect. ההגשה עוברת אז כמה סטטוסים: ממתינה (Waiting for Review), בבדיקה (In Review), ואז מאושרת או נדחית. Apple שולחת לך מייל בכל שינוי, ואפשר לעקוב אחרי המצב ב-App Store Connect או באפליקציית האייפון שלו.
שלוש הבהרות רשמיות ששימושיות לתכנון:
- המספרים האלה הם מגמות, לא התחייבות: עד הגשה אחת מתוך עשר מחכה יותר מ-48 שעות.
- ההגשות לא בהכרח נבדקות לפי סדר השליחה, כך לפי העזרה של App Store Connect.
- רק גרסה אחת של האפליקציה יכולה להיות בבדיקה בכל פלטפורמה. אי אפשר לערום כמה גרסאות כדי "לחסוך זמן".
אחרי שהאפליקציה אושרה, אפשר לבחור לפרסם אותה אוטומטית או לשחרר אותה בעצמך. האפשרות השנייה שווה זהב: קודם מאשרים את האפליקציה, ואז קובעים תאריך השקה כשיש אור ירוק.
מה מאריך את ההמתנה
הזמן מתארך רק לעתים רחוקות בגלל Apple. כמעט תמיד הוא מתארך בגלל מה ששולחים לה.
ההגשה הראשונה
בגרסה הראשונה בכלל, Apple בודקת הכול בבת אחת: דף האפליקציה, צילומי המסך, סיווג הגיל, מדיניות הפרטיות, הצהרות איסוף הנתונים, המינויים והאפליקציה עצמה. כל רכיב הוא הזדמנות לדחייה. התור לא ארוך יותר, השטח פשוט גדול יותר. אם עוד לא פרסמת אף פעם, השלבים שצריך להכין מפורטים בפרסום אפליקציה ב-App Store.
מינויים ורכישות בתוך האפליקציה
אם האפליקציה שלך מוכרת מינוי, שני כללים משנים לך את לוח הזמנים:
- המינוי הראשון שלך חייב להיות מוגש יחד עם גרסה חדשה של האפליקציה. זה כתוב במפורש בעזרה על רכישות בתוך האפליקציה. אם האפליקציה יוצאת בלעדיו, תצטרך גרסה חדשה כדי לאשר אותו.
- כל הרכיבים בהגשה חייבים להיות מאושרים כדי שההגשה תאושר. מינוי שנדחה חוסם את הכול.
כלל 2.1(b) דורש גם שהרכישות בתוך האפליקציה יהיו שלמות, גלויות לבודק ועובדות. אם אחת מהן לא מופיעה באפליקציה, תסביר למה בהערות לבדיקה. ההקמה המלאה של מינוי מפורטת במינויים בתוך אפליקציית iOS.
חשבון הדגמה חסר
אם האפליקציה שלך דורשת התחברות, ה-App Review Guidelines דורשות חשבון הדגמה פעיל או מצב הדגמה מלא, ושירותי שרת שפועלים במהלך הבדיקה. בלי פרטי התחברות בסעיף App Review Information של הגרסה, הבודק נתקע במסך ההתחברות, וזו דחייה. וגם אל תכבה את שרת הבדיקות שלך באמצע הבדיקה.
הדחיות עצמן
זה הגורם מספר אחת, בפער. Apple מציינת שיותר מ-40% מהבעיות הלא פתורות קשורות לכלל 2.1, זה שמכסה קריסות, תוכן זמני ומידע חסר. כל דחייה שנמנעה היא לפחות מחזור אחד שחסכת.
לענות ב-Resolution Center
כשהגשה נדחית, הסטטוס שלה עובר ל-Unresolved Issues. ההודעה של Apple מציינת את הכלל שהופר, הרבה פעמים עם צילום מסך של הבעיה. הכול קורה בסעיף App Review של האפליקציה שלך ב-App Store Connect, שעדיין קוראים לו הרבה פעמים Resolution Center.
התהליך הרשמי כדי לענות ל-App Review:
- באפליקציה שלך, לחץ על הקישור של הבעיות הלא פתורות בראש העמוד.
- לחץ על Resolve ליד ההגשה.
- לחץ על Reply to App Review, כתוב את התשובה שלך (עד 4,000 תווים) וצרף צילום מסך או מסמך אם צריך.
מה שהופך תשובה ליעילה:
- תציין את התיקון, לא את התחושות שלך. "בקשת הדירוג מופיעה עכשיו אחרי שמנצחים בהדגמה, צילום מצורף" עדיף על נאום הגנה ארוך.
- צרף הוכחה. צילום מסך או סרטון קצר של המסך המתוקן חוסכים סבב שאלות.
- אם הדחייה נוגעת רק למטא-דאטה (טקסט הדף, צילומי מסך, קישורים, כמו דחייה לפי 2.3.10), Apple מבהירה שאפשר לשלוח שוב את אותו build אחרי התיקון. אין צורך לקמפל מחדש.
לערער, רק אם אתה בטוח
אפשר לערער על דחייה מול ה-App Review Board. Apple מבקשת להסביר בדיוק למה האפליקציה עומדת בכללים, להגיש רק ערעור אחד לכל הגשה שנדחתה, ולענות קודם על בקשות מידע פתוחות. ערעור על דחייה מוצדקת רק מאריך את ההמתנה.
להגיש תיקון מהר
כשהסיבה ברורה, המהירות באה ממשמעת:
- תתקן את הסיבה, ורק אותה. להכניס שלושה פיצ'רים חדשים ל-build המתוקן זה לפתוח מחדש את שטח הבדיקה.
- תבדוק את התיקון בתנאים של הבודק. בבעיית תצוגה, זה אומר האייפון הכי קטן שנתמך והכי גדול, לא רק שלך.
- זהירות עם רכיבים שהוסרו. בהגשה עם בעיות לא פתורות, העזרה של Apple מבהירה שרכיב שהוסר לא יכול לחזור לאותה הגשה, ושכל רכיב אפשר לשנות רק פעם אחת לפני שליחה חוזרת. תחשוב לפני שאתה מוחק מינוי שנדחה.
- שלח שוב, ואז ענה. משפט או שניים עובדתיים בתשובה שלך כדי להגיד מה השתנה.
ומה עם בדיקה מזורזת? היא קיימת, אבל Apple שומרת אותה לשני מקרים: תיקון באג קריטי בגרסה שכבר פורסמה, עם השלבים לשחזר אותו, ואפליקציות שקשורות לאירוע עם תאריך. זה לא קיצור דרך לפרסום ראשון שמתעכב.
הדחיות הכי נפוצות אצל מתחילים
כבר סיפרתי בפירוט על שתי הדחיות שלי ב-Solys בלמה Apple דוחה אפליקציה. הנה הסיבות שבאמת חטפתי, עם מספר הכלל, כי אלה בדיוק הסיבות שמחכות לאפליקציה ראשונה.
2.1, האפליקציה לא עובדת (Solys). אי אפשר היה לנצח בהדגמת הפתיחה של Solys על מסך אייפון קטן: שלב חובה שאי אפשר לעבור, ולכן האפליקציה נחשבה לא שלמה. תוקן מאז.
5.6.3, בקשת דירוג מוקדמת מדי (Solys). הדירוג ב-App Store התבקש בתחילת ה-onboarding, לפני שהמשתמש חווה משהו באפליקציה. הוא צריך לבוא אחרי רגע אמיתי של ערך.
5.1.1, מדיניות פרטיות לא מעודכנת (Clic). כלל 5.1.1 דורש קישור למדיניות הפרטיות ב-App Store Connect ובתוך האפליקציה, והמדיניות הזאת חייבת לתאר במדויק אילו נתונים נאספים, איך משתמשים בהם ואיך מוחקים אותם. ב-Clic הגרסה שבאוויר לא הייתה מעודכנת. מדיניות שלא עוקבת אחרי המוצר שלך מספיקה כדי שההגשה תידחה.
5.1.1, כפתור "Allow" לפני בקשת המערכת (Nolera). Nolera הציגה מסך הסבר לפני בקשת הגישה למצלמה, עם כפתור בשם "Allow". ה-Human Interface Guidelines על פרטיות ברורות: מסך לפני התראת המערכת מותר, אבל הכפתור בו לא צריך להשתמש ב-"Allow" או במילה דומה, כי בשלב הזה לא מאשרים כלום. Apple ממליצה על "Continue" או "Next".
2.3.2, האייקון שומש כתמונת קידום של המינוי (Nolera). כלל 2.3.2 מסדיר את הקידום של רכישות בתוך האפליקציה ב-App Store: השם, התמונה והתיאור חייבים להתאים. ב-Nolera תמונת הקידום של המינוי הייתה פשוט האייקון של האפליקציה. צריך תמונה ייעודית לרכישה.
מה שמחבר את חמש הדחיות האלה: אף אחת מהן לא הייתה בעיית קוד מסובכת. את כולן אפשר היה לראות בקריאה של התיק בעיניים של בודק. אם האפליקציה שלך נדחתה הרגע והסיבה עדיין לא ברורה, התהליך המלא נמצא באפליקציה שנדחתה על ידי Apple.
לתכנן את הזמן בלו"ז שלך
כמה כללים פשוטים כדי שהבדיקה לא תדחה לך את ההשקה:
- אל תכריז על תאריך לפני האישור. תאשר את האפליקציה, תבחר פרסום ידני, ואז תקבע תאריך.
- תשאיר מרווח של לפחות מחזור דחייה אחד אם זו ההגשה הראשונה שלך או המינוי הראשון שלך.
- תפתח חשבון מפתח מוקדם אם אתה עובד דרך חברה: מספר D-U-N-S לבדו יכול לקחת יותר משבוע. הכול מוסבר במדריך לחשבון מפתח ב-Apple.
- תקרא את התיק שלך כמו בודק: חשבון הדגמה, מדיניות פרטיות מעודכנת, privacy manifest מלא, מסכי הרשאות, תמונות מינוי, וכל מסך חובה באייפון קטן וגדול.
אם אתה רוצה שמישהו יעבור על התיק שלך לפני השליחה
ה-Apple Review Kit מרכז את הצ'קליסט שלי לפני שליחה, את הדחיות שלי מ-Apple עם התיקונים, ו-skills של Claude Code שעוברים על הפרויקט, ה-paywall ודף האפליקציה שלך. הוא לא מבטיח אישור, Apple היא שמחליטה, אבל הוא עוזר לך לתפוס את הסיבות שפירטתי למעלה לפני שהן עולות לך מחזור.
מכין את ההגשה הראשונה שלך? האבחון החינמי שולח לך את הצ'קליסט שלי נגד דחיות של Apple ואומר לך מה נשאר לעשות. אם האפליקציה שלך כבר תקועה, תזמין איתי שעה: נקרא יחד את ההודעה של Apple, בשיחת וידאו. ואם אתה עוד בונה אותה, בעמוד הבית תראה איך ליצור את האפליקציה שלך כשחושבים על הבדיקה מההתחלה.
שאלות נפוצות
כמה זמן לוקח לאשר אפליקציה ב-App Store?
Apple מודיעה שהיא בודקת לפחות 50% מההגשות תוך פחות מ-24 שעות, ו-90% תוך פחות מ-48 שעות. זו לא התחייבות: חלק לוקחות יותר זמן, והן לא בהכרח נבדקות לפי סדר השליחה. הזמן האמיתי הוא מההגשה הראשונה ועד שהאפליקציה זמינה למכירה, והוא מתארך בעיקר בגלל דחיות.
מה מאריך את זמן האישור של אפליקציה?
הדחיות, בפער: כל אחת מתחילה מחזור שלם מחדש (לקרוא את הסיבה, לתקן, לשלוח שוב, לחכות שוב). Apple מציינת שיותר מ-40% מהבעיות הלא פתורות קשורות לכלל 2.1, זה של קריסות, תוכן זמני ומידע חסר. גם הגשה ראשונה מכפילה את ההזדמנויות לדחייה, כי Apple בודקת הכול בבת אחת.
איך עונים על דחייה ב-App Store?
בסעיף App Review של האפליקציה שלך, פתח את הבעיות הלא פתורות, לחץ על Resolve ואז על Reply to App Review. כתוב את התשובה שלך (עד 4,000 תווים), ציין את התיקון ולא את התחושות שלך וצרף צילום מסך או סרטון קצר. אם הדחייה נוגעת רק למטא-דאטה, אפשר לשלוח שוב את אותו build אחרי התיקון. אם הסיבה עדיין לא ברורה, קרא את אפליקציה שנדחתה על ידי Apple.
אפשר לבקש מ-Apple אישור מזורז?
כן, בדיקה מזורזת קיימת, אבל Apple שומרת אותה לשני מקרים: תיקון באג קריטי בגרסה שכבר פורסמה, עם השלבים לשחזר אותו, ואפליקציות שקשורות לאירוע עם תאריך. זה לא קיצור דרך לפרסום ראשון שמתעכב.
האם המינוי הראשון חייב להיות מוגש יחד עם האפליקציה?
כן, לפי העזרה של Apple: המינוי הראשון שלך חייב להיות מוגש יחד עם גרסה חדשה של האפליקציה. אם האפליקציה יוצאת בלעדיו, תצטרך גרסה חדשה כדי לאשר אותו. כדי שההגשה תאושר, כל הרכיבים שלה חייבים להיות מאושרים: מינוי שנדחה חוסם את הכול.
מתי להכריז על תאריך ההשקה של האפליקציה?
לא לפני ש-Apple אישרה את האפליקציה. תבחר פרסום ידני: קודם מאשרים את האפליקציה, ואז קובעים תאריך השקה כשיש אור ירוק. אם זו ההגשה הראשונה שלך או המינוי הראשון שלך, תשאיר גם מרווח של לפחות מחזור דחייה אחד.