مقارنة بين HTML5 والإعلانات المدمجة مع المحتوى

الجدل حول التطبيقات المتوافقة مع الأجهزة الجوّالة

مقدمة

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

مستوى توفّر الميزات

وجهة نظر: يمكن أن يؤدي التطبيق الأصلي المزيد من المهام

يمكن تقسيم وظائف الأجهزة الجوّالة إلى بُعدَين: تجربة التطبيق نفسه، والطريقة التي يتكامل بها مع منظومة الجهاز المتكاملة، مثل الميزات المتوفرة على Android، كالأدوات المصغّرة والإشعارات. تتفوق الإعلانات المدمجة في كلا البُعدين.

في ما يتعلق بتجربة التطبيق، يمكن للتطبيقات الأصلية إنجاز المزيد. ويمكنهم بسهولة الحصول على أحداث التمرير السريع والأحداث المتعددة اللمس على المنصات التي تتيح ذلك. ويمكنها عادةً الاستجابة للضغط على المفاتيح المادية، مثل زر البحث وأزرار التحكّم في مستوى الصوت على جهاز Android. ويمكنها أيضًا الوصول إلى الأجهزة، مثل نظام تحديد المواقع العالمي (GPS) والكاميرا. وبإذن المستخدم، تتيح بعض المنصات الوصول غير المقيد إلى نظام التشغيل. ما عليك سوى محاولة رصد مقدار البطارية المتبقي باستخدام HTML5.

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

نقطة مضادة: يمكن تعزيز الميزات الأصلية، كما أنّ الويب يواكب التطورات على أي حال

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

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

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

تتطوّر التطبيقات الأصلية بسرعة، ولكنّ الويب يلحق بها.

الأداء

ميزة: تعمل الإعلانات المدمجة مع المحتوى بشكل أسرع

لا تواجه التطبيقات الأصلية عائق وقت تشغيل الويب. وهي تعمل على مستوى منخفض من التجريد ويمكنها الاستفادة من أدوات تحسين الأداء، مثل تسريع وحدة معالجة الرسومات (GPU) وتعدد مؤشرات الترابط.

وجهة نظر أخرى: أصبحت أوقات تشغيل الويب أسرع بكثير اليوم، ومعظم التطبيقات لا تحتاج إلى هذه السرعة على أي حال

من الواضح أنّ الويب أصبح أسرع في السنوات الأخيرة. كان محرّك V8، وهو محرّك JavaScript المضمّن في Chrome، تطوّرًا كبيرًا في أداء الويب عند إطلاقه، ومنذ ذلك الحين، أصبح أسرع فقط:

الرسم البياني لأداء V8

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

الرسم البياني للوحة العرض المسرَّعة للأجهزة

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

لم تصل كل التحسينات التي تم إجراؤها على أجهزة الكمبيوتر إلى جميع المنصات المتوافقة مع الأجهزة الجوّالة بعد، ولكن تشير المؤشرات إلى أنّها في طريقها إلى ذلك. من المهم أيضًا ملاحظة أنّ معظم تطبيقات الأجهزة الجوّالة ليست ألعابًا ثلاثية الأبعاد متطورة، بل هي بشكل أساسي تطبيقات تعتمد على المعلومات، مثل الأخبار والبريد والجداول الزمنية والشبكات الاجتماعية وما إلى ذلك. يمكنك الانتقال إلى بعض المواقع الإلكترونية من جهازك الجوّال، مثل Gmail وAmazon وTwitter، والتأكّد من أنّ أداء الويب على الأجهزة الجوّالة أكثر من كافٍ. أما بالنسبة إلى الألعاب، فإنّ الألعاب الأساسية متاحة حاليًا باستخدام لوحة الرسم الثنائية الأبعاد، وبدأت تقنية WebGL في الظهور على الأجهزة الجوّالة، كما هو الحال في Firefox 4. إلى أن يصبح WebGL متاحًا على نطاق واسع، هناك مجموعة متزايدة من الأُطر التي تترجم تطبيقات WebGL إلى تطبيقات أصلية يمكنها الاستفادة من OpenGL، مثل ImpactJS.

تجربة المطوّرين

نقطة: التطبيقات الأصلية أسهل في التطوير

تستخدم التطبيقات الأصلية لغات برمجة قوية (مثل Java وObjective C وC++) مصمَّمة لتطوير التطبيقات المعقّدة، كما أنّها حققت نتائج جيدة. تم تصميم واجهات برمجة التطبيقات من البداية لتتوافق مع المنصة المعنية. يمكنك تصحيح أخطاء التطبيقات بسهولة في المحاكيات على أجهزة الكمبيوتر التي توفّر تمثيلاً دقيقًا لجهاز الاختبار.

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

وجهة نظر أخرى: غالبًا ما يكون تطوير الويب أسهل، خاصةً إذا كنت تستهدف أجهزة متعددة

لنبدأ بالتقنيات الأساسية. صحيح أنّ معايير الويب تم وضعها في الأصل في عصر كان فيه الويب يركّز بشكل أساسي على المستندات وليس التطبيقات، وتم إنشاء JavaScript ونشرها في 10 أيام فقط. ولكن تبيّن أنّها أكثر قدرة مما كان متوقعًا، فقد تعلّم مطوّرو الويب كيفية الاستفادة من الأجزاء الجيدة والتعامل مع الأجزاء السيئة، وأصبحت الأنماط مفهومة الآن للتصميم القابل للتوسيع. علاوةً على ذلك، تتطوّر المعايير باستمرار، وتساهم جهود مثل HTML5 وCSS3 وEcmaScript Harmony في تحسين تجربة المطوّرين. إنّ اختيار C++‎ أو Java أو JavaScript هو موضوع نقاش ديني، ويعتمد أيضًا على قاعدة الرموز البرمجية القديمة. لكن يمكننا بالتأكيد اعتبار JavaScript منافسًا قويًا في الوقت الحالي.

الجانب الآخر من مشكلة تجزئة المتصفّحات/وقت التشغيل هو أنّ كل هذه البيئات موجودة في المقام الأول. إذا كنت بصدد تطوير تطبيق Android باستخدام Java، عليك نقل التطبيق بالكامل إلى Objective C ليكون متوافقًا مع iOS. يمكنك تطوير تطبيق ويب مرة واحدة وسيعمل على Android وiOS، بالإضافة إلى WebOS وBlackBerry وWindows Mobile و… حسنًا، هذه هي النظرية على أي حال. في الواقع، ستحتاج إلى إجراء تعديلات على كل منصة إذا كنت تريد تقديم تجربة مناسبة. ولكن عليك إجراء ذلك في التطبيق الأصلي أيضًا، وذلك بالنسبة إلى معظم أنظمة تشغيل الأجهزة الجوّالة، لأنّ هناك إصدارات وأجهزة مختلفة.

الخبر السار هو أنّ "التجزئة" كانت دائمًا على هذا النحو على الويب، وهناك تقنيات معروفة للتعامل معها. الأهم من ذلك، أنّ مبدأ التحسين التدريجي يحثّ المطوّرين على استهداف جهاز أساسي أولاً، ثم إضافة طبقات من الميزات الرائعة الخاصة بالمنصة حيثما تكون متاحة. تساعد أيضًا فكرة رصد الميزات، وتتوفّر حاليًا مكتبات مثل Modernizr لدعم تصميم الويب السريع الاستجابة. ومن خلال الاستخدام الحكيم لهذه الأساليب، يمكنك توسيع نطاق وصولك إلى الغالبية العظمى من الأجهزة، بما في ذلك "الهواتف العادية" القديمة، وحتى أشكال الأجهزة مثل الساعات وأجهزة التلفزيون، بغض النظر عن العلامة التجارية ونظام التشغيل. شاهد عرضنا التوضيحي لواجهات المستخدم المتعددة في مؤتمر Google IO 2011، حيث استهدفنا أشكالاً مختلفة (هاتف عادي وهاتف ذكي وجهاز لوحي وكمبيوتر مكتبي وتلفزيون) باستخدام قاعدة رموز مشتركة للمنطق والترميز.

Look-And-Feel

نقطة: تتوافق الإعلانات المدمجة مع شكل النظام الأساسي ومظهره

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

علاوةً على ذلك، يتم تنسيق شكل النظام الأساسي وأسلوبه من خلال مكتبة البرامج الأصلية للنظام الأساسي، والتي تتضمّن أدوات مصغّرة تجسّد الشكل والأسلوب اللذين يتوقّعهما المستخدمون. يمكنك الحصول على الكثير من المظهر المتوقّع "مجانًا" من خلال استخدام مجموعة الأدوات الأصلية.

وجهة نظر أخرى: يتميّز الويب بمظهره الخاص، ويمكنك أيضًا تخصيص واجهة الويب للمنصات الأكثر أهمية بالنسبة إليك

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

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

سهولة العثور على المحتوى

نقطة: يسهل العثور على التطبيقات الأصلية

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

وجهة نظر مخالفة: في الواقع، من الأسهل العثور على تطبيقات الويب

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

لا تتوفّر لدينا حاليًا أسواق مماثلة يمكن للمستخدمين فيها تقييم التطبيقات والتعليق عليها، ولكنّنا نعمل على تغيير ذلك أيضًا. قراءة المزيد…

تحقيق الربح

النقطة: يمكن تحقيق الربح من الإعلانات المدمجة مع المحتوى

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

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

وجهة نظر مخالفة: لطالما كان من الممكن تحقيق الربح على الويب، وتتزايد الفرص المتاحة

ما كان ليصبح الويب محرك الصناعة الحديثة لولا الفرص الكثيرة المتاحة لتحقيق الربح. على الرغم من أنّ آليات "الدفع مقابل الاستخدام" المباشر لم تزدهر بعد، هناك العديد من المجالات المتخصّصة التي أصبحت فيها حلول "البرامج كخدمة" المستندة إلى الاشتراك مجدية بالفعل. وتشمل الأمثلة Google Apps ومجموعة منتجات 37Signals والإصدارات المدفوعة من خدمات البريد الإلكتروني المختلفة. بالإضافة إلى ذلك، لا تُعدّ الدفعات المباشرة الطريقة الوحيدة للاستفادة من تطبيقات الويب. هناك الإعلانات على الإنترنت، وروابط الشركاء التابعين، والرعاية، والترويج المتبادل لمنتجات وخدمات أخرى.

مع ذلك، من المنطقي تمامًا أن يقرأ مطوِّر على الويب العناوين الرئيسية ويشعر ببعض الحسد تجاه هذه الأرباح. لا يمكنك إرسال عنوان URL لموقع إلكتروني إلى الأسواق الأصلية، فماذا يمكن لمطوّر الويب أن يفعل؟ ما عليك فعله هو إنشاء "تطبيق غلاف" أصلي لكل نظام أساسي تريد استهدافه، أي إنشاء تطبيق أصلي فارغ يحتوي ببساطة على عرض ويب. في عرض الويب، يمكنك تضمين التطبيق الحقيقي، ثم إرسال هذه التطبيقات إلى الأسواق المختلفة (ونأمل أن تبدأ الأرباح في التدفق!). من المحتمل أن يكون هناك مئات، إن لم يكن آلاف، من التطبيقات المستندة إلى الويب في الأسواق الرئيسية اليوم، وبعضها تم دمجه بذكاء لدرجة أنّنا لا نعرف حتى تطبيقات الويب الخاصة بها على الإطلاق.

أما الجانب السلبي، فيتمثل في عبء الترجمة البرمجية إلى كل منصة. هنا يأتي دور إطار عمل حالي، مثل PhoneGap. والأفضل من ذلك، أنّ هناك خدمات ويب مثل PhoneGap Build وApparatio قيد التطوير. وجِّه هذه المواقع الإلكترونية إلى مستودع الرموز البرمجية، وسيظهر لك تطبيق Android وتطبيق iOS وغير ذلك، وكلها جاهزة لإرسالها إلى المتاجر المعنية. لم يكن عليك تثبيت حِزم تطوير البرامج (SDK) الأصلية على جهازك، بل كان كل ما تحتاجه لإنشاء كل هذه التطبيقات الأصلية هو أداة تعديل الرموز وبرنامج تصفّح ويب.

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

الاستنتاجات

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

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

إذا اخترت مسار الويب، عليك مراعاة معايير الويب ومبدأ التحسين التدريجي. الويب هو تكنولوجيا تعرف كيف تستهدف العديد من الأجهزة وأنظمة التشغيل المتاحة. سواء اخترت تسمية ذلك "تجزئة" أو "تنوّع"، فإنّ الويب يتقبّل ذلك ويمكن للمطوّرين الاستفادة من كل معلومات اختراع سابق.