تحديد مصدر الإشعارات الأصلية لتطبيقات الويب على أجهزة macOS

Marijn Kruisselbrink

Dan Murphy

تاريخ النشر: 16 يوليو 2026

اعتبارًا من Chrome 152، سيتم إسناد الإشعارات في تطبيقات الويب التقدّمية (PWA) المثبَّتة على نظام التشغيل macOS إلى تطبيق الويب التقدّمي نفسه بشكلٍ تلقائي، بدلاً من إسنادها إلى Google Chrome.

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

ما الذي سيتغيّر؟

في السابق، كانت جميع الإشعارات التي ترسلها تطبيقات الويب التقدّمية تُسنَد إلى Chrome على مستوى نظام التشغيل. وفي "مركز إشعارات macOS"، كانت تظهر ضمن "Google Chrome" وتستخدم رمز Chrome. لإيقاف الإشعارات، كان على المستخدمين استخدام عناصر التحكّم داخل Chrome، وليس "إعدادات النظام" في macOS.

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

المزايا:

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

مسار الإذن الجديد

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

المستخدمون الجدد (طلب الحصول على إذن للمرة الأولى)

إذا ثبّت مستخدم تطبيق ويب تقدّمي وطلب الموقع الإلكتروني إذن إرسال الإشعارات بعد التثبيت:

1. سيؤدي Chrome إلى تخطّي طلب الإذن على مستوى المتصفّح (القائمة المنسدلة من شريط العناوين).
2. سيؤدي Chrome على الفور إلى عرض طلب إذن نظام التشغيل macOS لتطبيق الويب التقدّمي.

المستخدمون الحاليون (مسار نقل البيانات)

إذا سبق للمستخدم منح إذن إرسال الإشعارات لموقعك الإلكتروني في Chrome، ثم ثبّت تطبيق الويب التقدّمي (أو سبق له تثبيته)، عليه منح إذن على مستوى نظام التشغيل لتطبيق الويب التقدّمي.

لجعل هذا الانتقال سلسًا قدر الإمكان:

1. في المرة الأولى التي يحاول فيها تطبيق الويب التقدّمي إرسال إشعار، سيعرض نظام التشغيل macOS طلب إذن النظام.
2. إذا وافق المستخدم، ستستمر الإشعارات في العمل بسلاسة.
3. إذا تجاهل المستخدم هذا الطلب أو أغلقه، سيعرض تطبيق الويب التقدّمي مؤشرًا داخل التطبيق (عادةً في شريط عنوان التطبيق أو القائمة) يوجهه إلى "إعدادات النظام" في macOS لتفعيل الأذونات يدويًا.

التأثير على المطوّرين: إيقاف خيار requireInteraction نهائيًا على نظام التشغيل macOS

على نظام التشغيل macOS، ما إذا كان الإشعار يظل على الشاشة إلى أن يغلقه المستخدم ("مستمر") أو يختفي تلقائيًا ("مؤقت") هو إعداد يتحكّم فيه المستخدم على مستوى كل تطبيق في "إعدادات النظام" في macOS.

بسبب تصميم نظام التشغيل هذا، لن يعود Chrome يراعي خيار requireInteraction في Notification API على نظام التشغيل macOS عندما يكون الإسناد نشطًا.

ما يعنيه ذلك لرمزك:

إذا كان تطبيقك يعتمد على requireInteraction: true لإبقاء الإشعارات المهمة على الشاشة، لن يعود ذلك مضمونًا على نظام التشغيل macOS. بدلاً من ذلك، عليك إجراء ما يلي:

• تصميم تطبيقك على أساس أنّ الإشعارات قد تكون مؤقتة (مؤقت)
• تشجيع المستخدمين الذين يحتاجون إلى إشعارات مستمرة على ضبط تنبيه بتلقّي إشعار في تطبيق الويب التقدّمي على "مستمر" في System Settings > Notifications > [Your PWA].

التأثير على المطوّرين: تتطلب App Badging API إذن إرسال الإشعارات

تتيح App Badging API لتطبيقات الويب ضبط شارة على رمز التطبيق (على سبيل المثال، عرض عدد الرسائل غير المقروءة). على نظام التشغيل macOS، يرتبط وضع الشارات على رمز التطبيق من الناحية الفنية بإعدادات إشعارات التطبيق. بما أنّ تطبيق الويب التقدّمي لديه الآن هوية إشعارات أصلية خاصة به:

• الإذن مطلوب: يجب أن يكون تطبيق الويب التقدّمي قد فعّل إذن إرسال الإشعارات على مستوى نظام التشغيل لكي تظهر الشارة على رمز Dock. يتوافق ذلك مع معايير منصة macOS ويتطابق مع الطريقة التي يتعامل بها Safari حاليًا مع Badging API لتطبيقات الويب.
• فشل بدون إشعار: إذا أوقف المستخدم "وضع شارة على رمز التطبيق" في System Settings > Notifications > [Your PWA]، أو رفض إذن الإ101}شعارات بالكامل، ستظل طلبات navigator.setAppBadge() ناجحة في JavaScript (بدون عرض خطأ)، ولكن لن يتم عرض الشارة على Dock. إذا كان تطبيقك يعتمد على وضع الشارات، احرِص على طلب إذن الإشعارات لضمان إمكانية عرض الشارة.

التأثير على إدارة المؤسسات

بالنسبة إلى مشرفي المؤسسات الذين يديرون أجهزة macOS ويريدون منح أذونات الإشعارات مسبقًا:

1. سياسة Chrome: عليك مواصلة ضبط سياسة Chrome (NotificationsAllowedForUrls) لمنح الإذن لمصدر تطبيق الويب التقدّمي.
2. سياسة macOS: بالإضافة إلى ذلك، عليك الآن نشر ملف إعداد macOS (إدارة الأجهزة الجوّالة) لمنح أذونات الإشعارات مسبقًا لمعرّف حزمة تطبيق الويب التقدّمي (برنامج دعم التطبيق).

بدون تطبيق كلتا السياسَتين، سيظل يُطلب من المستخدمين منح الإذن على مستوى نظام التشغيل.

أفضل الممارسات للمطوّرين

1. التحقّق من حالة الإذن: عليك دائمًا التحقّق من Notification.permission قبل إرسال إشعار.
2. الطلبات السياقية: إذا تبيّن لك أنّ الإذن تم منحه على مستوى الويب ولكن لا تظهر الإشعارات (وهو ما يمكن أن يحدث إذا تم إبطال الإذن على مستوى نظام التشغيل) ، وجِّه المستخدم إلى "إعدادات النظام" في macOS.
3. الاستعداد للإشعارات المؤقتة: لا تعتمد على requireInteraction في مسارات المستخدم المهمة على نظام التشغيل macOS.