לפני שבונים אפליקציה: שישה חסמים שאינם בקוד

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

1. חשבונות החנויות אינם פרט אדמיניסטרטיבי

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

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

וההשלכה המעשית חשובה מהתנאי עצמו. כשהחשבון על שמכם:

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

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

2. מכירה בתוך האפליקציה דורשת ח.פ וחשבון סליקה — והבנייה לא מחכה להם

זה החסם שהכי הרבה פעמים ראינו מפתיע בעלי עסקים.

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

מה שקורה בפועל: החנות נבנית במלואה, נבדקת, עובדת — ואינה יכולה לגבות שקל אחד. האפליקציה מוכנה ומושבתת בו-זמנית.

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

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

3. אפל לוקחת שלושים אחוז על מה שדיגיטלי

פרט קטן שהופך את כל מודל הרווח.

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

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

4. הקטלוג הוא הפרויקט, לא המסכים

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

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

השאלות שנסגרות מוקדם:

• האם התוכן באמת מוכן — תמונות, תיאורים ומחירים — או שהוא עדיין נאסף?
• מי בתוך העסק אחראי על העדכון, ובאיזה חלק מהשבוע שלו?
• האם יש מערכת קיימת (קופה, מלאי) שאפשר למשוך ממנה, או שהכול יוזן ידנית?

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

5. בדיקת החנויות אינה לוח הזמנים שלכם

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

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

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

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

6. אפליקציה שלא מתעדכנת יורדת מהחנות

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

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

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

מה נסגר לפני שורת קוד אחת

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

סיכום

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

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