عنوان «Safari 20 و پشتیبانی کامل PWA» خبر قابل اتکایی نبود. منابع رسمی بررسی‌شده چنین بسته‌ای از قابلیت‌ها را با آن عنوان تأیید نمی‌کنند و یادداشت‌های Apple و WebKit نسخه‌ها و قابلیت‌ها را جدا معرفی می‌کنند. برای نمونه، یادداشت Safari 26.0 مرجع یک انتشار مشخص است. عنوان مقاله اصلاح شده تا به بررسی قابلیت‌های PWA در Safari بپردازد. slug برای حفظ نشانی قبلی باقی مانده، اما نباید از آن نتیجهٔ فنی گرفت.
«پشتیبانی کامل» دربارهٔ PWA عبارت مبهمی است. PWA یک API واحد با کلید روشن یا خاموش نیست؛ نصب، cache، اعلان و کار در پس‌زمینه به قابلیت‌های متفاوتی مربوط‌اند. یک محصول ممکن است بدون Background Sync قابل استفاده باشد، در حالی که محصول دیگر به یک قرارداد ارسال معوق نیاز دارد. بررسی باید از عملیات مورد نیاز شروع شود. فهرست اسم APIها بدون محیط اجرا و شرط استفاده، وضعیت واقعی کاربر را توضیح نمی‌دهد.
محیط اجرا را دقیق نام ببرید
Safari روی macOS، تب مرورگر در iPhone و Web App نصب‌شده روی Home Screen را یک محیط فرض نکنید. مسیر دریافت مجوز و ادغام با سیستم‌عامل می‌تواند متفاوت باشد. در راهنمای محصول باید معلوم باشد کاربر از کدام محیط استفاده می‌کند. جملهٔ «در Safari کار می‌کند» برای یک قابلیت وابسته به نصب کافی نیست. نسخهٔ سیستم‌عامل و حالت اجرا را کنار نام مرورگر بنویسید تا همکار بتواند ادعا را با منبع مناسب مقایسه کند.
یک مثال فرضی، سامانهٔ پیگیری سفارش است که کاربر از لینک پیامک وارد آن می‌شود. ممکن است نمایش سفارش در تب مرورگر انجام شود، اما دریافت اعلان به مرحلهٔ دیگری وابسته باشد. اگر رابط بدون توضیح همان لحظه درخواست مجوز نشان دهد، کاربر دلیل تصمیم را نمی‌فهمد. جریان باید میان بازدید اولیه و فعال کردن قابلیت اضافی تمایز بگذارد. ارزش سرویس باید پیش از درخواست تغییر در دستگاه روشن باشد.
Web Push سابقه و شرط مشخص دارد
اعلام رسمی WebKit برای iOS و iPadOS 16.4، Web Push را برای Web Appهای اضافه‌شده به Home Screen توضیح می‌دهد. درخواست مجوز نیز باید در پاسخ به تعامل مستقیم کاربر انجام شود. بنابراین نسبت دادن شروع این قابلیت به «Safari 20» دقیق نبود. هنگام بازنویسی خبر تاریخی، تاریخ و دامنهٔ قابلیت را حفظ کنید؛ وجود آن در یک نسخهٔ بعدی، زمان معرفی اولیه را تغییر نمی‌دهد.
در مثال سفارش، دکمهٔ دریافت اعلان باید نوع پیام را روشن کند؛ مثلاً تغییر وضعیت همان سفارش. اگر کاربر انتظار اطلاع‌رسانی عملیاتی دارد و بعد تبلیغ می‌گیرد، مشکل از طراحی ارتباط است. ابزار Push اجازهٔ فنی دریافت پیام را مدیریت می‌کند، اما مناسب بودن محتوا را تعیین نمی‌کند. گزینهٔ غیرفعال کردن و تغییر ترجیح باید در قرارداد محصول وجود داشته باشد. مجوز گرفتن یک بار، رضایت نامحدود برای هر نوع پیام نیست.
Push را با تأیید تحویل قطعی اشتباه نگیرید. تنظیم دستگاه و وضعیت شبکه می‌تواند در دریافت و نمایش اثر داشته باشد. برای اطلاعاتی که باید در دسترس بماند، صفحهٔ داخل محصول منبع اصلی وضعیت باشد. اعلان مسیر خبر دادن است، نه تنها محل ثبت حقیقت. اگر کاربر پیام را از دست بدهد، باید بتواند با مراجعهٔ دوباره همان وضعیت را ببیند. این طراحی، به تجربه‌ای که فقط به یک اعلان وابسته است آسیب‌پذیری کمتری می‌دهد.
Badging وضعیت کوتاه نشان می‌دهد
Badge روی نماد برنامه می‌تواند تعداد یا نشانهٔ کوتاهی از وضعیت را نمایش دهد. این قابلیت با متن کامل اعلان یکسان نیست. در مدل محصول باید مشخص باشد شمارنده به چه چیزی اشاره می‌کند: پیام خوانده‌نشده، سفارش نیازمند توجه یا رویداد دیگری. اگر شمارنده پس از باز شدن صفحه به‌روزرسانی نشود، کاربر ممکن است همچنان تصور کند کاری باقی مانده است. تعریف وضعیت و زمان پاک شدن آن، پیش از استفاده از API لازم است.
مستند WebKit دربارهٔ Home Screen Web Apps، Badging را در همان زمینهٔ محیطی توضیح می‌دهد. این محدودیت را در نقل خبر حذف نکنید. یک دکمهٔ نمایشی در سایت که عددی روی آن قرار دارد، Badge سیستم‌عامل نیست. این دو ممکن است ظاهر مشابه داشته باشند ولی مسیر مجوز و دامنهٔ نمایش متفاوت دارند. نام‌گذاری درست در مستند محصول، مانع آن می‌شود که تیم دربارهٔ دو رفتار متفاوت با یک واژه صحبت کند.
Background Sync را جدا بررسی کنید
Background Synchronization API به تعویق انداختن بعضی کارها تا زمانی که اتصال مناسب فراهم شود مربوط است. مرجع MDN این API را با محدودیت سازگاری معرفی می‌کند. از پشتیبانی Push نمی‌توان پشتیبانی Background Sync را نتیجه گرفت. متن قبلی این مقاله این قابلیت‌ها را یک بستهٔ کامل فرض کرده بود. برای طراحی، جدول همان API و محیط هدف را مبنا قرار دهید و fallback مستقل داشته باشید.
اگر ثبت درخواست در پس‌زمینه در محیط کاربر ممکن نباشد، می‌توان مسیر ارسال هنگام باز شدن دوبارهٔ برنامه را بررسی کرد. رابط باید روشن بگوید پیش‌نویس ذخیره شده ولی هنوز در سرور ثبت نشده است. نمایش موفقیت قطعی پیش از دریافت پاسخ سرور، قرارداد اشتباهی می‌سازد. ارسال معوق به شناسایی درخواست تکراری و مدیریت تعارض نیز نیاز دارد. انتخاب fallback فقط یک شرط if در کد نیست؛ کاربر باید وضعیت عملیات را بفهمد.
برای دادهٔ حساس، نگهداری پیش‌نویس در دستگاه نیاز به سیاست مشخص دارد. باید بدانید چه چیزی ذخیره می‌شود، چه زمانی حذف می‌شود و دستگاه مشترک چه اثری دارد. این‌ها تصمیم‌های محصول‌اند و یک API آفلاین آن‌ها را خودکار حل نمی‌کند. اگر عملیات نیاز به تأیید دوبارهٔ کاربر دارد، بازگشت اتصال نباید بی‌خبر تصمیم قبلی را در شرایط تغییرکرده اجرا کند. معنی اقدام باید در تمام مراحل حفظ شود.
Screen Wake Lock برای نیاز مشخص
Screen Wake Lock می‌تواند در بعضی محیط‌ها به جلوگیری از خاموش شدن صفحه کمک کند. یک راهنمای آشپزی یا نمایش دستور کار ممکن است چنین نیازی داشته باشد. ولی بیدار نگه داشتن صفحه در هر بازدید سایت مناسب نیست. مرجع Screen Wake Lock شرایط و رفتار قابلیت را توضیح می‌دهد. انتخاب باید با درخواست قابل فهم کاربر همراه باشد و برنامه برای آزاد شدن یا در دسترس نبودن آن رفتار مشخص داشته باشد.
در پیام رابط، نتیجهٔ درخواست را با دقت بیان کنید. اگر وضعیت تغییر کرد، نباید همچنان نوشته باشد «صفحه روشن می‌ماند». یک کنترل روشن و خاموش با متن وضعیت، از فعال‌سازی پنهان قابل فهم‌تر است. این مثال دربارهٔ طراحی رفتار است، نه گزارش پشتیبانی همهٔ نسخه‌های Safari. برای هر محیط مقصد باید منبع همان قابلیت بررسی شود. نام یک نسخهٔ بزرگ، جای جدول سازگاری و شرط اجرای API را نمی‌گیرد.
Feature Detection به جای حدس از نام مرورگر
وقتی امکان بررسی وجود API هست، طراحی را به همان قابلیت متصل کنید. اما وجود یک عضو در محیط، تمام شرایط عملیاتی را ثابت نمی‌کند؛ ممکن است مجوز یا وضعیت اجرا اجازهٔ کار ندهد. پس مسیر موفقیت و شکست هر دو لازم‌اند. پنهان کردن دکمهٔ نامعتبر بخشی از کار است، ولی پیامی که بعد از شکست عملیات نشان داده می‌شود نیز باید دلیل قابل استفاده و راه بعدی داشته باشد. این قرارداد از جدول ثابت نام مرورگرها منعطف‌تر است.
برای خبرهای Safari، گزارش قابلیت‌های Safari 26.0 در WebKit نمونه‌ای از منبع نسخه‌محور است. گزارش را با تاریخ و نام دقیق نگه دارید و از آن نتیجهٔ «آخرین مانع همهٔ اپ‌ها برداشته شد» نگیرید. یک ابزار وب ممکن است با امکانات موجود نیاز خود را پوشش دهد، ولی ابزار دیگری به سخت‌افزار یا کار پس‌زمینهٔ متفاوتی وابسته باشد. تصمیم به جایگزینی اپ بومی نیاز به بررسی همان محصول دارد.
برای طراحی مسیر خود، قابلیت‌های ضروری را کنار حالت اجرای مورد انتظار و رفتار جایگزین بنویسید. سپس متن راهنما را با همان قرارداد هماهنگ کنید. راهنمای تصمیم‌گیری PWA در ۲۰۲۶ برای این مرحله مرتبط است. خبر این مقاله دربارهٔ انتشار یک «PWA کامل» نیست؛ نتیجهٔ بازبینی آن است که Push، Badge، Sync و Wake Lock باید جدا و با دامنهٔ مستند بررسی شوند تا وعدهٔ رابط با تجربهٔ واقعی کاربر هماهنگ بماند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!