امکان استفاده از موتور مرورگر جایگزین در iOS به معنی اجرای خودکار Gecko یا Blink در تمام نسخه‌های Firefox و Chrome روی همه آیفون‌ها نیست. نام مرورگر، موتور آن، روش نصب برنامه و منطقه عرضه چهار موضوع متفاوت‌اند. اگر این تفاوت‌ها را کنار بگذاریم، از یک تغییر محدود در سیاست پلتفرم به نتیجه نادرست درباره سازگاری تمام وب‌سایت‌ها می‌رسیم. برای توسعه‌دهنده وب، مهم است بداند کاربر واقعاً با کدام قابلیت روبه‌رو است.
این مقاله وضعیت را بر اساس مستندات رسمی Apple تا ۱۰ اکتبر ۲۰۲۶ توضیح می‌دهد. Apple مسیر استفاده از موتورهای جایگزین را برای توسعه‌دهندگان واجد شرایط در حوزه‌های مشخص فراهم کرده است. این مسیر، مجوز عمومی برای هر برنامه یا مدرک عرضه یک محصول مشخص نیست. همچنین تغییر سیاست موتور مرورگر نباید با Sideloading، فروشگاه جایگزین یا اضافه کردن یک وب‌اپ به صفحه اصلی یکسان فرض شود.
مرورگر با موتور مرورگر فرق دارد
مرورگر برنامه‌ای است که کاربر باز می‌کند؛ موتور مرورگر مسئول بخش‌هایی مانند پردازش HTML، CSS و اجرای تعامل صفحه است. دو برنامه با نام متفاوت ممکن است از موتور یکسان استفاده کنند. در مقابل، یک برند مرورگر ممکن است در پلتفرم‌های مختلف پیاده‌سازی متفاوتی داشته باشد. بنابراین دیدن نام Chrome روی یک دستگاه، برای نتیجه‌گیری درباره وجود Blink در همان محیط کافی نیست.
این تفاوت برای عیب‌یابی کاربرد مستقیم دارد. اگر یک صفحه در مرورگر دسکتاپ درست و در نسخه موبایل همان برند نادرست است، از یکسان بودن نام به یکسان بودن همه قابلیت‌ها نپرید. موتور، نسخه سیستم، تنظیمات و محیط اجرای صفحه را ثبت کنید. یک خطای CSS یا رفتار فرم می‌تواند به ترکیب این عوامل مربوط باشد، نه فقط به نام برنامه‌ای که در گزارش کاربر آمده است.
مسیر رسمی Apple برای موتور جایگزین
مستندات Apple درباره اتحادیه اروپا استفاده از موتورهای غیر WebKit را در محدوده پلتفرم، منطقه و شرایط مشخص توضیح می‌دهند. توسعه‌دهنده باید Entitlement مناسب و الزامات مربوط را رعایت کند. وجود این مسیر را با اجازه بی‌قیدوشرط برای همه برنامه‌ها اشتباه نگیرید. مجوز و اجرای فنی یک موتور، هر دو بخشی از کار سازنده مرورگر هستند.
مسیرهای توزیع جایگزین برنامه نیز در راهنمای برنامه‌ها در اتحادیه اروپا توضیح داده شده‌اند. این موضوع با موتور مرورگر مرتبط است، اما همان موضوع نیست. ممکن است درباره روش نصب یک برنامه خبری بخوانید که هیچ چیزی درباره موتور داخل آن ثابت نمی‌کند. برای یک تصمیم واقعی، مستندات همان قابلیت و شرایط جاری آن را مبنا قرار دهید.
Apple همچنین در راهنمای موتورهای جایگزین در ژاپن مسیر مربوط به iOS 26.2 و بعد از آن را شرح داده است. این راهنما میان برنامه مرورگر و برخی تجربه‌های مرور داخل برنامه تفاوت می‌گذارد و همچنان معیارهای صلاحیت و تعهدات امنیتی دارد. توسعه شرایط در یک منطقه، به معنی یکسان شدن وضعیت تمام کشورها و تمام نسخه‌های سیستم‌عامل نیست.
چرا Entitlement مهم است؟
Entitlement مجوز مشخصی در مدل پلتفرم است که امکان استفاده از قابلیت مربوط را فراهم می‌کند. در اینجا فقط انتخاب یک تنظیم در پروژه کافی نیست؛ توسعه‌دهنده باید مسیر درخواست و الزامات ارائه‌شده توسط Apple را دنبال کند. مرورگر کدی را اجرا می‌کند که از سایت‌های مختلف دریافت می‌شود، بنابراین مدیریت فرایندها، شبکه و به‌روزرسانی امنیتی بخشی از مسئولیت سازنده آن است.
برای صاحب وب‌سایت، این مجوز وظیفه تازه‌ای برای ثبت سایت ایجاد نمی‌کند. شما باید صفحه‌ای بسازید که با قراردادهای وب و قابلیت‌های مخاطبان هماهنگ باشد. اما برای تیمی که خود مرورگر یا تجربه مرور داخل یک اپ را توسعه می‌دهد، مسئله متفاوت است و به مستندات SDK، دامنه مجوز و شرایط توزیع وابسته می‌شود. این دو مخاطب را در یک راهنمای اجرایی مخلوط نکنید.
آیا WebKit دیگر اهمیت ندارد؟
خیر. باز شدن یک مسیر جایگزین، جمعیت کاربرانی را که همچنان از WebKit استفاده می‌کنند حذف نمی‌کند. دستگاه‌های قدیمی‌تر، مناطق دیگر و انتخاب خود کاربر در وضعیت واقعی محصول نقش دارند. اگر سایت شما قبلاً مشکل نمایش در یک محیط WebKit داشته، یک تغییر سیاست دلیل کنار گذاشتن بررسی آن مشکل نیست. کاربران فعلی باید بتوانند از محصول استفاده کنند، حتی اگر تنوع موتور در آینده بیشتر شود.
به همین دلیل، تصمیم سازگاری را از داده مخاطبان بگیرید. برای فروشگاه عمومی یا سامانه‌ای با کاربران متنوع، انتظار پشتیبانی گسترده‌تر منطقی است. برای ابزار داخلی با دستگاه و نسخه مدیریت‌شده، محدوده ممکن است مشخص‌تر باشد. در هر دو حالت، «همه کاربران مرورگر جدید دارند» فرضی است که باید با شرایط واقعی محصول هماهنگ شود، نه با عنوان یک خبر درباره پلتفرم.
تأثیر بر CSS و رابط کاربری
تنوع موتور می‌تواند تفاوت‌های بیشتری در پشتیبانی ویژگی‌ها و رفتارهای مرزی ایجاد کند. راه‌حل، تشخیص نام مرورگر برای تک‌تک سبک‌ها نیست. ابتدا قابلیت مورد نیاز را شناسایی کنید و در صورت ضرورت از Feature Detection و Progressive Enhancement استفاده کنید. صفحه باید یک رفتار پایه قابل استفاده داشته باشد و امکانات تازه، تجربه را بهتر کنند. نبود یک ویژگی تزئینی نباید اصل ارسال فرم یا خواندن محتوا را متوقف کند.
برای مثال، اگر یک انیمیشن تازه در همه محیط‌ها وجود ندارد، ساختار صفحه، focus و پیام‌های اصلی باید همچنان درست باشند. اگر طراحی به یک API مهم وابسته است، مسیر جایگزین را از ابتدا مشخص کنید. مقاله طراحی Mobile First کمک می‌کند درباره عرض صفحه، ورودی لمسی و نیاز کاربر فکر کنید؛ پشتیبانی موتور فقط یکی از بخش‌های این تصمیم است.
در سایت فارسی، علاوه بر موتور باید RTL و نمایش متن ترکیبی را هم بررسی کنید. عنوان بلند، اعداد، تاریخ و نام انگلیسی در یک جمله، سناریوهای واقعی‌اند. تغییر موتور قرار نیست تصمیم‌های ناقص تایپوگرافی را خودکار اصلاح کند. برای انتخاب فونت و خوانایی، راهنمای تایپوگرافی فارسی را کنار تصمیم سازگاری مرورگر به کار ببرید.
PWA و نصب برنامه موضوعی مستقل‌اند
PWA مجموعه‌ای از قابلیت‌ها و الگوهای وب است و تجربه آن به پشتیبانی محیط اجرا وابسته است. نصب، اعلان، اجرا در پس‌زمینه یا دسترسی به APIهای دستگاه را نمی‌توان فقط از نام موتور نتیجه گرفت. حتی میان دو محیط با موتور مشابه ممکن است محدودیت‌های سیستم‌عامل یا حالت اجرا متفاوت باشند. صفحه داخل مرورگر، وب‌اپ نصب‌شده و WebView داخل یک برنامه لزوماً قرارداد یکسانی ندارند.
اگر محصول شما به یک قابلیت PWA وابسته است، پشتیبانی همان قابلیت را برای محیط‌های هدف بررسی کنید. مثلاً امکان نصب به معنی تضمین اجرای پیوسته کد در پس‌زمینه نیست. پیام رابط باید محدودیت را قابل فهم بیان کند و از کاربر انتظار انجام کاری را نداشته باشد که محیط او فراهم نمی‌کند. وعده «PWA کامل‌تر برای همه» بدون مشخص کردن قابلیت و محیط، برای تصمیم محصول کافی نیست.
مرور داخل اپ را با مرورگر مستقل یکی نگیرید
کاربر ممکن است لینک سایت را در پیام‌رسان یا یک اپ دیگر باز کند. در این حالت، تجربه مرور داخل برنامه می‌تواند با مرورگر مستقل تفاوت داشته باشد. اشتراک‌گذاری، cookie، ورود و بازگشت از پرداخت از مسیرهای حساس این تجربه هستند. گزارش «روی آیفون کار نمی‌کند» باید با پرسش درباره مسیر باز شدن صفحه دقیق‌تر شود؛ در غیر این صورت، شرایط بازسازی مسئله روشن نیست.
در طراحی سایت، مسیر خروج به مرورگر اصلی یا ادامه فرایند را در جای لازم روشن کنید. برای مثال، اگر یک محیط محدود، بخشی از جریان احراز هویت را پشتیبانی نمی‌کند، پیام راهنما باید اقدام بعدی را بگوید. کاربر نباید از نام فنی موتور یا نوع WebView سر دربیاورد تا کارش را انجام دهد. اطلاعات فنی را در گزارش تیم ثبت کنید و متن رابط را بر اساس نیاز کاربر بنویسید.
یک فهرست عملی برای تیم وب
نخست محیط‌های مهم را ثبت کنید: دستگاه، نسخه سیستم، مرورگر مستقل یا درون‌برنامه‌ای و مسیر ورود به صفحه. سپس جریان‌های اصلی را انتخاب کنید، مثل خواندن مقاله، ورود، پر کردن فرم و پرداخت. هدف این است که بررسی سازگاری به چند مشاهده تصادفی محدود نشود. هر جریان باید ورودی، نتیجه مورد انتظار و وضعیت خطای قابل فهم داشته باشد.
بعد قابلیت‌های تازه‌ای را که استفاده کرده‌اید فهرست کنید. بعضی از آن‌ها فقط ظاهر را بهتر می‌کنند و برخی برای کار اصلی محصول ضروری‌اند. برای دسته دوم، مسیر جایگزین یا حداقل نسخه پشتیبانی‌شده باید مشخص باشد. از یک فهرست کلی مرورگرها به‌عنوان جایگزین این تحلیل استفاده نکنید؛ مسئله اصلی رفتار قابلیت مورد نیاز در شرایط کاربران شماست.
در گزارش خطا، تفاوت دیده‌شده را دقیق بنویسید: کدام عنصر، کدام ورودی و در چه مرحله‌ای رفتار متفاوت دارد. عکس صفحه می‌تواند کمک کند، ولی برای خطای درخواست یا ورود، اطلاعات جریان هم لازم است. ثبت زمان و مسیر درخواست، بدون انتشار اطلاعات حساس، به تیم کمک می‌کند مشکل رابط را از مشکل شبکه یا Session جدا کند.
خبر سیاست پلتفرم را چطور بخوانیم؟
هر خبر درباره موتور جایگزین را با چهار سؤال بخوانید: برای کدام منطقه، روی کدام نسخه پلتفرم، برای چه نوع برنامه و با چه مجوزی؟ سپس بررسی کنید آیا یک مرورگر مشخص واقعاً نسخه مربوط را عرضه کرده یا فقط امکان آن اعلام شده است. این ترتیب جلوی نسبت دادن قابلیت عرضه‌نشده به تمام کاربران را می‌گیرد.
برای توسعه‌دهنده وب، نتیجه کاربردی این تغییر افزایش اهمیت طراحی مبتنی بر قابلیت است. موتورهای متنوع‌تر می‌توانند گزینه‌های بیشتری فراهم کنند، اما مسئولیت ساخت تجربه قابل استفاده باقی می‌ماند. WebKit را از برنامه سازگاری حذف نکنید و وجود یک مسیر جایگزین را با پایان همه محدودیت‌های وب موبایل برابر نگیرید. محصول شما باید بر اساس کاربران واقعی و امکانات واقعی محیط آن‌ها تصمیم بگیرد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!