יום שישי, 8 בפברואר 2013

פיתוח אפליקציית אייפון - התהליך המלא, משלב הרעיון ועד הכניסה לחנות של אפל

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

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

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

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

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

שלב 1: אייפון או אנדרויד?

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


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

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

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

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

שלב 2: החלטה על תוכן האפליקציה

לאחר שהחלטנו סוף סוף להתחיל לפתח לפלטפורמת האייפון הגענו לשלב הבא בתהליך והוא להחליט מה האפליקציה שלנו תדע לעשות? 

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

המוטיבציה של כל חברה או מפתח עצמאי צריכה להיות להיכנס לחנות של אפל או אנדרויד כמה שיותר מוקדם עם ה Minimum Viable Product שידוע כ MVP על מנת לקבל פידבק כמה שיותר מהר  ממשתמשים אמיתיים (אם אתם לא מכירים את המושג MVP או Lean-Startup - מומלץ בחום לראות את ההרצאה של אריק ריס, הוגה הרעיון).

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

שלב 3: המעצב נכנס לתמונה... בחירת Concept

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

לא ניתן היום לפתח אפליקציה ללא מעצב גרפי מקצועי. לפני עידן סטיב ג'ובס, כל נושא העיצוב בעולם הטכנולוגיה היה נחשב למשהו שהוא nice to have ולא Must. היום עיצוב הוא Must ואין סיכוי לאפליציות ללא עיצוב מקצועי לעשות משהו משמעותי בשוק.

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

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

בפגישות המשך המעצב הציג לנו 2-3 רעיונות שונים לאפליציה, אנחנו נתנו את הפידבק שלנו וביחד החלטנו על ה Concept של האפליקציה.

תמונות מתוך שלב העיצוב הראשוני של האפליקציה

שלב 4: הקמת התשתית הטכנולוגית של הפרוייקט

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

ניהול קבצים Github

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

UI-Automation

נושא מתקדם, מיועד למפתחי אייפון בלבד. בתוך חבילת הפיתוח של אפל, ביחד עם Xcode מגיע גם סט תוכנות שנקרא Utilities ובתוכן נמצא UIAutomation. זהו למעשה כלי לטסטים אוטומטיים לאייפון שמאוד דומה ל Selenium וניתן בעזרתו לעשות את הדבר הקרוב ביותר ל Functional Test. 

אחת המתודולגיות פיתוח הנפוצות ביותר כיום היא Test Driven Development - TDD, בשיטה זו כותבים Tests לפני כל פיתוח של תוכנה למוצר. הטסטים הללו אמורים לבדוק את ה Feature הבא במוצר והם מוכנים עוד לפני הפיתוח. בהתחלה הטסטים נכשלים כמובן כי שום דבר לא השתנה במוצר, אבל לאחר הפיתוח הטסטים צריכים לעבור ומכאן והלאה הם תמיד צריכים לעבור. אם הטסטים נכשלים סימן שאחד המתכנתים שבר משהו עובד במוצר.

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

Jenkins - Central Build Server

נושא מתקדם, בפיתוח תוכנה כאשר כמה מתכנתים עובדים יחד על אותו קוד, נהוג לעבוד עם Central Build Server כלומר שרת מרוחק שתפקידו לבנות את התוכנה לאחר שכל מתכנת בקבוצה מעדכן את הקוד במערכת (ולאחר הבניה מריץ את הטסטים שנכתבו בשלב הקודם). 

אני לא ארחיב כאן במילים, רק אספר בקצרה (למי שזה לא סינית בשבילו), שאפשר לעשות בעזרת Jenkins מערכת של CI שמחוברת ל Github ומריצה Build ולאחר מכן את UI-Automation Tests לאחר כל Git Push. מי שסקרן לדעת איך עושים את זה שישלח לי מייל בפרטי.
  

שלב 5: כתיבת קוד

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

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

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

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

עבודה עם ספריות חיצוניות

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

המתכנת של האפליקציה חייב לשאול את עצמו בכל יום מחדש: "האם הבעיה שאני מנסה לפתור עכשיו היא כזו שגם מפתחי אפליקציות אחרים צריכים להתמודד עימה?" - אם התשובה היא חיובית (וזה קורה יותר ממה שאתם חושבים) סביר מאוד להניח שמישהו כבר כתב את הקוד שמספק את הפיתרון לכך. דוגמאות לספריות כאלו: Pull to Refresh, Infinite Scrolling, Animations, Network Operations.

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

שלב 6: Analytics Tools

יש תוכנות רבות שתפקידן לעשות ניתור על פעולות המשתמשים, המפורסמת בהן היא Google Analytics שבין היתר גם בה אנחנו משתמשים, עם דגש על custom events שזו למעשה אופציה להגדיר בתוך הקוד אילו פעולות של המשתמש אני רוצה לנתר, למשל: משתמש לחץ על כפתור Facebook-Connect. 

מעבר לגוגל, אנחנו משתמשים גם ב Flurry שהיא ספק נוסף ל Analytics, אשר מתמחה ספציפית בתחום המובייל (להבדיל מגוגל שהבסיס שלה התחיל ב Web והמובייל הוא הרחבה). Flurry מאוד פופולארית בקרב מפתחי האפליקציות, ובצדק. יש לה ממשק נוח עם אפשרויות רבות וקל יחסית לעבוד איתה.

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

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

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

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

שלב 7: QA סופי

אני יעשה את זה קצר כאן, מעבר לבדיקות QA הסטנדטיות של האפליקציה לאורך כל תהליך הפיתוח (ולא רק בסופו), חשוב לי לציין כלי חשוב ביותר שמאפשר להפיץ אפליקציות אייפון לפני שהן עולות ל App-Store ועוד בדרך חוקית. 

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

שלב 8: העלאה לחנות של אפל

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

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



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