ما المتصفح داخل التطبيق، وكيف يعمل؟

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

تعمل المتصفحات داخل التطبيقات باستخدام مكوّن عرض ويب يوفره نظام التشغيل وتستخدمه شيفرة التطبيق، ويستطيع عرض HTML و CSS و JavaScript تمامًا كمتصفح الويب العادي. ويقوم المكوّن على التقنية نفسها التي تشغّل المتصفحات الكبرى، مثل WebKit في iOS أو محرك Blink من Chromium في Android، ما يضمن التوافق والأداء.

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

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

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

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

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

من المهم أن يتمكن المستخدم من رؤية عنوان الصفحة المعروضة و حالة HTTPS الخاصة بها حتى يمكن التعرف على الصفحات المزيفة. ولا ينبغي أن تتم عمليات تسجيل الدخول لدى أطراف ثالثة، مثل الدخول عبر Google أو Apple، في عرض ويب مضمّن يستطيع فيه التطبيق تقنيًا قراءة ما يُكتب. ولهذا الغرض، يُوصى بمتصفح النظام أو بحلول مثل ASWebAuthenticationSession و Custom Tabs.

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

يمكن تحسين أداء المتصفح داخل التطبيق باستخدام مكونات النظام، مثل Custom Tabs في Android و SFSafariViewController في iOS، التي تحسّنها المنصات. ويمكن لـ Custom Tabs تهيئة المتصفح مسبقًا وتحميل صفحة يُرجَّح أن يفتحها المستخدم مسبقًا حتى تظهر بشكل أسرع.

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

WebView مكوّن يعرض محتوى الويب مباشرة داخل واجهة مستخدم التطبيق نفسه. ويملك المطور تحكمًا كاملًا في العرض ويستطيع التواصل بين محتوى الويب والتطبيق، لكن WebView لا يشارك عادةً ملفات تعريف الارتباط وعمليات تسجيل الدخول مع متصفح المستخدم. وفي iOS، يُسمى المكوّن المكافئ WKWebView.

أما SFSafariViewController في iOS و Custom Tabs في Android فيفتحان بدلًا من ذلك متصفح النظام فوق التطبيق. وتشارك Custom Tabs عمليات تسجيل الدخول وملفات تعريف الارتباط مع Chrome أو المتصفح الافتراضي، بينما يشارك SFSafariViewController الملء التلقائي وكلمات المرور المحفوظة مع Safari، لكنه يحتفظ منذ iOS 11 بملفات تعريف الارتباط الخاصة به منفصلة. ويعرض كلاهما العنوان ويمنح المستخدم ميزات الأمان المألوفة. وفي المقابل، يكون تحكم التطبيق أقل. وكثيرًا ما يُوصى بهذه الحلول لعرض الصفحات الخارجية.