תגית: Mobile

פיתוח למובייל: 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 הן רובן נייטיב עדיין.

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

החלטתם לפתח אפליקציית מובייל. אולי אפליקציה חדשה, ואולי וריאציה מובילית למערכת קיימת. הצעד הטבעי הראשון הוא לפנות לאנשי ה Marketing / ניהול המוצר ולשאול: “באילו מכשירים עלינו לתמוך?”. רשימת המכשירים יכולה להשפיע רבות על בחירת הטכנולוגיה.למשל: אם אתם רוצים לפתח אפליקציה לאייפד (iPad) בלבד – יש סביבת פיתוח ייעודית של אפל שמתאימה במיוחד למשימה זו. אם אתם רוצים לפתח למספר גדול של סוגי מכשירים (סמארטפונים, טאבלטים ופאבלטים[א]) ודגמים – יש ייתרון בפיתוח אפליקציית ווב, שלכאורה נכתבת פעם אחת ואז רצה אותו הדבר על כל המכשירים.

סביר אגב, שהתשובה שתקבלו מאנשי המוצר תהיה: “iPhone בעדיפות ראשונה, iPad בעדיפות שנייה ומאוחר יותר נרצה כנראה לתמוך גם ב Android”, שמשמעה בפועל הוא בד”כ: “אנו הולכים אחרי העדר, אנחנו לא ממש יודעים”.

יש לנו כאן דילמה מהותית וכמעט חדשה:
עבור אפליקצייה שולחנית הבחירה בין אפליקצייה native לאפליקציית ווב היא ברורה וקלה יותר: הצידוק לאפליציית native הוא בעיקר צורכי גרפיקה / זמן אמת (משחקים / תוכנות גרפיות / כלי productivity) או כלים ספציפיים למערכת ההפעלה (למשל אנטי-וירוס). כל השאר – הלך לווב. מכיוון שמערכת ההפעלה “חלונות” הייתה מונופול בצד ה Client – הפיתוח נעשה בכלים מתאימים (Windows Forms/WPF) עם נישה קטנה של UI בג’אווה (או שפות VM אחרות) – בעיקר לכלי אדמיניסטרציה.

המונופול של Windows ו Intel אפשר תאימות גבוהה, כך שאפליקציה שפותחה לחלונות ונבדקה על מחשב Dell, רצה היטב גם על מחשב מכל דגם של HP או Lenovo.

אנו נראה שהדילמה בפיתוח למובייל דומה – אך שונה ומורכבת יותר.

באיזה מכשירים לתמוך? הרבה מכשירים, הרבה יצרנים.

BYOD

לפני שנה שוחחנו עם לקוח גדול שבחר להשתמש במערכת שלנו.
“באיזה מכשירים אתם מתכוונים להשתמש?” – שאלנו. “משיקולי אבטחה, תהיה לנו מדיניות נוקשה של iOS[ב] בלבד! לא נרשה חיבור מכשירים אחרים למערכת”.
“כמה נוח”, חשבנו לעצמנו, “הנה לקוח שסגור על עצמו”.
לאחר כשישה חודשים התקשר אותו הלקוח וחקר על תמיכה באנדרואיד.
“חשבנו שאתם עובדים רק עם iOS…”, תהינו בקול. “נכון”, הוא ענה, “אבל… להרבה מאוד עובדים יש מכשירים שלהם שהם הביאו מהבית, רובם מכשירי אנדרואיד, והם לוחצים שנחבר אותם למערכת. אלו עובדים שלא קיבלו מאתנו מכשירים באופן רשמי, אבל עדיין רוצים להתחבר למערכת לצורכי עבודה. קשה לסרב לזה”.תופעה נפוצה מאוד בארגונים היום היא תהליך שנקרא Bring Your Own Device (או בקיצור BYOD) – בה לעובדים יש מכשירים בעלי יכולות שהם רכשו והם רוצים להשתמש בהם לצורך העבודה.

נכון לשנת 2013, BYOD הוא מיינסטרים

מ BYOD נהנים שני הצדדים: הארגון מפחית עלויות (מכשירים, הכשרה, חידוש מכשירים) בעוד העובדים יכולים לעשות יותר עבודה ובדרך שהם בוחרים. ניתן למצוא כיום גם מדיניות של Buy Your Own Device – בה הארגון מספק לעובדים תקציב בכדי שיקנו לעצמם מכשיר בעצמם וע”פ בחירתם (תחת מגבלות מסוימות) – סימן לחשיבות שיש לבחירת המכשיר ע”י העובד.

למורת-רוחם של גופי IT רבים, מדיניות BYOD היא לרוב איננה יוזמה של גוף ה IT אלא תגובה ללחץ ו”קביעת עובדות” מצד היחידות העסקיות (Line Of Business) בשטח.

המשמעות המעשית של BYOD היא הצורך לתמוך במגוון רחב של מכשירים, ללא יכולת של גוף ה IT להכתיב או לבחור את המכשירים, כפי שיכול היה במשך שנים להכתיב את חומרת ה PC או את הדפדפנים שבשימוש[ג]. דיי נדיר היה לראות עובד מחסן שמביא PC מהבית לעבודה ודורש לחבר אותו למערכות הארגוניות.

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

רוב מפתחי האפליקציות מתכננים לתמוך ב2 פלטפורמות או יותר

דיי ברור שפיתוח Native (ל iOS, אנדרואיד, בלאקברי, Windows 8, וכו’) מספק את מירב האפשרויות לפיתוח האפליקציה – ביצועים טובים יותר ויכולת לגשת ליכולות ספציפיות של המכשיר וכו’ – ממש כפי שאפליציית Windows Native יכולה לעשות יותר מאפליקציית ווב הרצה על חלונות. בניגוד למחשב השולחני, אם נכתוב אפליקציה native למובייל בטכנולוגיה מסוימת – נגיע לפחות מ50% מהמשתמשים. כדי להגיע לאחוז דומה של משתמשי “חלונות” (כ 90%), עלינו לפתח עבור 3 מערכות הפעלה שונות ובסביבות פיתוח שונות, מה שמכעט משלש את כמות ההשקעה – מכיוון שאלו מערכות הפעלה שונות.

לא דיברנו עדיין על עוד 2 מכפילים נוספים המשפיעים על “מספר הפלטפורמות בפועל”:

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

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

  • סמארטפון: iPhone (ו iPod Touch)
  • סמארטפון: Anroid של סאמסונג (סדרות Note, Ace, Galaxy וכו’)
  • טאבלט: iPad
  • סמארטפון: Windows Phone
  • טאבלט: Windows 8 (הערה: Windows 8 ו Windows Phone הן מערכות הפעלה דומות, אך שונות).
  • טאבלט: Amazon Kindle Fire (נפוץ בקרב משתמשים פרטיים).
  • ? טאבלט אנדרואיד* – אולי Galaxy או Nexus
  • ? סמארטפונים של יצרן אנדרואיד* נוסף. HTC, ZTE או מוטורולה הן המועמדות המובילות.
  • ? מכשירים של מערכת הפעלה רביעית. מתמודדות עיקריות: Tizen אולי BlackBerry 10 או FireFox OS.
  • ? מסכים (כבר לא נכון לקרוא להם “טלויזיות” או “טלויזיות חכמות”) המריצים מערכות הפעלה מוביליות לינק1 לינק2.
* בעולם האנדרואיד, יש משמעות מיוחדת ליצרנים השונים. אשתדל לכסות עניין זה בפוסט המשך.
תחזית לפילוח מערכות ההפעלה המוביליות בשנים הקרובות

נתח השוק שמנבאים למייקרוסופט עשוי להפתיע רבים, אולם לקוחות עסקיים רבים “ישבו על הגדר” במשך זמן-מה ולא בחרו פלטפורמה מובילית לעבוד איתה. בקרב ארגונים, אפל נתפסת כ”ממוקדת לקוח-פרטי” (Consumer-Oriented), לא-קשובה מספיק ללקוח העסקי וגם חזקה או עצמאית מדי בכדי “להתגמש” מול לקוחותיה העסקיים. אנרואיד… נתפסת כאלטרנטיבה משמעותית פחות מוצלחת – אדבר עליה בפוסט הבא. מייקרוסופט היא חברה שהארגונים כבר רגילים לעבוד איתה וסומכים עליה שתהיה קשובה לצורכיהם.

כשראיתי לראשונה את התחזיות המציבות את מייקרוסופט בקו אחד עם אפל בתוך כמה שנים, זה נראה לי דמיוני: Windows Phone 7 הייתה דיי מפגרת אחרי המתחרות, ונראה היה שמייקרוסופט מאחרת ביותר מדי בכדי שיהיה לה סיכוי להתמודד ברצינות ולהשלים את הפער.
דברים ששמעתי לאחרונה מלקוחות מתיישבים היטב עם התחזיות המנבאים למייקרוסופט חדירה משמעותית לשוק המוביל: ארגונים רבים מביעים נכונות רבה מאוד לעבוד עם מייקרוסופט, גם במחיר סלחנות מסוימת על פלטפורמה שעדיין איננה בוגרת. “בחירות מסוג זה הן עבורנו בחירות לעשור, לא לשנה-שנתיים כמו שלקוח פרטי בוחר מכשיר טלפון” – הסביר לי מנהל IT.

UX Reusability

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

לדוגמה: ה UX Guidelines של חלונות 8 אוסרות על אפליקציה להוסיף אלמנט חיפוש בשטח האפליקציה. החיפוש נעשה מתוך SideBar של מערכת ההפעלה (נקרא “Charm”) גם כאשר מדובר בחיפוש בתוך-האפליקציה. למכשירי ה Windows Phone יש כפתור חיפוש פיסי בתחתית המכשיר.

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

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

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

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

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

הנה דוגמה לאפליקציית הווב של Financial Times, והדרך בה היא מציגה חיפוש על טאבלטים במערכות הפעלה שונות. בסקאלה שבין “UI כמו של מערכת ההפעלה” עד ל “UI עצמאי”, FT בחרו גישת ביניים של “אזרחות טובה”. האפליקציה בסה”כ נראית אותו הדבר על כל הפלטפורמות, מלבד אלמנטים שסותרים בצורה משמעותית את ה UX Guidelines של הפלטפורמות השונות[ד].

—

[א] Phablet – יציר הכלאיים בין טאבלט לאייפון. לרוב בעל מסכי “5 עד “7, שניתן לבצע מהם שיחות. דוגמה בולטת: סדרת ה Galaxy Note של סמסונג.

[ב] מערכת ההפעלה של מכשירי אפל: iPad, iPhone ו iPod Touch.

[ג] בארגונים רבים, IE הוא הדפדפן היחידי שנתמך לשימושים ארגוניים. Chrome יכול לשמש רק לגלישה אישית באינטרנט או שלעתים אף מונעים / אוסרים התקנה של כל דפדפן מלבד זה שהוחלט ע”י ה IT (שזה לרוב IE).

[ד] כדאי להכיר:

סימני המהפכה (מובייל)

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

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

שינוי? אתם בטוחים?

הנה אחד הגרפים שעבורי הוא עוצמתי במיוחד:

במהלך שנות ה-80, Wintel (צימוד של Windows ו Intel) השתלטו לחלוטין על שוק המיחשוב – על חשבון כמעט כל השחקנים האחרים. הם שלטו בעוצמה במהלך שנות ה-90 ושנות ה-2000, כמעט 2 עשורים. לפתע פתאום, בשנים ספורות, המערכות שהם מייצרים ומוכרים הפכו להיות מיעוט של המערכות הנמכרות. בשנת 2012 רק כשליש ממערכות המחשוב האישי שנמכרו היו WinTel.
הנתונים בגרף הם דיי מדהימים וכנראה לא מבטאים את התחושה שיש לרבים מאיתנו: ה PC עדיין כאן, ומקומו יציב.
את התמונה משלים הגרף הבא:
ובכן, זה לא שמחשבי ה PC נזרקו לפח והפסיקו להימכר – פשוט יש מכשירים חדשים, סמארטפונים וטאבלטים, שנכרים בקצב גדול בהרבה.
כבר כמה שנים אנו יודעים על מגמה ברורה של צמיחת הלפטופים על חשבון המחשבים השולחניים, גם בבית וגם במקומות העבודה – אולם זו הייתה מגמה הדרגתית. הפריצה של מכשירי המובייל היא מהירה לאין-שיעור.
ב2012 יכולנו לראות צמצום לא רק במכירות המחשבים השולחניים, אלא גם במכירות הלפטופים שעד כה צמחו. ה Netbook (מחשב נייד קטן וזול) נעלם מהעולם ויצרנים גדולים כבר הפסיקו לייצר אותו (לינק1, לינק2). טאבלטים הם התחליף.
במקום Windows יש את Android ו iOS.
במקום מעבדי Intel ישנם מעבדי ARM.
ל Wintel יש סיבה טובה מאוד להיות מודאגים – והם כבר פועלים בשנה-שנתיים האחרונות במלוא המרץ, כולל קניבליזציה של מוצרים קיימים שלהם, על מנת להסתגל למציאות החדשה.
שאלה נפוצה היא: האם סמארטפונים הם באמת תחליף למחשב או שהם סתם עוד טלפון נייד? האמת היא, כנראה, איפשהו באמצע.

על אופניים ומשאיות

ההצלחה של מכשיר האייפון הפתיעה את כולם: אנליסטים, מומחים ומתחרים. יש שאומרים שזו הייתה הפתעה חד-פעמית שלא יכולה עוד לחזור על עצמה שוב בשנים הקרובות.
הסיבה הייתה כמובן נקודת הייחוס: האייפון היה הרבה יותר יקר ממכשירי טלפון אחרים. התאוריה הכלכלית גורסת שלמכשירים יקרים יש מעט קונים – אולם את האייפון קנו הרבה מאוד אנשים למרות מחירו הגבוה. הסתכלו מסביב: כמעט לכולם יש אייפון (או אנדרואיד) – גם אנשים שאינם עשירים או שאינם נוטים לקנות מוצרי יוקרה.
כיצד ניתן להסביר זאת?
חשבו לדוגמה על אופניים. אנשים רבים קונים ומשתמשים בהם. אופניים \”רגילים\” עולים 500, אולי 1000 ש\”ח. נאמר שמחר מופיעה חברה בשם \”אגס\” ומציעה אופניים מ-ד-ה-מ-י-ם במחיר 100,000 ש\”ח. כמה זוגות אופניים אתם חושבים שימכרו? בוודאי יש כמה טייקונים ובני עשירים שלא יתקשו להוציא סכום שכזה – אך הם עדיין מעטים.
מנכ\”ל \”אגס\”, סתיו עובד, מסביר בתוקף שזו קטגוריה שונה של מוצר: באופניים שלו יכולה ליסוע ביחד משפחה שלמה. החוויה נעימה ונוחה הרבה יותר, שקטה ונעימה. לא נכון להשוות אותם ל\”אופניים סתם\”.
אבל, 100,000 ש\”ח? השתכנעתם?
ובכן, מסתבר שה\”אופניים\” של חברת \”אגס\” הם בעצם רכב משפחתי, וכן – גם מי שאינו עשיר במיוחד או אינו נוטה לקנות מוצרי יוקרה עדיין מוציא סכום גבוה של 100,000 ש\”ח וקונה רכב. זו חוויה כ\”כ שונה ויותר טובה – שכולם רוצים אותה.
מהצד השני יש את המחשב האישי: ה PC. ה PC, כפי שתיאר אותו פעם סטיב ג\’ובס (לא לבלבל עם סתיו עובד), הוא כמו משאית: הוא כלי עבודה מקצועי, מאוד Capable – שאינו מותאם לצורכיהם של רוב המשתמשים. ה PC גדול, מסורבל, מסובך לשימוש ואיני אופטימלי לסט המשימות שאנו נוהגים לעשות הכי הרבה: לקרוא מייל או מסמך, לשמוע מוסיקה או לראות סרטון ביו-טיוב.
כמו משאיות, ה PC לא צפוי להיעלם – זהו כלי עבודה חשוב. ייתכן והוא יהפוך להיות נישה קטנה, שכוללת אולי 5% מהמחשבים בעולם. כפי שיש הרבה משאיות וכמה חברות מרוויחות מייצורן יפה, אך הן עדיין המיעוט.

עד כמה ההצלחה של אפל היא גדולה?

לכולם ברור שאפל הצליחה מאוד, שהמנייה שלה עלתה מאוד ושבעלי המניות כנראה מרוצים. בכל זאת, לסיום, הייתי רוצה להתבונן שוב במספרים המדהימים של אפל.
בעולם הגלובלי שלנו, כשאפשר לייצר מוצר חדשני ולשווק אותו בו-זמנית בכל העולם למיליוני אנשים – למוצר מהפכני אמיתי יש השפעה כספית מדהימה, מבהילה אולי.
בואו נשווה את הרווחים של אפל לאלו של חברות מקבילות.
אם נניח שאפל היא חברת תוכנה (תחום רווחי מאוד) – היא עדיין הרוויחה ב 2012 יותר מגוגל, מייקרוסופט, איביי, יאהו, פייסבוק ואמזון ביחד. כל אחת מהחברות הללו היא ענקית מעוררת קנאה, אבל אפל הרוויחה יותר מכולן ביחד. וואהו!
אפשר לומר שאפל היא חברת חומרה, כיצד אם כן היא משתווה לייצרני ה PC הגדולים? ובכן: אפל מרוויחה כפול מיבמ, לנובו, HP, אינטל, דל, אייסר ואסוס ביחד.
מה עם חברות המדיה? אפל הרי מוכרת תוכן (מוסיקה, ספרים, סרטים). אפל מרוויחה כפול מוולט דינסי, ניוז קורפ, טיים וורנר ועוד – ביחד. לא חברות קטנות או \”פראייריות\”.
האם אפל היא יצרנית טלפונים? אם משווים את הרווחים שלה לרווחים המצרפיים של נוקיה, סמסונג (שכרגע מרוויחה הרבה מאוד), HTC ו RIM – היא עדיין משאירה להן אבק.
אפל, אגב, עושה את רוב רווחיה בעקבות מכירת חומרה: אייפונים ואייפדים. לא מתוכנה, לא מתוכן ולא מאפליקציות.
שיהיה בהצלחה בעולם החדש!

סמינר על פיתוח למובייל בכנס MOBI WEB של ג\’ון ברייס

בעוד כ-3 שבועות אעביר סמינר על נושא פיתוח המובייל, טכנולוגיות, בחירת פלטפורמה וכו\’.
אודה לכם אם תפיצו למי שעשוי להיות רלוונטי ו/או מעוניין.
עדכון: גיל גבעתי, מנכ\”ל Efficens Software, יצטרף אלי וידבר על ניתוח התנהגות משתמשים בתוך אפליקציית המובייל.
כנס MOBI WEB כולל מגוון מרצים ונושאים סביב לנושא המובייל – יש עוד הרבה נושאים מעניינים (חלקם גם בחינם).
תודה מראש,
ליאור

במה שונה פיתוח למובייל?

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

שפה חדשה

האם אתם שולטים ב Objective-C? ב JavaScript? ב HTML5 וב CSS3? ב ++C/C?
אם אתם הולכים לפתח למובייל – ייתכן ותאלצו ללמוד שפת תכנות חדשה: זו כבר לא כל-כך בחירה שלכם מה אתם מעדיפים – זו דרישה של הפלטפורמה.

סביבת עבודה חדשה

כמה מכם מכירים Linux או Unix? כמה רגילים לעבוד ב Mac OS או חלונות 8 (שבה חוויית השימוש שונה לחלוטין)?
האם אתם רגילים ל Visual Studio, Eclipse וגם Xcode?
ייתכן ותאלצו להתרגל לסביבה חדשה וכלים חדשים.

ספריות חדשות

הביטו במפה הבאה שיצרתי. עם כמה מהספריות הללו עבדתם כבר? האם אתם מזהים לאיזה תחום כל ספרייה שייכת?

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

חזרה לפיתוח של אפליקציות מקומיות / Rich Client  / אפליקציות שולחניות

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

משתמשים חדשים

כמה מהמשתמשים שלכם כיום:

  • נמצאים במרחק-נגיעה מהמחשב 90% מהזמן?
  • אומרים: \”אל תתן לי להקליד במקלדת\”?
  • מסירים תוכנה אם היא לא הגיבה תוך 2-3 שניות?
  • עובדים בתנאי רעש ותאורה לקויה?
אנו נוהגים לומר שאותם האנשים, עם אותם צרכים והעדפות, ברגע שהם נוגעים במכשיר מובייל – הופכים למשתמשים מזן חדש.

מומחיות חדשה

האם אתם מומחים למגע (Touch) ומחוות (Gestures)? יודעים להבדיל בין \”התנהגות חלקה\”, \”קצת מקרטע\” ו \”ממש flickering!\”? ואם ההתנהגות לא-טובה, מה עושים בכדי לשפר אותה?
האם אתם מכירים את רוב הדגמים של המחשבים של הלקוחות שלכם ואיזו חומרה יש להם? חומרת Desktop היא סטנדרטית למדי – לא כך במובייל.
האם אתם יודעים למה אין (כמעט) סמארטפונים עם חלת-דבש? (גרסת אנדרואיד)
כיצד אתם בוחרים מה ייכנס ל Notification Area, ל Action Bar או כ Charm?

שינוי בסדרי-גודל

מעבר מפיתוח אפליקציות (Application) יחידה עם הרבה פונקציות –> לפיתוח אפליקציות (Apps) רבות בעלות פונקציה יחידה כל אחת. סביר להניח שאם לתוכנה שלכם יש כיום תפריט ראשי עם 6 פריטים, נכון יהיה בעולם המובייל להפוך 4 מהם ל-Apps* ו 2 אחרים \”להעלים\” (כלומר לומר למשתמש: עבור פעולה זו – לך לממשק ה Desktop).
* בלתי-תלויים!

חוקי עיצוב UI חדשים

נכון – מעולם לא הייתם מעצבי ה UI באופן רשמי, אבל תמיד הייתה לכם השפעה.
בעולם המובייל יש רף חדש של חוויית משתמש של אפליקציות פשוטות ו\”זורמות\”. אפליקציות שלא מתנהגת בהתאם – בולטות לרעה.
יש אתגרים חדשים כאשר עובדים על מסך של \”3 עד \”5 (לסמארטפון) או \”7 עד \”10 (טאבלט) כאשר אמצעי ההצבעה הוא אצבע ולא עכבר / עט.
יש כמובן גם כמה קונבנציות חדשות, לכל מערכת הפעלה – וגם בכלל בין מערכות ההפעלה השונות.

חזרה לתכנות מוגבל-משאבים

למכשיר סמארטפון ממוצע יש 512MB זכרון סה\”כ – לפעמים פחות. 
המעבד חלש משמעותית יותר, ה Storage קטן יותר והרשת אטית יותר.
מתי בפעם האחרונה לא היה לכם 1MB של זיכרון כשרציתם אותו??

חוקי ביצועים חדשים

ביצועים של אפליקציית מובייל מודדים במילי-שניות (זמן תגובה), צריכת זיכרון (ב MB) וכו\’ – כל אלה כנראה לא חדשים.
מדד חשוב חדש הוא (O(watt – מדד הסוללה. סוללה היא תמיד משאב בחסר כשמדובר במכשירים ניידים – וחשוב מאוד לתכנן את המערכת שלכם על מנת לנצל אותה בצורה נכונה. לדוגמה: להביא מידע קצת פחות עדכני ובאצוות גדולות, כי העלות של \”יצירת connection\”, מבחינת הסוללה – היא אדירה.

ערוצי הפצה חדשים

כלומר אפ סטורס, כפי שכבר כתבתי עליהם בפוסט הזה

אינטגרציה הדוקה יותר עם מערכת ההפעלה

בפיתוח אפליקציה למערכת ההפעלה \”חלונות\” יש כמה אפשרויות אינטגרציה – אולם מלבד הוספה של Tray Icon, מעטות האפליקציות שאכן התממשקו למערכת ההפעלה מעבר ל\”ריצה בחלון שהוקצה להן\”.
במובייל – אנו רואים הרבה יותר אפשרויות מצד מערכת ההפעלה והרבה יותר הענות מהמפתחים להתממשק למערכת ההפעלה. הסיבות העיקריות לכך הן שטח המסך המוגבל ורף חוויית המשתמש הגבוה יותר המקובל. בניגוד לחלונות, בה לרוב האפליקציות המגיעות עם מערכת ההפעלה (Notepad, Calculator) לא הייתה אינטגרציה משמעותית עם מערכת ההפעלה, מלבד ההפעלה הבסיסית, אפל דווקא הדגימה באפליקציות שהגיעו עם האייפון אינטגרציה גבוהה – והמפתחים הלכו בעקבותיה.

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

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