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

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

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

לא אפל ולא גוגל מחפשות תירוץ לדחות אפליקציה לגיטימית — הבודקים בודקים שהאפליקציה עובדת כפי שהיא מתוארת ולא מטעה משתמשים. בפועל, אותן בעיות חוזרות שוב ושוב:

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

מה כדאי להכין לפני שמגישים אפליקציה?

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

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

איך בפועל עובד לוח הזמנים של בדיקת החנויות?

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

מה עושים אם האפליקציה נדחתה?

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

מה ההבדל בין בדיקת אפל לבדיקת Google Play?

בדיקת App Store מתבצעת על ידי אדם שבפועל פותח ומשתמש באפליקציה, וזו הסיבה שתהליכים שבורים וצילומי מסך לא תואמים מתגלים באופן עקבי — וגם הסיבה שהבדיקה בדרך כלל מחמירה יותר בנוגע לעיצוב וכללי פונקציונליות. Google Play מסתמך יותר על בדיקות אוטומטיות לצד בדיקת מדיניות, כשבדיקה אנושית שמורה בעיקר לאפליקציות שסומנו או לקטגוריות מסוימות; לרוב הוא מהיר יותר עבור אפליקציות פשוטות אבל מחמיר יותר בתחומי מדיניות מסוימים, כמו הרשאות וגילוי בטיחות נתונים. הכנה לפי הרף המחמיר מבין השניים — התייחסות לכל צילום מסך, הרשאה ותהליך כאילו מישהו יבדוק אותם ידנית — מכסה את שניהם.