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

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

תמונה: יח"צ

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

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

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

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

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

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

cc by flickr, Morten Rand-Hendriksen

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

יש שיקולים רבים שיכולים לתרום להחלטה, כמו למשל:

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

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

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

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

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

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

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

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

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

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

שלב 3: המעצב נכנס לתמונה… בחירת הקונספט

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

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

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

• משתמש יוכל לבחור קבוצת כדורגל אותה הוא אוהד מתוך 5 ליגות שונות.
• משתמש יוכל לקרוא מאמרים של הקבוצה אותה הוא אוהד
• משתמש יוכל לקרוא מאמרים של הליגה של הקבוצה אותה הוא אוהד
• משתמש יוכל לשנות את הקבוצה אותה הוא אוהד

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

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

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

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

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

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

ניהול קבצים Github

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

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

UI-Automation

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

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

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

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 הסטנדטיות של האפליקציה לאורך כל תהליך הפיתוח (ולא רק בסופו), חשוב לי לציין כלי חשוב ביותר שמאפשר להפיץ אפליקציות אייפון לפני שהן עולות לאפסטור ועוד בדרך חוקית.

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

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

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

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

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

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