تطبيقات الويب التقدمية: متى تتفوق على الأصلي

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

كلاهما خاطئ اليوم، وبطريقة تغيّر الحساب. يدعم Safari إشعارات الدفع في تطبيقات الويب المضافة إلى الشاشة الرئيسية منذ iOS 16.4. وتخلى Chrome عن اشتراط وجود service worker للتثبيت. وفي أكتوبر 2025 صنّفت الجهة التنظيمية البريطانية Apple وGoogle بأنهما تتمتعان بوضع سوقي استراتيجي على متصفحاتهما ومحركات متصفحاتهما للهواتف. وفي الوقت نفسه ما زال iOS يرفض التنفيذ في الخلفية، ويخلي البيانات المخزنة وفق قواعد لا تتحكم بها، ولن يدرج تطبيق ويب في App Store أبداً.

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

متى يتفوق تطبيق الويب التقدمي على التطبيق الأصلي؟ حين يكون مستخدموك على أندرويد وسطح المكتب بقدر ما هم على iPhone، وحين يكون التطبيق واجهة لخادم لا للجهاز، وحين يجدك الناس عبر البحث لا عبر متجر. ويخسر تطبيق الويب التقدمي حين تحتاج إلى تتبع الموقع في الخلفية، أو أدوات على الشاشة الرئيسية، أو Bluetooth على iPhone، أو الفوترة عبر المتجر. التوفير هو قاعدة كود واحدة بدل ثلاث، أي بالمقاييس البريطانية نحو £40,000 إلى £120,000 من كلفة البناء وفاتورة أصغر بوضوح كل عام بعد ذلك.

ما هو تطبيق الويب التقدمي فعلياً

يُستخدم المصطلح بمرونة تكفي لأن يقصد شخصان في الاجتماع نفسه أمرين مختلفين. التعريف التقني ضيق ويستحق التمسك به.

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

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

ملف بيان تطبيق الويب

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

الـ service worker

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

HTTPS

الـ service workers والدفع وتحديد الموقع والوصول إلى الكاميرا كلها مقصورة على السياقات الآمنة. وعلى الاستضافة الحديثة هذا مجاني وتلقائي، فهو قيد لا تكلفة.

ماذا يعني مثبَّت، منصة بمنصة

يفترض المشترون أن التثبيت سلوك واحد. إنه ثلاثة سلوكيات، والفروق بينها ذات أثر تجاري.

أندرويد

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

iOS و iPadOS

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

سطح المكتب

يثبّت Chrome وEdge وSafari على macOS تطبيقات الويب في الشريط أو شريط المهام بنافذة خاصة بها. سطح المكتب هو المكان الذي تكون فيه تطبيقات الويب التقدمية أقل إثارة للجدل وأكثر إهمالاً، خصوصاً في الأدوات الداخلية حيث البديل بناء Electron لا يريد أحد صيانته.

غيّر Chrome قواعد قابلية التثبيت ولم تنتبه معظم الأدلة

لسنوات كرر كل مقال القائمة نفسها: ملف بيان وأيقونات وHTTPS وservice worker يتضمن معالج fetch. هذا البند الأخير لم يعد صحيحاً لمسار التثبيت من القائمة.

فقد أزالت Google اشتراط service worker ينفذ fetch للتثبيت من القائمة، في الإصدار 108 على الهاتف و112 على سطح المكتب، وصارت توفر صفحة افتراضية للعمل دون اتصال للمواقع التي لا تقدم صفحتها الخاصة. ما زالت خوارزمية دعوة التثبيت تريد معالج fetch، لكن قابلية التثبيت نفسها لم تعد تعتمد عليه.

وامتد الأثر إلى الأدوات. فقد أزالت Lighthouse فئة تطبيقات الويب التقدمية كلياً في الإصدار 12.0.0 الصادر في أبريل 2024، لأن تلك الفحوص وُجدت لاختبار معايير لم تعد سارية. وإذا كان خط البناء لديك ما زال يفشل عند غياب درجة PWA فهو يختبر شيئاً تقاعدت عنه Google.

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

العمل دون اتصال قرار تصميمي له تكلفة

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

استراتيجيات التخزين المؤقت

يتلخص التخزين المؤقت في الـ service worker في أربعة أنماط وقرار لكل نوع مورد. يقدّم cache first النسخة المخزنة ولا يتحقق أبداً، وهو الصحيح للخطوط ولملفات البناء ذات البصمة. ويجرب network first الخادم ثم يتراجع، وهو يناسب البيانات التي يجب أن تكون حديثة. ويقدّم stale while revalidate النسخة المخزنة فوراً ويحدّثها في الخلفية، وهو الخيار المعتاد للمحتوى. ويُستخدم network only لكل ما لا يجوز الرد عليه من نسخة قديمة، مثل المدفوعات.

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

المزامنة في الخلفية

صفّ عمليات الكتابة أثناء انقطاع الاتصال وتفريغها عند عودته هو غرض Background Synchronization API. ويدرجها MDN بأنها محدودة التوفر وليست ضمن Baseline صراحةً، ما يعني أنها لا تعمل في بعض أكثر المتصفحات استخداماً.

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

إشعارات الدفع تحسم من المشاريع أكثر من أي شيء آخر

إن كانت قدرة واحدة تُغرق مقترح تطبيق ويب تقدمي فهي هذه، وعادةً بناءً على وقائع كانت صحيحة في 2022.

أندرويد وسطح المكتب

يعمل الدفع عبر الويب على Chrome في أندرويد وChrome على سطح المكتب وEdge وFirefox منذ سنوات عبر تعاون Push API وNotifications API وservice worker. ويتولى خدمة الدفع الخاصة بمنتج المتصفح مهمة التسليم، والإذن طلب قياسي، ولا توجد فجوة تُذكر أمام تطبيق أصلي في الحالة الشائعة التي يرسل فيها خادم رسالة إلى مستخدم مشترك.

iOS و iPadOS

أضافت Apple الدفع عبر الويب في iOS وiPadOS 16.4. والشرط المرتبط به هو الجزء الذي يغفل عنه الناس: يذكر WebKit أن تطبيق الويب يجب أن يكون مضافاً إلى الشاشة الرئيسية، وأن الإذن يجب أن يُطلب استجابةً لتفاعل مباشر من المستخدم مثل النقر على زر اشتراك. ولا يعمل الدفع عبر الويب لموقع قائم في تبويب Safari.

ويجب أن يضبط ملف البيان القيمة display على standalone أو fullscreen، وعندها تتصرف الإشعارات كإشعارات أي تطبيق آخر: شاشة القفل ومركز الإشعارات وساعة Apple Watch المقترنة والتحكم لكل تطبيق في الإعدادات. وتعمل الشارات أيضاً.

ثم أضافت Apple مساراً أبسط. وصل Declarative Web Push في Safari 18.4، وهو متاح على iOS وiPadOS 18.4 لتطبيقات الويب المضافة إلى الشاشة الرئيسية، ويعرض إشعاراً من حمولة JSON موحّدة دون حاجة إلى تشغيل service worker. إنه يقلل العمل. لكنه لا يلغي شرط الشاشة الرئيسية.

فجوة iOS، بصياغة دقيقة

الفجوة حقيقية وهي أصغر من سمعتها. وصياغتها بدقة أنفع من التذمر منها أو التظاهر بأنها أُغلقت.

إخلاء البيانات المخزنة

يخلي WebKit بيانات المواقع على أساس الأقل استخداماً حديثاً، حيث يُقاس آخر استخدام من آخر تفاعل للمستخدم أو عملية تخزين. وتوثيق سياسة التخزين لديه يحدد حصة لكل أصل تصل إلى 60% من القرص لتطبيقات التصفح وإلى 15% للتطبيقات الأخرى، مع حصص إجمالية تبلغ 80% و20% على الترتيب، ويؤكد أن تطبيق ويب مستقلاً على الشاشة الرئيسية ينال الحصص نفسها التي ينالها المتصفح.

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

التنفيذ في الخلفية

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

لا وجود في App Store

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

محركات المتصفحات وقانون الأسواق الرقمية وهيئة المنافسة البريطانية

هذا هو الجزء الذي تسبق فيه التغطية الصحفية المصادر الأولية، لذا يجدر التمسك بما هو موثق فعلاً.

تسمح Apple الآن بمحركات متصفحات بديلة، وهي تنص صراحةً على أن هذا ينطبق في الاتحاد الأوروبي وحده، على iOS 17.4 أو أحدث وiPadOS 18 أو أحدث، عبر تصريحين يُمنحان للمطورين الذين يستوفون معايير منشورة للأمان والخصوصية وحزم الاختبار. وتشترط Apple اجتياز 90% من Web Platform Tests و80% من Test262، والتشغيل من دون JIT، ومعالجة معظم الثغرات خلال 30 يوماً.

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

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

العتاد وواجهات الأجهزة، متحققاً منها لا مفترضة

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

ما يعمل في كل مكان تقريباً

الوصول إلى الكاميرا والميكروفون عبر getUserMedia مصنّف Baseline على MDN ويعمل عبر المتصفحات منذ 2017. وتحديد الموقع، واتجاه الجهاز، ورفع الملفات بما فيه التقاط الصور بالكاميرا على الهاتف، والوصول إلى الحافظة، وWeb Share API على الهاتف، ومفاتيح المرور عبر WebAuthn مع Face ID أو بصمة الإصبع كمصادِق، كلها تعمل في المتصفحات المحمولة الحالية. وقراءة الباركود ورموز QR من تدفق الكاميرا أمر روتيني.

وبالنسبة إلى الغالبية العظمى من تطبيقات الأعمال، تلك القائمة هي كامل متطلبات العتاد.

ما يقتصر على Chromium، وعلى الهاتف على أندرويد فعلياً

توثّق Google أن Web Bluetooth متاح على ChromeOS وChrome لأندرويد 6.0 وmacOS من Chrome 56 وWindows 10 من Chrome 70، من دون ذكر دعم iOS، ويصنفه MDN بأنه محدود التوفر لا Baseline. أما Web NFC فأضيق: توثّقه Google بأنه متاح على أندرويد في Chrome 89.

وواجهة File System Access API لقراءة الملفات التي يختارها المستخدم والكتابة فيها هي كذلك أرض Chromium، رغم أن origin private file system يغطي معظم احتياجات التخزين الداخلي للتطبيق عبر المتصفحات.

التوزيع عبر المتاجر مسألة تجارية لا تقنية

تتجادل الفرق حول التوزيع عبر المتاجر وكأن المسألة قدرة تقنية. المسألة أربعة متغيرات تجارية، وواحد منها فقط يرجّح كفة المتجر بلا لبس.

الاكتشاف هو الميزة الصادقة. فالمستهلكون يبحثون فعلاً في App Store وفي Play بالعلامة وبالفئة، والشركة التي لا حضور لها في المتاجر تتنازل عن تلك القناة. وهذا يهم كثيراً لمنتج استهلاكي باسم معروف، ويهم قليلاً جداً لأداة يستخدمها 200 موظف في شركة واحدة.

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

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

ما تتقاضاه المتاجر فعلياً

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

تتقاضى Apple 30% كعمولة قياسية على السلع والخدمات الرقمية. وبرنامج App Store Small Business Program يخفض ذلك إلى 15% للمطورين الذين تصل عائداتهم إلى 1,000,000 دولار أمريكي في السنة التقويمية السابقة، مع أهلية المطورين الجدد، وعودة النسبة القياسية على المبيعات المقبلة متى تجاوزت العتبة خلال سنة.

وتنشر Google رسم خدمة متدرجاً لـ Google Play: 15% على أول مليون دولار أمريكي من إيراد المطور كل سنة، و30% فوق ذلك، و15% على الاشتراكات ذاتية التجديد بصرف النظر عن الإيراد. وتعرض الصفحة نفسها بنية مختلفة تسري اعتباراً من 30 يونيو 2026 في المنطقة الاقتصادية الأوروبية والمملكة المتحدة والولايات المتحدة، تقوم على 10% أو 20% إضافةً إلى رسم فوترة قدره 5%، بحسب ما إذا كان التثبيت جديداً أم قائماً.

وكلا المزوّدين ينشر بالدولار الأمريكي. وبيع اشتراك شهري بـ £9.99 عبر متجر يكلف نحو £18 سنوياً لكل مشترك عند 15% ونحو £36 عند 30%. اضرب ذلك في عدد مشتركيك قبل أن تعتبر المتجر مجانياً.

ما زال بإمكانك نشر تطبيق ويب تقدمي عبر Google Play

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

الـ Trusted Web Activity تطبيق أندرويد يفتح تطبيق الويب التقدمي الخاص بك بملء الشاشة بلا إطار متصفح، ومتحقق من ملكيتك له عبر Digital Asset Links. ويتطلب Chrome على أندرويد 72 أو أحدث، ولا يملك التطبيق المضيف أي وصول إلى ملفات تعريف الارتباط أو تخزين محتوى الويب. وهو عملياً غلاف رقيق يُولَّد من ملف البيان لديك ويُقدَّم إلى Play كأي تطبيق آخر.

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

ولا مقابل لذلك على iOS. فإرشادات المراجعة لدى Apple تعامل منذ زمن الغلاف حول موقع بأنه غير كافٍ بذاته، وبالتالي فمسار متجر iOS يعني بناء شيء أصلي فعلاً. وهذا اللاتماثل، أكثر من أي فجوة في الواجهات، هو ما يشكّل جدول التكاليف أدناه.

تكلفة تطوير تطبيق ويب تقدمي مقابل قاعدتي كود أصليتين

المقارنة التي يجريها الناس هي تكلفة البناء، وهي النصف الأصغر. أما المقارنة التي تحسم النتيجة فهي التكلفة الإجمالية على ثلاث سنوات، لأن نفقة الأصلي متكررة.

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

الفارق بين الصف الأول والثالث، أي نحو £75,000 إلى £175,000 في البناء و£27,000 إلى £60,000 سنوياً بعده، هو ما تشتريه حين تشتري الأصلي. وأحياناً يكون ذلك مالاً في محله. لكن ينبغي أن يكون قراراً لا وضعاً افتراضياً. وصفحتا تطوير المواقع وتطوير البرمجيات لدينا تبينان كيف نحدد نطاق المسارين.

أين تذهب أموال الصيانة فعلياً

تكلفة البناء يجري التفاوض عليها. أما تكلفة الصيانة فتُكتشف، وهناك تفشل المشاريع متعددة قواعد الكود بصمت لا بضجيج.

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

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

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

المقارنة التي تهم ليست رقمين في عرض سعر. إنها فريق واحد مقابل ثلاثة، كل سنة، ما دام المنتج حياً.

الأداء و Core Web Vitals لتطبيق الويب التقدمي

يُحاكم التطبيق المثبَّت أمام الأصلي، فسقف الأداء أعلى مما هو لموقع لا أدنى. والخبر الجيد أن المقاييس معلنة والعتبات ثابتة.

تتألف Core Web Vitals حالياً من ثلاثة مقاييس، يُقيَّم كل منها عند المئين 75 من تحميلات الصفحة ويُفصل بين الهاتف وسطح المكتب. فـ Largest Contentful Paint جيد عند 2.5 ثانية أو أقل وضعيف فوق 4.0. وInteraction to Next Paint، الذي حل محل First Input Delay حين استقر في 2024، جيد عند 200 مللي ثانية أو أقل وضعيف فوق 500. وCumulative Layout Shift جيد عند 0.1 أو أقل وضعيف فوق 0.25.

ولتطبيق الويب التقدمي هنا ميزة بنيوية. فـ service worker يقدّم القشرة من الذاكرة المؤقتة يجعل الزيارات المتكررة شبه فورية، وهو تحديداً النمط الذي ينتجه تطبيق مثبَّت، لذا تبدو بيانات المستخدمين الحقيقية لتطبيق ويب تقدمي مثبَّت أفضل عادةً من الكود نفسه عند زيارته بارداً في المتصفح.

وله كذلك مخاطرة بنيوية. فأطر الصفحة الواحدة تدفع العمل نحو العميل، وINP هو المقياس الذي يعاقب ذلك. وإذا كنت تصارع هذه الأرقام أصلاً، فدليلنا حول اجتياز Core Web Vitals يتناول التشخيص بعمق أكبر مما يتسع له هذا المقال.

تحسين محركات البحث هو الميزة التي لا يحسبها أحد

هذه هي الحجة التي أضعها أولاً في معظم الحالات التجارية، وهي تُترك خارج المقارنة كلياً في الغالب.

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

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

ولا يؤتي ذلك ثماره إلا إذا كان التنفيذ قابلاً للزحف، وهنا تخطئ التطبيقات المعروضة على العميل: فعرض كل شيء بـ JavaScript بعنوان واحد وبلا HTML مولَّد من الخادم يفرّط بالميزة كلياً. والحل هو العرض من الخادم أو العرض المسبق للمسارات القابلة للفهرسة، وتدقيق SEO تقني قبل الإطلاق أرخص بكثير من اكتشاف أن شيئاً لم يُفهرس بعد ستة أشهر.

المتطلبات المُقصية

القرار أسهل بوصفه قائمة اعتراضات لا قائمة منافع، لأن الاعتراضات موضوعية.

أنت بحاجة إلى الأصلي إذا كان أي مما يلي متطلباً حقيقياً لا أمنية. تتبع الموقع في الخلفية والتطبيق مغلق. أدوات على الشاشة الرئيسية، أو تطبيقات للساعة، أو التكامل مع CarPlay وAndroid Auto. Bluetooth أو NFC على iPhone. HealthKit أو Apple Pay داخل التطبيق أو أي تكامل عميق مع نظام التشغيل لم تفتحه Apple للويب. الفوترة عبر المتجر للسلع الرقمية حيث تفرضها سياسة المتجر. الحساب الثقيل المستمر، مثل معالجة الفيديو الآنية أو عرض ثلاثي الأبعاد بمعدلات إطارات أصلية. الوجود في App Store كمتطلب تسويقي يعتمد عليه عملك فعلاً.

فإن لم ينطبق أي من ذلك، فتطبيق الويب التقدمي هو الجواب الصحيح على الأرجح، وعبء الإثبات يقع على من يريد ثلاث قواعد كود.

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

السيناريو الأول: خدمة ميدانية لمقاول مرافق

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

كل متطلب مغطى. الكاميرا تعمل عبر getUserMedia. والتواقيع عنصر canvas. وبيانات المهام تُخزَّن مؤقتاً في IndexedDB وصف الكتابة يُفرَّغ عند عودة الاتصال، مكتوباً يدوياً لأن Background Sync غير موثوق عبر المتصفحات. وتنبيهات التوزيع تخرج دفعاً عبر الويب، وهو يعمل على أندرويد وعلى iOS للفنيين الذين أضافوا التطبيق إلى شاشتهم الرئيسية، والتثبيت بند من خمس دقائق في التدريب التمهيدي لا مشكلة اكتساب مستخدمين.

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

ابنِ تطبيق ويب تقدمياً واحداً بنحو £45,000 إلى £70,000 بدل تطبيقين أصليين بـ £120,000 إلى £200,000، وأطلق الإصلاحات في بعد الظهر نفسه بدل المرور بمراجعة، وأنفق الفارق على خلفية نظام التوزيع التي تحدد فعلاً ما إذا كان الأمر ينجح.

السيناريو الثاني: سلسلة صالونات تريد الحجوزات والتذكيرات

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

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

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

ابنِ موقع الحجز كما ينبغي، واجعله قابلاً للتثبيت كي تحتفظ به الزبونات المنتظمات على شاشتهن الرئيسية، وأضف الدفع عبر الويب للأقلية التي توافق. فالبناء الأصلي هنا ينفق £80,000 أو أكثر ليصل إلى عملاء أقل مما يصل إليهم الموقع أصلاً.

السيناريو الثالث: منتج لياقة بالاشتراك

تمارين موجهة، ومحتوى فيديو، وتكامل مع جهاز يُرتدى، و£12.99 شهرياً، وبيع مباشر للمستهلك، ونمو ممول بالاكتساب المدفوع. هذا السيناريو يسير في الاتجاه الآخر، ويستحق بيان السبب.

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

الفوترة هي الجزء المثير. فعمولة المتجر على £12.99 شهرياً تعادل نحو £23 سنوياً لكل مشترك عند 15% و£47 عند 30%، وهو ما يبلغ عند 20,000 مشترك من £460,000 إلى £940,000 سنوياً. وهذه حجة قوية لتحصيل الدفع على الويب ومعاملة التطبيق كعميل، وهو ما تفعله اليوم عدة منتجات اشتراك كبيرة.

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

كيف تقرر في فترة بعد الظهر

القرار لا يحتاج إلى مرحلة استكشاف. يحتاج إلى أربع إجابات مكتوبة.

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

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

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

أين يضعك هذا

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

فجوات iOS حقيقية ومحددة وقابلة للالتفاف في معظمها لا قاتلة. الدفع يعمل إذا ثبّت المستخدم. والتخزين سخي لكنه قابل للإخلاء. والتنفيذ في الخلفية غير موجود ومكانه خادمك على أي حال. وBluetooth وNFC لا يعملان على iPhone، ولا يغير ذلك أي قدر من الهندسة.

تبني Mecanik المسارين وستخبرك متى يكون الجواب الأصلي. وإن أردت المقارنة محسوبة على متطلباتك الفعلية لا على قائمة عامة، فصفحتا تطوير المواقع وتطوير البرمجيات تصفان كيف نحدد النطاق، ودليلنا حول بناء تطبيق ويب في 2026 يتناول قرارات حزمة التقنيات التي تلي ذلك.

الأسئلة الشائعة

ما هو تطبيق الويب التقدمي؟ تطبيق الويب التقدمي تطبيق مبني بتقنيات الويب يتصرف كتطبيق مخصص للمنصة. تقنياً هو تطبيق ويب يُقدَّم عبر HTTPS مع ملف بيان يصف اسمه وأيقوناته وسلوكه عند الإطلاق، إضافةً إلى service worker يستطيع الرد على الطلبات من ذاكرة تخزين مؤقت واستقبال رسائل الدفع. ويعرّفه MDN بأنه برنامج يعمل على منصات متعددة من قاعدة كود واحدة مع بقائه قابلاً للتثبيت وقادراً على العمل دون اتصال.

هل يستطيع تطبيق الويب التقدمي إرسال إشعارات دفع على iPhone؟ نعم، بشرط واحد. أضافت Apple الدفع عبر الويب في iOS وiPadOS 16.4، لكن WebKit يشترط أن يكون تطبيق الويب قد أُضيف إلى الشاشة الرئيسية أولاً، وأن يُطلب الإذن استجابةً لتفاعل مباشر من المستخدم مثل النقر على زر اشتراك. ولا يعمل الدفع لموقع يعمل في تبويب Safari. أما Declarative Web Push المضاف في iOS وiPadOS 18.4 فيبسّط التنفيذ لكنه يبقي شرط الشاشة الرئيسية نفسه.

كم تبلغ تكلفة تطوير تطبيق ويب تقدمي في المملكة المتحدة؟ لتطبيق أعمال متوسط التعقيد توقع £35,000 إلى £75,000 لبناء قاعدة كود واحدة لتطبيق ويب تقدمي و£8,000 إلى £20,000 سنوياً لصيانته. أما المسار الأصلي المقابل، بتطبيقي iOS وأندرويد منفصلين مع موقع تعريفي، فيتراوح بين £110,000 و£250,000 للبناء و£35,000 إلى £80,000 سنوياً بعده. وهذه نطاقات وكالات بريطانية لا عروض أسعار، والفارق المتكرر يهم عادةً أكثر من فارق البناء.

هل يمكن وضع تطبيق ويب تقدمي في App Store أو Google Play؟ في Google Play نعم، وفي App Store لا. فعلى أندرويد تغلّف Trusted Web Activity تطبيق الويب التقدمي في قشرة أصلية رقيقة يجري التحقق منها عبر Digital Asset Links، فتحصل قاعدة الكود نفسها على صفحة في Play مقابل بضعة أيام من عمل التغليف. ولا مقابل لذلك لدى Apple، وإرشادات المراجعة لديها تعتبر الغلاف حول موقع غير كافٍ، فالوجود في App Store يعني بناء شيء أصلي فعلاً.

متى ينبغي اختيار تطبيق أصلي بدل تطبيق ويب تقدمي؟ اختر الأصلي حين تحتاج إلى تتبع الموقع في الخلفية والتطبيق مغلق، أو أدوات على الشاشة الرئيسية، أو تكاملات مع الساعة أو السيارة، أو Bluetooth أو NFC على iPhone، أو HealthKit أو Apple Pay داخل التطبيق، أو حساباً ثقيلاً مستمراً مثل معالجة الفيديو الآنية، أو الوجود في App Store كقناة اكتساب حقيقية. فإن لم ينطبق أي من ذلك فتطبيق الويب التقدمي صحيح على الأرجح، وعبء الإثبات يقع على من يريد صيانة ثلاث قواعد كود.