מדוע פרסום ב-Huawei AppGallery נכשל במודרציה
פרסום ב-Huawei AppGallery נכשל לא בגלל הקוד, אלא בגלל פורמליות: האפליקציה נבנתה, נבדקה ועובדת, אבל המודרציה מחזירה אותה עם ניסוח יבש שעדיין צריך לפענח. לרוב הסיבה היא אי-התאמה לדרישות חנות האפליקציות: ההרשאות המוצהרות אינן תואמות להתנהגות בפועל.
הסיבה השנייה בשכיחותה היא חתימת האפליקציה. גרסת release שחתומה במפתח דיבאג או במפתח ממאגר אחר אינה מתקבלת על ידי החנות. מלכודת נפרדת היא החלפת מפתח בין גרסאות: העדכון מפסיק להתקין מעל הגרסה הקודמת, וחלק מהמשתמשים נשארים בגרסה הישנה.
הבלוק השלישי הוא כרטיס האפליקציה: תיאור, צילומי מסך, אייקון, דירוג גילאים, קישור למדיניות פרטיות. היעדר מדיניות הוא כמעט ערובה לדחייה במודרציה, גם אם האפליקציה אוספת מינימום נתונים. כרטיס חסר לא חוסם את הפרסום, אבל מוריד את המיקום בחיפוש הפנימי של החנות.
המחיר של כל כישלון נמדד לא בשעות פיתוח, אלא בחלון השקה שהוחמץ. סבב בדיקה נמשך ימים, תיקונים דורשים build חדש וסבב המתנה חדש, השחרור נדחה, וערוץ הרכישה שכבר התחיל להתחמם מתקרר.
נסביר מה בדיוק בודקת המודרציה ואיך להכין את ה-build כך לעבור אותה בפעם הראשונה.
במה נבדלות דרישות חנויות האפליקציות זו מזו
כל חנות בודקת סט כללים משלה, ו-build שעבר מודרציה באחת לא מבטיח התקבלות באחרת. ההבדלים בין חנויות האפליקציות נוגעים לחתימה, לגרסת מערכת היעד, להרכב כרטיס האפליקציה ולמדיניות הטיפול בנתונים — החזרות לתיקון מגיעות בדיוק בנקודות האלה.
חתימה ותעודות
החנויות מתייחסות למפתחות באופן שונה: חלקן מקבלות build שחתום רק במאגר שלכם, אחרות דורשות חתימה נוספת של החנות ותעודה נפרדת. סעיף נפרד הוא תוקף המפתח: כשהתוקף פג, העדכונים מפסיקים להתקבל, גם אם הקוד מוכן.
לכן אנחנו מפיקים מפתחות עם מרווח תוקף, שומרים אותם מחוץ ל-repository, ובודקים את חתימת ה-release לפני ההעלאה.
הרכב כרטיס האפליקציה ולוקליזציה
כרטיס האפליקציה הוא המקור השני להחזרות: סט צילומי מסך לגדלי מסך שונים, טקסטי תיאור, דירוג גילאים, קישור למדיניות הפרטיות של האפליקציה וגילוי הרכב הנתונים הנאספים. לוקליזציה של התיאורים בחלק מהחנויות היא חובה עבור אזורי היעד, אחרת הכרטיס לא מוצג בריכוזים.
| דרישה | הבדל בין החנויות | מהי הסכנה באי-התאמה |
|---|---|---|
| חתימה ותעודות | סכימת חתימה משל עצמה ותעודה נפרדת של החנות | דחייה בשלב ההעלאה |
| גרסת מערכת יעד | מינימום משלה לגרסת המערכת ולסט ההרשאות | העדכון לא עובר בדיקה |
| מדיניות פרטיות | קישור ציבורי חובה, הרכב הנתונים נדרש בגילוי מחמיר יותר | חסימת הכרטיס עד לתיקון |
| כרטיס ולוקליזציה | סט גדלים ודרישות תרגום שונים | החזרת המטא-נתונים לתיקון |
| בדיקת ה-build על ידי החנות | בדיקה ידנית ואוטומטית נמשכות זמנים שונים | דחיית תאריך השחרור |
כללי פרסום האפליקציה של החנויות משתנים באופן שוטף, לכן לפני כל שחרור אנחנו משווים מול התיעוד העדכני של Huawei AppGallery ושל שאר החנויות, ולא מול רשימות ביקורת משנה שעברה.
תהליך פרסום האפליקציה: מה-build ועד לאישור
מסלול השחרור ב-AppGallery בנוי סביב רעיון אחד: עד לרגע העלאת ה-build לחנות, כרטיס האפליקציה, החתימה ונתוני חשבון המפתחים כבר מתואמים זה עם זה. אז מעבר הבדיקה הוא קריאת הערות, ולא בנייה מחדש מאפס. הסדר שבו אנחנו מובילים את הפרסום:
- ביקורת ה-build הנוכחי: התחברות, תשלום והתראות לא צריכים להיות תלויים בשירותים שאין במכשירי Huawei — אותם סוגרים במימוש חלופי.
- הכנת החתימה: המפתח נוצר פעם אחת ומשמש מחדש בכל העדכונים, לכן הוא נשמר במאגר מאובטח ולא במחשב הנייד של המהנדס.
- מילוי כרטיס האפליקציה: שם, תיאור, צילומי מסך ברזולוציות הנדרשות, קטגוריה, דירוג גילאים, מדיניות פרטיות ומידע על איסוף נתונים.
- העלאת ה-build לחנות: פורמט, אזורי הפצה והפצה מדורגת באחוזים.
- בדיקות סגורות על רשימת חשבונות מוגבלת — לפני שהאפליקציה מופיעה בהפצה הפתוחה.
- מעבר הבדיקה והוצאת עדכון: תשובות להערות, פרסום לציבור הרחב, ומשם שחרורים לפי לוח זמנים.
בדיקות סגורות לפני שחרור
זו לא פורמליות, אלא דרך לתפוס את מה שלא רואים בסביבת הבדיקות: עדכון מעל הגרסה הקודמת, מכשירים בלי השירותים הרגילים, אלכסוני מסך שונים. אנחנו מפרידים בין התקנות "מאפס" לבין התקנות "מעל הגרסה הישנה" ומשווים דוחות — רגרסיות מתגלות לפני זרימת ההתקנות החדשות.
מה לעשות כשהבודק מעיר הערות
הערה כמעט תמיד מצביעה על אי-התאמה בין כרטיס האפליקציה להתנהגות האפליקציה, לכן אנחנו עונים לא בטקסט, אלא ב-build חדש או בהסבר מדויק עם הקלטת מסך. בכל סבב אנחנו מתעדים: גרסת ה-build, סיבת הדחייה, מה שינינו — כך הבדיקה לא מסתובבת במעגלים.
מצבי הפצה ולוחות זמנים לבדיקה בחנויות האפליקציות
פרסום ראשון ועדכון של אפליקציה שכבר מותקנת עוברים תורים שונים של בדיקה: גרסת ההתחלה עוברת בדיקה ידנית של המדיניות, והחנות עשויה לבחון אותה כמה ימי עבודה; עדכון מעל גרסה מותקנת — בדרך כלל מכמה שעות ועד יומיים. את תאריך השחרור אנחנו תמיד מחשבים לפי התרחיש הגרוע ביותר ומשאירים חלון לתיקון הערות המודרציה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| הפצה מלאה | הגרסה נבדקה, מוכנים למסור אותה לכולם בבת אחת | החזרה לאחור רק דרך build חדש, שגיאה מגיעה לכל הקהל |
| הפצה מדורגת | שינויים גדולים, יש סיכון לתקלות בחלק מהמכשירים | הפצה בחלקים עם השהיה בין שלבים |
| בדיקות סגורות | פונקציונליות חדשה לפני שחרור כללי | מעגל משתתפים מוגבל, ענף build נפרד |
| עדכון מעל גרסה מותקנת | שיפורים ותיקונים קטנים | המדיניות נבדקת מחדש, חלק מהמשתמשים דוחים את ההתקנה |
הפצה מדורגת והחזרה לאחור של גרסה
הפצה מדורגת פותחת את הגרסה החדשה בחלקים — למשל 5%, 20%, 50% ו-100% עם השהיה בין שלבים. אנחנו בודקים את שיעור ההפעלות המוצלחות והסיומים החריגים בשעות הראשונות: אם המדד יורד, ההפצה נעצרת, ושאר הקהל נשאר בגרסה הקודמת.
החזרה לאחור בחנויות אינה מיידית: אי אפשר להוריד את מספר הגרסה, לכן מראש מחזיקים build יציב של קודמו ומפיצים אותו כעדכון. נתוני המשתמשים נשמרים במקרה כזה, אם סכימת האחסון תואמת — את זה בודקים בבדיקות סגורות לפני תחילת ההפצה.
תוצרי השחרור: build-ים, מפתחות, הרשאות גישה ונהלים
אחרי השחרור נשאר אצל הלקוח סט שמספיק כדי להוציא עדכונים בכוחות עצמו או עם צוות אחר: build-ים, מפתחות, הרשאות בקונסולת המפתחים ונהלים. להלן מה בדיוק נכלל במסירה ואיך זה נשמר.
- build-ים חתומים — חבילות שפורסמו בפורמטים AAB ו-APK עם מספר גרסה, תאריך ו-checksum של הקובץ.
- מאגר מפתחות החתימה — המפתח עצמו, הסיסמאות אליו וטביעת האצבע של התעודה: בלעדיהם אי אפשר לעדכן בחנות, ואי אפשר לשחזר את המפתח.
- הרשאות גישה לקונסולת המפתחים — חשבון הבעלים אצל הלקוח, תפקידים נפרדים לפיתוח ולבדיקות, איש קשר להתכתבות עם הבודקים.
- הוראות הפצה — סדר הפעולות: build, חתימה, העלאה, מילוי כרטיס האפליקציה, שליחה לבדיקה, טיפול בהערות.
- נוהל עדכונים ותמיכה — תדירות השחרורים, האחראים, זמן התגובה לדחייה וכללי החזרה לאחור ל-build הקודם.
מסירת הרשאות גישה ותפקידים
בעל החשבון הוא הלקוח — על הישות המשפטית שלו וכתובות הקשר שלו. המהנדסים שלנו נשארים עם תפקיד מפתח ועם סט הרשאות מינימלי תחת אימות דו-שלבי, ובסיום העבודה הגישה נשללת בפעולה אחת, ולא באמצעות החלפת סיסמה.
נוהל הוצאת עדכונים
הנוהל מגדיר את תדירות ה-build-ים המתוכננים, את האחראים ואת זמן הטיפול בגרסה שנדחתה על ידי הבודקים. סעיף נפרד הוא התגובה לשינוי בדרישות החנות, כדי שעדכון כללי הפרסום לא יהפוך לבהלה, וכן סדר ההחזרה לאחור אם ה-build החדש פגע ביציבות.
מקרה בוחן: שחרור בלי דחיות וצמיחה בהתקנות מערוץ חדש
מה היה לפני הפנייה
הלקוח — שירות משלוחים — לא עבר בדיקה ב-Huawei AppGallery פעמיים: תחילה סט ההרשאות היה רחב ממה שדרשו פונקציות האפליקציה, ואחר כך הסנכרון ברקע הופעל בלי פעולת משתמש. כל סבב חייב build מחדש, נימוק חדש לבדיקה והמתנה. השחרור נמתח לשישה שבועות במקום השבועיים שתוכננו, והערוץ עצמו לא הביא אף התקנה.
מה שינינו ומה התקבל
עברנו על דרישות החנות שורה־שורה: השארנו רק את ההרשאות שבלעדיהן התרחיש לא עובד, קישרנו משימות רקע לפעולה מפורשת של המשתמש, והוספנו טיפול תקין בסירוב להענקת הרשאות.
את כרטיס האפליקציה, צילומי המסך והתיאור התאמנו לפורמטים של החנות, ואת ה-build הרצנו בבדיקות על מכשירי בדיקה לפני השליחה.
השליחה השלישית עברה בפעם הראשונה. זמן ההשקה — תשעה ימי עבודה מתחילת העבודה; בחודש הראשון הגיעו 23% מההתקנות מהערוץ החדש, ושיעור הכשלים בהפעלה ירד מ-4.1% ל-0.6%. הערוץ הפסיק להיות ניסוי ונכנס לתוכנית השחרורים הקבועה.
"בעבר הוצאה לחנות חדשה הייתה לוטו. עכשיו זו משימה מתוכננת, כמו עדכון בערוץ הראשי".
— מנהל המוצר של הלקוח
מה לעשות אם הפרסום ב-AppGallery נדחה על ידי המודרציה?
דחייה של המודרציה היא תמיד ניסוח קונקרטי: קוד סיבה וטקסט ההערה בקונסולת המפתחים של Huawei AppGallery.
אנחנו מפרקים אותו באופן מילולי: סיבות טכניות (חתימת ה-build, סט ההרשאות, התנהגות בעת בקשת גישות) מתקנים ב-manifest, וסיבות תוכן (תיאור, צילומי מסך, קטגוריה, דירוג גילאים) — בכרטיס האפליקציה. סוג הסיבה גם קובע את היקף התיקונים.
תיקון הערות מסתיים לא בשינוי הקוד, אלא בבדיקה לפי רשימה: משחזרים את התרחיש שהמודרציה ציינה, בהתקנה נקייה ובהתקנה מעל הגרסה הקודמת. הגשה חוזרת של ה-build נעשית עם מספר גרסה מוגבה — המודרציה משווה אותו לזה שנדחה ולא בוחנת שוב את אותו build.
אם ההערה שנויה במחלוקת, עובד ערעור על דחיית החנות: מצרפים וידאו של התרחיש, צילומי מסך וקישור לסעיף במדיניות שמתיר את ההתנהגות. התשובה מגיעה בתוך כמה ימי עבודה, ופנייה מנומקת מסירה את ההערה לעיתים קרובות יותר מהגשה חוזרת בלי הסברים.
קטגוריה נפרדת היא build שכבר הופץ. תיקונים לא צריכים לשבור תאימות: מיגרציות נתונים וחוזי החלפת נתונים עם השרת נבדקים בעדכון מהגרסה הקודמת, אחרת החנות תקבל את ה-build והמשתמשים יקבלו קריסה.
אם מפתחות החתימה אבדו, אי אפשר לעדכן אפליקציה קיימת — מפרסמים אפליקציה חדשה עם מזהה אחר, והקהל עם הביקורות לא עובר. לכן אנחנו מחזיקים מפתחות במאגר מאובטח עם גיבויים, ומנהלים יומן של ניסוחי ההערות ותשובות המודרציה — זה מקצר את הטיפול בדחייה לשעות.
שאלות טכניות נפוצות על פרסום ועדכונים
לפני ההתחלה לקוחות בדרך כלל שואלים את אותה קבוצת שאלות: כמה ממתינים לבדיקה, מה יקרה לביקורות בעת העברה, האם יהיה צורך לבנות גרסה נפרדת לכל חנות, ומי אחראי לעדכונים אחרי השחרור. להלן תשובות קצרות מניסיון שלנו בפרסום ב-Huawei AppGallery ובקטלוגים אחרים.
כמה נמשכת הבדיקה ומה הכי מעכב אותה?
בדיקה ראשונית נמשכת מכמה שעות עד שלושה ימי עבודה, עדכונים עוברים מהר יותר. בקשה מוחזרת בגלל אי-התאמה בין התיאור לפונקציונליות, היעדר מדיניות פרטיות, הרשאות מיותרות ופרטי התחברות לבדיקה שלא עובדים אצל הבודק. אנחנו עוברים על רשימת הביקורת הזו לפני השליחה — מספר ההחזרות קטן פי כמה.
אפשר להעביר אפליקציה מחנות אחרת יחד עם הביקורות?
מבחינה טכנית — כן, מעבירים את ה-build ואת המטא-נתונים, והאפליקציה ממשיכה לעבוד אצל המשתמשים הקיימים. ביקורות, דירוג והיסטוריית התקנות לא עוברים: הם קשורים לרשומה בקטלוג מסוים. הדירוג נבנה מחדש, לכן בשבועות הראשונים אחרי השחרור אנחנו עובדים במיוחד בקפידה עם משוב.
צריך לבנות גרסה נפרדת לכל חנות?
כן, וזו פרקטיקה רגילה. build נפרד נחתם במפתח משלו ומחבר שירותים של הקטלוג המסוים — התראות, מפות, תשלום, אנליטיקה. הליבה המשותפת היא אחת, לכן תמיכה בכמה build-ים לא הופכת לפיתוח של כמה אפליקציות.
מה לעשות אם מפתח החתימה אבד?
מפתח החתימה הוא ארטיפקט קריטי, והגיבוי שלו נשמר בנפרד מה-repository, עם גישה מוגבלת. אם המפתח אבד או נחשף, השחזור נעשה דרך התמיכה של הקטלוג עם אימות זכויות הכתיבה. בלי גיבוי אי אפשר לעדכן עותקים מותקנים — יהיה צורך לפרסם רשומה חדשה ולבנות מחדש את הקהל.
מי אחראי לעדכונים אחרי השחרור?
בעל הרשומה והזכויות על חשבון המפתחים הוא תמיד הלקוח, וזה מבטיח שליטה על המוצר. אנחנו מנהלים את החלק הטכני: עוקבים אחר דרישות הקטלוג, בונים מחדש לגרסאות מערכת חדשות, סוגרים פרצות בתלויות, מריצים בדיקות רגרסיה ומוציאים עדכון עם תיאור השינויים.
נדון בפרסום האפליקציה שלכם בחנות
הערכת משימת פרסום ב-AppGallery דורשת שיחה אחת, אם יש בידינו נתוני קלט. להלן רשימה של מה שמסיר כמעט את כל השאלות בשלב ההתחלה: תוכנית העבודה נבנית לפיה, ולוחות הזמנים לפרסום נמסרים כבר בלי הסתייגות "תלוי בחנות".
- build של השחרור: חבילה חתומה שמוכנה להעלאה, מספר גרסה, רשימת שינויים לתיאור העדכון.
- מפתח החתימה וסדר אחסונו — בלי גישה אליו, עדכונים ושחזור הפרסום הופכים למשימה נפרדת.
- גישה לחשבון המפתחים: תפקיד עם זכות פרסום, שירותים מחוברים, סטטוס בדיקת החשבון.
- כרטיס האפליקציה: אייקון, חומרים גרפיים לגדלי מסך שונים, לוקליזציות של שם ותיאור, מילות מפתח.
- מדיניות פרטיות ומסכי הסכמה — לרוב דווקא זה מחזיר את האפליקציה לתיקון.
- שירותים שעליהם תלוי הפעלת האפליקציה במכשירי החנות: התראות, מפות, תשלום, התחברות עם חשבון — מה כבר מחובר ובאיזה שלב.
- מגבלות לוחות זמנים: תאריך שבו האפליקציה צריכה להיות זמינה למשתמשים, עם מרווח לבדיקת המודרציה.
- הערות נוכחיות של החנות, אם הפרסום כבר נדחה: טקסט הדחייה וחומרים מקונסולת המפתחים.
עם הסט הזה אנחנו חוזרים עם הערכת משימה ותוכנית עבודה: מה אנחנו סוגרים מצדנו, מה נדרש מכם, כמה זמן נמשך כל שלב ומתי האפליקציה תופיע בחנות. תארו את המשימה — נדון בה בצורה עניינית.