פיתוח למובייל: Native או Web? (חלק ב')

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

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

Native או Web: הדילמה

"פיתוח Native" הוא המקבילה של Desktop Application בעולם המובייל, קרי אפליקציה המותקנת על המכשיר, רצה כקובץ בינארי ומשתמשת בפקדים של מערכת ההפעלה (בהגדרה גסה).

יתרונות עיקריים של פיתוח Native הם:

• Best User Experience בפיתוח ב Native קל יותר להגיע לשימושיות גבוהה. הרבה יותר קל להשיג אנימציה חלקה ותגובה מהירה, ולעתים יש דברים שפשוט לא עובדים בווב. מכיוון ששימושיות גבוהה היא ערך חשוב באפליקציות מובייל - זהו יתרון חשוב.
  
  חברות המושקעות בפיתוח לווב, מנסות להוכיח ש HTML5 "יכול הכל". סיפור משעשע הוא הסיפור של FastBook בו הציגה חברת Sencha אפליקציית מובייל עדיפה על אפליקציית הנייטיב של פייסבוק (לטענתם), על רקע טענות של צוקרברג על כך ש HTML5 עדיין אינה מספיק טובה.
  Sencha גם עורכת תחרות בשם HTML5isReady ברוח דומה.
  
  בכל מקרה, ניתן לומר בבירור שלאפליקציות נייטיב יש יתרון בתחום זה. בכדי להגיע בעזרת HTML5 לתוצאות של Sencha יש צורך במומחיות יוצאת-דופן בפיתוח ווב, בעוד בפיתוח נייטיב - תוצאות יפות הן המצב הכמעט-סטנדרטי.
• Full Access to OS APIs אמנם ניתן לגשת כיום בחלק מהמכשירים ל GPS או אפילו למצלמה מקוד JavaScript של אפליקציית ווב, אך עדיין יש סט גדול של יכולות הזמינות רק מקוד native על המכשיר: גישה לאנשי הקשר, חיבור לרשתות חברתיות עם פרטי בעל המכשיר, ניהול קבצים ועוד.
• App Store Distribution. הדרך הסטנדרטית לחפש אפליקציה למובייל היא כמובן דרך ה App Store של המכשיר - הזמינה רק לאפליקציית נייטיב. עבור חברה קטנה שמוכרת אפליקציות - גישה ל App Store היא הכרחית על מנת להפיץ את האפליקציה. עוד בנושא ניתן לקרוא בלינק לפוסט על חנויות אפליקציה.

לפיתוח אפליקציות Web יש כמה יתרונות חשובים משלהן:

• Easiest Multi-Platform Development קלות בפיתוח למספר מכשירים. שימו לב שאני אומר קלות ולא "פיתוח יחיד". זאת בשל קושי לבצע Full User Experience Reuse ובשל שכיחות הבאגים בדפדפנים מוביילים (בולט במיוחד: Android Browser על גרסאות אנדרואיד 2.3 ומטה).
• Full control on updates באפליקציות נייטיב אינני יכול לשלוט מתי/האם משתמשים מעדכנים את גרסת האפליקציה - כך שה Backend שלי צריך לתמוך בגרסאות שונות. אם יש לי עדכון קריטי (אולי עדכון אבטחה?) - בווב אשחרר אותו לכל המשתמשים מיידית. בנייטיב: תהליך האישור של חנות האפליקציות יכול לעכב אותי בכשבוע או יותר בשחרור השינוי הקטן ביותר. תכונה זו חשובה יותר לארגונים.
• Interoperability & Extendibility נקודה זו היא חסרת חשיבות כמעט ל Consumer אך חשובה מאוד ל Enterprises ועושה לעתים רבות את ההבדל: מכיוון שאפליקציות נייטיב רצות ב Sandbox - אין מודל קיים של Plug-in שארגון יכול להשתמש בו על מנת לבצע התאמות של אפליקציית נייטיב לצרכיו הספציפיים. מאידך גיסא הרחבות בווב (ב JavaScript) הן קלות מתמיד - ויש הרבה ידע ותשתיות קיימות. אלמנט נוסף שחשוב למחלקות ה IT הוא Branding: היכולת לצבוע את האפליקציה בצבעים והלוגו של החברה (כדי שיהיה ברור מעורבותה של מחלקת ה IT). לקוחות רבים דחו אפליקציות בגלל יכולת זו בלבד, סיבה שנראית כחסרת-חשיבות למי שלא מבין את הפוליטיקה הפנימית של ארגוני IT בארגונים גדולים.

פתרון הביניים: Hybrid

הפלא ופלא, אנשים יצירתיים חשבו על פתרון לשלב בין גישות ה Web וה Native במכשירי המובייל. בכלי הפתוח למערכות ההפעלה השונות ישנו פקד (פקד = control. ממש כמו כפתור או רשימה) שנקרא WebView ומהותו הוא הצגת תוכן וובי בתוך אפליקציית native.

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

• בתור התחלה: ניתן להפיץ את האפליקציה ב App Store, מכיוון שמעתה זו אפליקציית נייטיב לכל דבר.
• ניתן לשמור את קבצי ה HTML מקומית מבלי "לחלוק" Cache עם אפליקציות אחרות ולהבטיח טעינה מהירה יותר של האפליקציה.
• ניתן, ופה אולי היתרון יוצא-הדופן, לחשוף פונקציות של האפליקציה הנייטיב כ javaScript API כך שאפליקציית הווב תוכל להשתמש בהן - וכל להעשיר את אפליקציית הווב ביכולות ״נייטיב״. לדוגמה: חישובים שדורשים יעילות גבוהה (כמו פענוח הצפנה), גישה ל OS API כגון שליפת אנשי הקשר, הפעלת רטט, או גישה לתמונות שצולמו לאחרונה בעזרת המכשיר.

ישנם פתרונות סטנדרטיים, לדוגמה PhoneGap או MoSync, של Containers מוכנים-מראש לאפליקציות ווב הנקראים Hybrid Container או Hybrid Web Container. ע"י שימוש בפתרונות אלו, אתם יכולים להתמקד בפיתוח אפליקציות ווב (עם התכונות הנלוות של הווב) ורק "לארוז אותן" כאפליקציית נייטיב. PhoneGap מספקת Containers מותאמים למספר רב של מערכות הפעלה מוביליות, וחושפת JavaScript API אחיד ממערכות ההפעלה כך שתוכלו לכתוב אפליקציית ווב פעם אחת, ולגשת לשירותים של מערכת ההפעלה השונות מבלי להיות מודעים למערכת ההפעלה שמריצה את ה Container.

רשימת הנייטיב API ש PhoneGap חושפת עבור אפליקציות ווב, על פלטפורמות שונות. מקור: וויקיפדיה. (לחצו על התמונה להגדלה).

בואו נשווה את תכונות ההייבריד לאלו של אפליקציות נייטיב או ווב:

פיתוח בעזרת Framework הכולל Hybrid Container מספק יתרונות משני העולמות, הווב והנייטיב:

• גישה מלאה ל API של מערכת ההפעלה. אם זה לא API שמסופק Out of the Box ע"פ ה Framework, אני יכול להוסיף wrapper של קוד נייטיב החושף javaScript API בעצמי.
• הפצה של האפליקציה ב App Store.
• קלות בפיתוח Cross Platform (באופן חלקי: ייתכן ועלי לתחזק wrappers משלי)
• שליטה מלאה על עדכונים (חלקי: עבור חלק הקוד הוובי באפליקציה. עבור שינויים בקוד הנייטיב עלי לעדכן גרסה של ה container / native app).
• Interoperability / Extendibility (חלקי: רק עבור חלקי הקוד הוובי).
• ה User Experience יהיה עדיין נתון רובו ככולו ליכולות הווב, קרי HTML5/CSS3.

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

• את ההבדל מעל מערכות הפעלה שונות קשה להחביא, ו"ה javaScript API האחיד" מעל מערכות ההפעלה השונות לא מתנהג כ"כ יפה.
• ישנו פער זמנים בין הזמן בו משתחררת גרסת מערכת הפעלה (למשל iOS 6) לזמן בו משתחררת גרסת ה Container שתומכת בה. מדובר בחודשים. במקרי הקצה, פונקציונליות יכולה להישבר (תמיכה לאחור איננה הצד החזק של אפל, למשל) ולדרוש מכם לכתוב wrappers משלכם, ללא תלות ב Frameworks.
• ה Hybrid Frameworks מוסיפים Layer נוסף של תלות גם ברמת הבאגים והבעיות השונות. שוב סיבה לעקוף את ה Framework בכדי ליצור workarounds. איתור תקלה (האם היא באפליקציה שלכם, ב Hybrid Container או במערכת ההפעלה?) הופכת למשימה קצת יותר מורכבת. באג רציני דורש הבנה ב Internals של מערכת ההפעלה - כך שהניתוק ממערכת ההפעלה אינו מוחלט.
• עליכם להקים ולתחזק סביבת Build לכל הפלטפורמות שאתן רוצים לתמוך בהן, משימה שאיננה פשוטה למפתח הבודד. את ה custom native code שאתם מפתחים עליכם לתחזק לכל פלטפורמה (ואולי אף גרסאות שונות של מערכת ההפעלה) - כך שיש אלמנט של קוד כפול.

אינני רוצה ליצור את התחושה ש Hybrid Framework הוא פתרון לא-מוצלח. לפתרון Hybrid יש הרבה ערך ופוטנציאל והם יכולים להיות בסיס לפתרונות מצויינים - בעיקר כשמבינים את ה Tradeoffs שבאים איתם. הדבר העקרי לו כדאי להיות מודעים הוא פער גדול בין ציפיות גבוהות למדי ומציאות שאיננה כולה דבש. אחוז לא מבוטל של מפתחים מתחיל לעבוד עם Hybrid Container בציפייה ל Silver Bullet רק כדי לגלות שיש גם מורכבויות - ואז נוטש אותו.

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

Native Transformers

קטגוריה נוספת ואחרונה של כלי פיתוח מובייל עבור Multi-Device נקראת Native Transformers. נניח שהחלטתם ששימושיות וגישה למערכת ההפעלה חשובה מספיק עבורכם, והתחלתם לפתח נייטיב 6 גרסאות של האפליקציה עבור 3 מערכות הפעלה שונות (+ טאבלט / סמארטפון).

עבור iOS עליכם לפתח בשפת Objective-C ב XCode על גבי מחשב מק.
עבור Android אתם מפתחים בג'אווה על איזו סביבה שמתחשק לכם, וב Eclipse.
עבור Windows Phone / 8 אתם מפתחים בשפת #C על גבי VS2012 שרץ רק על גבי Windows 8.

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

כתבו הרבה קוד משותף, ומעט קוד ספציפי - ההבטחה של ה Native Transformers.

Native Transformers מבטיחים לעזור בנושא זה. הם מציעים לכם לכתוב פעם אחת את הקוד שיכול להיות משותף, בשפת ביניים (לרוב javaScript או וריאציות שלה), בעוד ה Native Transformer יקמפל קוד זה לקוד נייטב עבור מערכות ההפעלה השונות, וייצור לכם שלד של פרויקט בסביבה המתאימה ממנו תוכלו להמשיך. יתרה מכך, חלק מהפתרונות בנויים כך שתוכלו לבצע שינויים בקוד המשותף ולהעביר את התוצר לסביבות הפיתוח הספציפית (לדוגמה: iOS, Windows 8) מבלי למחוק / לפגוע בפיתוחים הספציפיים שכבר עשיתם. מבנה שדומה להורשה בו רק מחלקת האב משתנה ברגע שמקמפלים את הקוד המשותף.

מכיוון שמספר גדול של Native Transformers מתבסס על javaScript כשפת ביניים, לא נדיר למצוא פתרונות שיכולים גם "לקפמל" גרסאות HTML5, כלומר ווב.
תכונה נוספת מקובלת היא Designer מסוג WYSIWYG בו אתם יכולים להרכיב בשפת הביניים את ה UI הכללי ולקבל שלד מוכן של UI בפקדים של מערכת ההפעלה הספציפית.


בואו נשווה את ה Native Transformers לפתרונות שקרובים אליו ביותר, הרי הם פיתוח נייטיב על הרבה פלטפורמות מצד אחד, ופתרונות ה Hybrid מהצד השני:

ישנו מספר רב למדי (אני שמעתי על כ 10 ויותר) של Native Transformers, בעיקר בעולם ה Enterprise. השלושה הנפוצים ביותר הם כנראה:

• Appcellerator Titanium - הפלטפורמה המוכרת ביותר בקטגוריה זו.
• Adobe Air - בעיקר עבור תוכנות גרפיות / משחקים. מספר לא מבוטל של משחקים שאתם משחקים בסאמרטפון שלכם ונראים נייטיב לחלוטין נכתבו בעצם ב Air.
• Antenna - שחקן מרכזי בשוק האנטרפרייז.

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

ל Native Transformers יש כמה חסרונות:

• בדומה לפתרונות Hybrid - יש כאן תלות בשחקן צד שלישי, בקצב העדכונים שלו, האיכות שלו, היציבות הפיננסית שלו וכו'. התלות בספק ה Native Transformers גדולה משמעותית מהתלות בספק ה Hybrid Container, אותו קל יחסית "לעקוף".
• שפת הביניים, הספריות שלה ובעיקר כלי העיצוב הגרפי הם סביבה חדשה (ולא כ"כ סטנדרטית) שיש ללמוד - מה שהופך את ה Learning curver לגבוה, למרות ש Native Containers ממוצבים ככלי Productivity לפיתוח מהיר על מספר פלטפורמות. בכל מקרה עליכם לדעת לפתח נייטיב בכל הפלטפורמות ולהכיר מספיק טוב את מערכות ההפעלה - הרי ה Native Transformers יוצרים בסה"כ שלד דיי גס של אפליקציה שיש עוד לעבוד עליו.
• גודל ה binaries של האפליקציה גדל בצורה משמעותית. פי 10 הוא לא מספר חריג במיוחד. זה לא נשמע מעניין כ"כ בימנו, שהרשתות מאוד מהירות, אולם מערכות הפעלה מוביליות לא מרשות (משיקולי שמירה על סוללה) להוריד ב 3G אפליקציות מעל גודל מסוים (בימנו הגבול הוא 20-50MB, תלוי במערכת / גרסה). כלומר: ייתכן והאפליקציה שתיווצר, גם אם היא נראית פשוטה - לא תוכל להיות מותקנת ללא חיבור WiFi.
• פתרונות אלו הם לרוב מסחריים, ובעלי רישיונות יקרים מהממוצע.

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

הרבה אופציות. כיצד בוחרים?

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

לו הדילמה הייתה פשוטה, קרוב לוודאי שהפוסט לא היה מתארך כ"כ J.

סה"כ הקו המנחה הוא כזה: ארבעת הקטגוריות נמצאות על סקאלה: בצד אחד פתרונות ה Web (הכי זול לפתח Cross-Device, אבל חווית המשתמש הכי פחות אינטגרטיבית) ובצד השני האופציה לפתח נייטיב בנפרד על כל פלטפורמה.

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

אם אתם סטארט-אפ קטן, עובדים Lean או רק מתחילים - כנראה שעדיף לכם ללכת בגישה של Web-First (אולי רק עם Container לצורך הפצה - אם מדובר באפליקציה לצרכן הפרטי).

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

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

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

לסיכום

עברנו על ארבעת הקטגוריות לפיתוח אפליקציות מובייל, Cross-Device והשוונו בניהן.

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

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

שיהיה בהצלחה!

דיסקליימר: החברה בה אני עובד, SAP, מוכרת גם כלי Native Transformers. לא התנסיתי בהם, אבל אני מניח שהם הטובים בקטגוריה.


----

[א] אני קצת מוטה לעולם הארגוני, כנראה. אפליקציות ל Consumer הן רובן נייטיב עדיין.

Posted with Blogsy