قال مارك زوكربيرج ذات مرة ، "أكبر خطأ ارتكبناه ، كشركة ، هو الرهان كثيرًا على HTML5 بدلاً من الأصلي ... لأنه لم يكن موجودًا. وليس الأمر أن HTML5 سيئ. أنا في الواقع ، على المدى الطويل ، متحمس جدًا حيال ذلك ". ومن الذي لن يكون متحمسًا لإمكانية وجود قاعدة رمز واحدة تعمل عبر منصات متعددة ؟

مزيد من القراءة على SmashingMag:

• دليل المبتدئين لتطبيقات الويب التقدمية
• اللبنات الأساسية لتطبيقات الويب التقدمية
• إنشاء تطبيق ويب كامل في Foundation For Apps

لسوء الحظ ، شعر Facebook أن HTML5 لا يقدم التجربة التي كان يتطلع إلى بنائها ، وهذا ما يدور حوله حقًا: التجربة. أعتقد أن ما كان مارك يحاول قوله حقًا هو أن أكبر خطأ ارتكبوه كان اتخاذ قرار مدفوع بالتكنولوجيا بدلاً من قرار يعتمد على تجربة المستخدم. في نهاية اليوم ، يجب أن نتخذ قرارات تقدم قيمة لعملائنا ، والالتزام بتكنولوجيا معينة ليس هو أفضل طريقة لتحقيق ذلك.

بالنسبة إلى عميلنا Beyond the Rack ، وهو بائع تجزئة للتجارة الإلكترونية عبر الإنترنت فقط ، كان هدفنا الأساسي هو إنشاء تطبيق يتمتع بتجربة مستخدم رائعة. مثل زوكربيرج ، أردنا أيضًا أن نتبع مسار HTML5 - أسلوب "الكتابة مرة واحدة ، تشغيل في كل مكان" للتطبيقات التي تمت كتابتها في واجهات ويب HTML5 جذابة للغاية. ولكن في عالم اليوم ، حيث أصبحت التطبيقات هي الطريقة الأساسية التي يتفاعل بها المستخدمون مع منتجك ، فإن الأداء ليس مجرد متعة - إنه ميزة تنافسية.

ومع ذلك ، فليس من الصحيح أبدًا أن جميع ميزات تطبيقك تحتاج إلى أن تُبنى بواجهات أصلية بالكامل. على سبيل المثال ، في حين أنه قد يكون من الصعب جعل الرسوم المتحركة للتنقل تبدو أصلية على الويب ، يمكن بسهولة استخدام صفحة الويب التي تحتوي على القليل من الرسوم المتحركة المعقدة أو لا تحتوي على أي رسوم متحركة في التطبيق بينما لا تزال تشعر بأنها أصلية. هذا هو كل ما يهم المستخدم حقًا. المطلوب إذن هو "ربما اكتب مرة واحدة ، وربما يتم تشغيلها في كل مكان - يعتمد الأمر حقًا على الميزة ...".

باختصار ، لا تختار بين الواجهات الأصلية وواجهات الويب . استخدم الأثنين.

في هذه المقالة ، سأوجهك خلال تجربتنا في إنشاء تطبيق لـ Beyond the Rack حيث نمزج المحتوى الأصلي ومحتوى الويب لإنشاء تطبيق "يشعر" بأنه أصلي.

دراسة حالة: إنشاء تطبيق لما وراء الرف

من الواضح أنه كان من المهم تحديد المشكلات التي كانت Beyond the Rack تتطلع إلى حلها لنفسها وعملائها من خلال تطبيقها. من الطبيعي أن يأتي اختيار ما إذا كنت تريد الانتقال إلى المحتوى الأصلي أو الويب لكل ميزة.

لقد أدركنا أنه لإنشاء تطبيق رائع ، نحتاج إلى القيام بعمل رائع مع جميع الأشياء الثلاثة التالية:

• واجهة التسوق
  Beyond the Rack هو بائع تجزئة عبر الإنترنت فقط ؛ لذلك ، فإن وجود واجهة رائعة لتصفح المبيعات وإجراء عمليات الشراء أمر بالغ الأهمية. نظرًا لأننا كنا نبني تطبيقًا محليًا ، فقد أتيحت لنا الفرصة لتجاوز ما يمكن أن تقدمه تجربة الويب.
• القابلية للمشاركة
  نظرًا لأن محرك الإيرادات الكبير لـ Beyond the Rack هو مشاركة العملاء لعناصر المبيعات المختلفة مع الأصدقاء ، فقد احتجنا إلى التأكد من أن المشاركة بين iOS و Android والمتصفح تكون سلسة قدر الإمكان.
• الاكتشاف
  توفر Beyond the Rack مبيعات محدودة الوقت لمستخدميها ؛ لذا ، فإن القدرة على الوصول إلى المستخدمين بسرعة أمر في غاية الأهمية. تقدم رسائل الدفع أفضل طريقة لجذب هؤلاء العملاء المخلصين ، وكانت في النهاية الدافع الأكبر في قرار إنشاء التطبيق.

دعنا نتعمق في كيفية قيامنا ببناء بعض أهم ميزات تطبيقاتنا Beyond the Rack iOS و Android: ما هي ميزات التطبيق التي تم إنشاؤها باستخدام تقنية الويب ، وما الميزات الأصلية بالكامل ، وكيف تعمل جميعها معًا.

واجهة التسوق

القطع الأصلية

لقد قمنا ببناء موقع ويب سريع الاستجابة لـ Beyond the Rack على الكمبيوتر اللوحي والجوال - موقع نفخر به. لكن لم يكن كافيًا مجرد طرح موقع الويب في عرض الويب وتسميته يوميًا ؛ لا يبدو موقع الويب في حد ذاته تطبيقًا محليًا. سبب كبير لذلك هو التنقل. في المتصفح ، لديك أزرار للخلف والأمام وشريط URL. في تطبيقات iOS و Android ، لدى المستخدمين توقعات مختلفة جدًا حول كيفية التنقل ، وأردنا مطابقة هذه التوقعات بحيث يشعر تطبيقنا بالاتساق مع كل نظام أساسي.

لقد صنعنا نموذجًا أوليًا يقوم بتحميل المحتوى ديناميكيًا عبر AJAX ويدير التنقل والانتقالات في لغات الويب ، ولكن لم نتمكن من جعله يشعر بالسلاسة مثل الانتقالات التي تراها في التطبيقات الأصلية. من الصعب جدًا مطابقة الرسوم المتحركة للتنقل على iOS و Android باستخدام تقنية الويب ، وأي شيء غير مرغوب فيه في التنقل سيجعل تطبيقنا يبدو أقل أصالة. إذا كان تطبيقك لا يعمل بمعدل 60 إطارًا في الثانية ، فسوف يلاحظ المستخدمون ذلك.

لقد توصلنا إلى نهج شعرنا أنه يجمع بين أفضل ما في العالمين: تحميل المحتوى الرئيسي من الويب ، ولكن استخدم عناصر التنقل الأصلية:

على نظام iOS ، كان تنفيذ هذا أمرًا بسيطًا حقًا. لقد استفدنا من وحدة التحكم في التنقل ، التي تدير مجموعة من المشاهدات ، بالإضافة إلى شريط التنقل للتحكم في التنقل بين كل طريقة عرض. في حالتنا ، فإن كومة المشاهدات هي في الحقيقة مجرد كومة من طرق عرض الويب - في أي وقت يحدث التنقل ، بدلاً من الانتقال إليه في عرض الويب نفسه ، نقوم بإنشاء عرض ويب جديد ، وندفعه إلى UINavigationController بنا وانتقل إلى الوجهة الجديدة. يعني استخدام مجموعات من طرق عرض الويب أيضًا أنه عندما يعود المستخدم ، لا يتعين عليه الانتظار حتى يتم إعادة تحميل الصفحة ، وهو أمر رائع لتجربته. إذا قررنا في المستقبل استبدال الميزة بطريقة العرض الأصلية ، فسنقوم ببساطة بدفع العرض الأصلي إلى المكدس ، بدلاً من إصدار عرض الويب لتلك الميزة.

على نظام Android ، سيكون ما يعادل وحدة التحكم في التنقل هو استخدام أكوام من الأنشطة. قررنا عدم استخدام أنشطة وأجزاء متعددة ، لأن كلاهما يتطلب إدارة دورة حياة معقدة للغاية. انتهى بنا الأمر إلى إدارة مجموعتنا الخاصة من طرق عرض الويب للتطبيق وكتابة رسوم متحركة أصلية مخصصة للانتقال بين كل طريقة عرض.

يستفيد عدد من التطبيقات الأخرى من عناصر التنقل الأصلية لتتوافق مع أنماط تصميم نظام التشغيل. تحقق من هذه الصورة لتطبيق Android الخاص بـ Basecamp ، والذي يستفيد من شريط التنقل الأصلي:

قارن أيضًا بين تطبيق أمازون وموقعه على الهاتف المحمول:

من خلال هذا النهج ، وجدنا مكانًا رائعًا لدينا للحصول على تجربة مألوفة للمنصة ، مع الاستمرار في الاستفادة من تجربة تسوق أساسية رائعة من الويب.

قد تكون هذه مفاجأة للكثيرين ، لكن مطوري تطبيق Facebook يجدون أيضًا باستمرار المكان المناسب ، مستفيدين من المحتوى الأصلي أو الويب عندما يكون ذلك منطقيًا لكل ميزة. وفقًا لمقال كتبه مهندس Facebook: "بالنسبة للمناطق داخل التطبيق حيث نتوقع إجراء تغييرات في كثير من الأحيان ، سنستمر في استخدام كود HTML5 ، حيث يمكننا دفع التحديثات من جانب الخادم دون مطالبة الأشخاص بتنزيل إصدار جديد من التطبيق . " يبدو كما لو أن Facebook يتخذ نفس النهج الذي نوصي به هنا: اختر التقنية لكل ميزة بناءً على الأداء وجهود التطوير المطلوبة والسرعة التي تحتاجها لإخراجها من الباب.

بالنسبة إلى تطبيقك ، ضع في اعتبارك كل حالة على حدة سواء كان إنشاء ميزة محليًا أو الاستفادة من محتوى الويب أكثر منطقية. نظرًا لصعوبة إنشاء التنقل الذي يبدو أصليًا ، فمن المنطقي على الأقل إنشاء ذلك باستخدام المكونات الأصلية.

بتات الويب

اليوم ، يتفق الجميع تقريبًا على أنه من الجيد تحسين مواقع الويب بشكل تدريجي : استخدم قاعدة ترميز واحدة لأدنى قاسم مشترك من المستعرضات ، وطبقة ذلك باستخدام الوظائف والتحسينات باستخدام JavaScript و CSS ، اعتمادًا على السياق - لا توجد قواعد أو قوالب رموز منفصلة للأجهزة المختلفة المطلوبة. تمامًا مثلما لا يكون من المنطقي إنشاء قوالب منفصلة للويب المحمول وسطح المكتب ، أردنا استخدام قوالب موقع الويب المباشر داخل التطبيق نفسه. التطبيق هو مجرد سياق آخر.

أسمي هذا المبنى مواقع الويب المتجاوبة "المدركة للتطبيقات" . من خلال بناء موقعنا الإلكتروني مع وضع سياق التطبيق وأدائه في الاعتبار ، سنكون مستعدين للشحن لجميع مستخدمينا عبر منصات مختلفة عاجلاً وليس آجلاً.

يجب أن تكون مواقع الويب قادرة على اكتشاف سياق التطبيق في ثلاثة أماكن: CSS وجافا سكريبت والخادم. أنشأنا فئة app لكتابة CSS شرطي وطريقة isRunningInApp لكتابة JavaScript شرطي ، وألحقنا App بوكيل المستخدم لمنطق جانب الخادم الشرطي.

يوجد مثال على المكان الذي استخدمنا فيه التحسين التدريجي داخل التطبيق في صفحة عرض منتجاتنا. لقد قمنا بتحسينها عن طريق إضافة زر "إضافة إلى عربة التسوق" ثابت الموضع فقط للتطبيقات:

كان بإمكاننا إضافة زر "إضافة إلى الحقيبة" ثابت الموضع في المتصفح أيضًا ، لكننا لم نفعل ذلك لأن النقر بالقرب من الجزء السفلي في Safari سيفتح في الواقع شريط التنقل في Safari. إن فتح هذا الشريط عن طريق الخطأ عندما يحاول المستخدم إضافة منتج إلى عربة التسوق الخاصة به سيكون عيبًا غير مقبول في قابلية الاستخدام ، على الرغم من مزايا وجود زر "إضافة إلى عربة التسوق" في أسفل الصفحة:

هناك مجال آخر أجرينا فيه تعديلات خاصة بالتطبيق على موقع الويب وهو في عربة التسوق. يعد منطق عربة التسوق عادةً أحد أصعب الجوانب في أي موقع ويب للتجارة الإلكترونية ، ولأننا كنا سعداء تمامًا بتجربة عربة التسوق على الهاتف المحمول ، فقد قررنا إعادة استخدامها في التطبيق ، على الرغم من تعديل الشكل والمظهر قليلاً:

القابلية للمشاركة

تعد القدرة على مشاركة الروابط وفتح الروابط المشتركة ميزة مهمة يجب أن تعمل بشكل جيد مع Beyond the Rack. أردنا أن تكون المشاركة سلسة. إذا شارك شخص ما رابطًا من سطح المكتب الخاص به ، وفتحه صديقه في التطبيق ، فيجب فتح الرابط بشكل صحيح ؛ وبالمثل ، إذا شارك شخص ما منتجًا من التطبيق ، فيجب أن يفتح بشكل صحيح على سطح المكتب ؛ وإذا كان الصديق على الهاتف المحمول ولكن ليس لديه التطبيق مثبتًا ، فيجب أن يفتح في المتصفح. لقد عقدنا العزم على جعل هذه تجربة رائعة لأن هذا شيء عادة ما تكون التطبيقات ضعيفة فيه.

قد يكون من الصعب جعل المحتوى قابلاً للمشاركة بين الويب والتطبيق . للقيام بذلك بنجاح ، ستحتاج إلى تعيين روابط التطبيق وروابط الويب. كان هذا مؤلمًا في أيام الاستجابة المسبقة ، عندما كان فتح عنوان URL لسطح المكتب ينقلك إلى الصفحة الرئيسية لعنوان URL للجوال ، بسبب عمليات إعادة التوجيه وما إلى ذلك. نحن نشهد نفس المشكلة بالضبط اليوم مع التطبيقات - تطلب منك اللافتات في Safari و Chrome فتح رابط في أحد التطبيقات ، فقط حتى لا يُظهر التطبيق ما كنت تبحث عنه ، مما يتركك للبحث عنه مرة أخرى. لحسن الحظ ، يعد التعامل مع روابط الويب في تطبيق Beyond the Rack أمرًا سهلاً ، لأن كل ما نحتاج إليه هو تحميل عنوان URL هذا في عرض ويب. علينا فقط التأكد من أن روابط الويب تنقل المستخدمين إلى التطبيق بدلاً من المتصفح.

على نظام Android ، يعد فتح عنوان URL في التطبيق أمرًا بسيطًا. تحتاج فقط إلى إعداد عامل تصفية الهدف لتحميل التطبيق كلما حاول المستخدم تحميل عنوان URL المحدد (في حالتنا ، www.beyondtherack.com ). بمجرد تثبيت التطبيق ، سيتم منح المستخدمين خيار فتح عنوان URL في التطبيق أو في المتصفح:

كان لنظام iOS طريقًا صعبًا بعض الشيء لتمكين عناوين URL للويب من الفتح مباشرة في التطبيقات. في السابق ، كان نظام iOS يسمح لك فقط بتسجيل مخطط تطبيق لكل تطبيق (على سبيل المثال ، beyondtherack:// ). نظرًا لأنه كان من المستحيل معرفة التطبيقات التي تم تثبيتها ، كان الخيار الوحيد هو فتح رابط معين في Safari ، ومن هناك ، حاول فتح هذا الرابط في التطبيق. جاء هذا مع إزعاج بسيط: إذا لم يكن التطبيق مثبتًا ، فسيتلقى المستخدم رسالة خطأ مزعجة ، "يتعذر على Safari فتح الصفحة لأن العنوان غير صالح". لحسن الحظ ، يسمح لك الاختراق بقمع هذا الخطأ باستخدام إطارات iframe. إذا كنت تريد دعم الارتباط العميق على iOS 8 ، فهذا هو الخيار الأفضل.

لحسن الحظ ، قدم iOS 9 ارتباطًا عالميًا ، والذي يسمح للتطبيقات باعتراض روابط الويب قبل أن تنتقل الروابط عبر Safari. ## قابلية الاكتشاف يعد التوقيت في غاية الأهمية بالنسبة لشركة مثل Beyond the Rack. تقليديا ، كانت الطريقة الأساسية للشركة لإعلام العملاء بالمبيعات من خلال حملات البريد الإلكتروني. ولكن باستخدام التطبيقات ، يمكنه ** التواصل مباشرة مع عملائه بشأن المبيعات ** ، وهو أمر قوي للغاية. (بالطبع ، تصل الإشعارات الفورية ببطء إلى المتصفحات ، حيث يتصدر Chrome المسؤولية] (https://gauntface.com/blog/2014/12/15/push-notifications-service-worker). ولكن بالنسبة لأجهزة Android الأقدم وبالنسبة لنظام iOS ، فقد تم بالفعل اختيار استخدام تقنية أصلية أو تقنية الويب لنا.) تمامًا كما هو الحال مع المشاركة ، جعل قرارنا بالاستفادة من محتوى الويب مباشرة في التطبيق من السهل إعداد ** دفع الإخطارات **. نظرًا لأنه يمكن تحديد كل منتج وعملية بيع من خلال نفس عنوان URL على كل من موقع الويب والتطبيق ، فإن تثقيف المسوقين حول كيفية إرسال الإشعارات إلى عملائهم أمر بسيط - كل ما يحتاجون إليه هو مشاركة نفس عناوين URL التي اعتادوا مشاركتها في حملات البريد الإلكتروني. أحد الاختلافات المثيرة للاهتمام بين iOS و Android هو ** نظام الإذن ** لدفع الإشعارات. في نظام التشغيل iOS ، يتحكم نظام التشغيل في إذن الإشعارات ، بينما لا يلزم الحصول على إذن على نظام Android. ومع ذلك ، شعرنا أن طلب الإذن هو الشيء الصحيح الذي يجب القيام به من منظور خدمة العملاء. لذلك ، عندما يسجل المستخدم الدخول إلى التطبيق لأول مرة ، نسأله عما إذا كان يرغب في الحصول على إشعارات:

قررنا أيضًا إنشاء ** مربعات حوار الإشعارات ** هذه بواجهات الويب. لم يتطلب أي شيء عنها أداءً متقدمًا ، لذلك كان بناءها باستخدام واجهات مستخدم الويب وإعادة استخدامها عبر الأنظمة الأساسية أمرًا منطقيًا. هذا مثال آخر على جعل تطبيق موقع الويب مدركًا: تعد مربعات الحوار هذه جزءًا من موقع الويب ولكنها معروضة بشكل مشروط في التطبيق.

نتائج

بعد إصدار التطبيق ، أردنا مقارنة أدائه بتجربة المتصفح. لم تكن المقارنة المباشرة بين تحليلاتهم كافية ، لأنه من خلال تجربتنا ، من المرجح أن يكون أي شخص قام بتثبيت التطبيق عميلاً أكثر ولاءً ، وبالتالي من المرجح أن يقوم بالتحويل بشكل أفضل. لتجنب تحيز الاختيار ، قمنا بإعداد اختبار A / B ؛ تم الاحتفاظ بنصف المستخدمين في التطبيق والنصف الآخر تم ترحيلهم إلى المتصفح ، مما يضمن أن المشاركين الوحيدين في التجربة هم المستخدمون الذين ثبّتوا التطبيق (المستخدمون الأكثر ولاءً).

• كانت المعاملات لكل زائر فريد أعلى بنسبة 76٪ مع تجربة التطبيق مقارنة بالويب.
• كان المستخدمون الفريدون يوميًا للتطبيق أكثر احتمالية بنسبة 20٪ للتحويل .
• أمضى مستخدمو التطبيق وقتًا أطول في التصفح بنسبة 63٪ مقارنة بمستخدمي الويب .

أداء سريع يفوز

إن إنشاء تطبيق يقوم بتحميل محتوى الويب ويشعر بأنه أصلي لا يأتي من خارج منطقة الجزاء على نظام التشغيل iOS أو Android. فيما يلي بعض تحديات الأداء التي واجهناها والتي تستحق المشاركة:

• في نظام التشغيل iOS ، لا يتوافق زخم التمرير في عرض الويب مع زخم التمرير المطابق في عرض التمرير الأصلي. تم الكشف عن هذا في اختبار المستخدم. إليك سطر واحد لحل ذلك: webview.scrollView.decelerationRate = UIScrollViewDecelerationRateNormal;
• كن حذرًا عند تغيير حجم طرق عرض الويب . واجهنا مشكلات حيث تسبب تغيير حجمها في إعادة طلاء كاملة ، مما أدى إلى توقف أداء التمرير على الأجهزة القديمة.
• قد يكون التعامل مع مئات من تطبيقات عرض الويب المختلفة على Android أمرًا مؤلمًا. المشكلة الأكثر إيلامًا التي واجهتنا هي خطأ عرض الويب المعروف في Android 4.4.2 ، والذي يطرح استثناءً فادحًا في Chromium يتسبب في تعطل التطبيق. إزالة transform: translate3d في إصدار Android هذا تفي بالغرض. بدلاً من ذلك ، يمكنك استخدام Crosswalk لشحن وقت تشغيل الويب المجمع الخاص بك مع تطبيقك (لم نفعل ذلك ، لكننا نخطط لمشاريع مستقبلية).
• استخدم FastClick ، ​​ليس فقط لأنه يزيل تأخير النقر 300 مللي ثانية ، ولكن أيضًا لأنه يصلح خطأ النقر في عرض الويب المقدم في iOS 8.4.1. بالنسبة لنا ، تجلى الخطأ في عدم السماح للصفحة بالتغير إذا كانت النقرة بطيئة جدًا.
• افعل كل ما في وسعك لجعل التمرير يبدو رائعًا. يمكنك رفض أحداث التمرير وتجنب إعادة الطلاء غير الضرورية والمزيد. إذا لم يتم تشغيل التمرير بمعدل 60 إطارًا في الثانية ، فسوف يلاحظ المستخدمون ذلك في تطبيق أكثر من الويب.
• افعل كل ما في وسعك لجعل الصفحات يتم تحميلها في أقل من 1000 مللي ثانية.

أدوات لبناء تطبيق يستفيد من موقع الويب الخاص بك

لديك عدد من الخيارات لبناء تطبيق يستفيد من موقعك الحالي. النهج الذي اتبعناه هو بناء التطبيق الخاص بكل منصة (باستخدام Xcode و Android Studio) ، والاستفادة من طرق عرض الويب أو العروض الأصلية عند الضرورة.

عند تحميل عرض ويب لميزة معينة ، نوصي بدمج عرض الويب الخاص بـ Cordova ، بدلاً من استخدام مكتبات عرض الويب التي يوفرها iOS و Android مباشرةً. سيعطي هذا طرق عرض الويب الخاصة بك عددًا من الميزات التي قد تضطر إلى بناءها بنفسك ، مثل جسر ويب إلى أصلي للتواصل من JavaScript إلى التعليمات البرمجية الأصلية والعكس بالعكس ، والقدرة على الوصول إلى أحداث دورة الحياة ، بالإضافة إلى الوصول لثروة من ملحقات كوردوفا. بدلاً من ذلك ، تتوفر بعض الجسور الأخرى من الويب إلى الأنظمة الأساسية المختلفة إذا كنت تريد تجنب الاعتماد على كوردوفا.

هناك عدد قليل من أطر العمل لمساعدتك في إنشاء التطبيقات بهذه الطريقة ، مثل Supersonic و Astro ، وهو إطار عمل أصلي للتطبيقات نقوم بإنشائه لتسهيل إدارة تعقيد إنشاء التطبيقات باستخدام كل من الواجهات الأصلية وواجهات الويب.

خاتمة

مع Beyond the Rack ، شرعنا في إنشاء تطبيق يمكننا من خلاله بسهولة شحن قيمة للمستخدمين دون التضحية بالتجربة. من خلال اتباع نهج يضع التكنولوجيا في المقعد الخلفي ، ويسمح لنا باستخدام التكنولوجيا المناسبة للمهمة ، نعتقد أننا حققنا ذلك بالضبط. مع أي تغيير أو إدخال لميزة ، نسأل أنفسنا دائمًا ، "ما التجربة التي نريد تصميمها هنا والتي ستحل مشكلة المستخدم بشكل أفضل؟ هل تتطلب هذه التجربة استخدام أداء متقدم أو رسوم متحركة؟ "

ستحدد الإجابة على هذا السؤال ما إذا كنا نبني الميزة باستخدام تقنية الويب ونعيد استخدامها في المتصفح وعلى Android و iOS أو نبنيها بشكل مخصص لكل نظام أساسي.

في النهاية ، أعتقد أن هذه هي الطريقة التي يجب أن تُبنى بها التطبيقات. لكنها ستتخذ تحولًا في العقلية. بدلاً من محاولة تحديد ما إذا كانت الويب ستنتصر على المحتوى الأصلي أو ستصبح من بقايا الماضي ، يجب أن نتبنى أفضل ما في الاثنين. يجب أن ندرك مزايا وعيوب كل منهما واستخدام التكنولوجيا الأكثر منطقية للميزة المعينة.