BrowserEngineKit – Apple डेवलपर डाक्यूमेंटेशन

मूल लेख ↗ Hacker News चर्चा ↗

Apple का नया BrowserEngineKit framework, पहली बार, Chromium और Gecko जैसे third-party browser engines को iOS पर native रूप से चलने देगा—लेकिन केवल EU के users के लिए, जहाँ Digital Markets Act Apple को अपने platform restrictions ढीले करने के लिए मजबूर कर रहा है। Commenters true Firefox- और Chrome-based browsers के full extension support जैसे लाभों की तुलना बढ़े हुए attack surface, tracking, और web standards पर Chromium के प्रभुत्व को और मजबूत करने की संभावना से करते हैं। कई लोग यह भी सवाल उठाते हैं कि आम users को इससे कितना फर्क पड़ेगा, यह कहते हुए कि browser choice अक्सर technical quality से अधिक defaults और corporate power से तय होती है।

Apple के BrowserEngineKit परिवर्तन का दायरा

  • iOS पर वैकल्पिक browser engines की अनुमति देता है, लेकिन केवल EU में और कड़े शर्तों के साथ:
    • ऐप EU-केवल होना चाहिए, WebKit-आधारित संस्करण से अलग binary होना चाहिए, और उसमें default-browser entitlement नहीं हो सकता।
    • Entitlement आवश्यक है; Apple तय कर सकता है कि कौन engine ship करेगा और privacy संबंधी प्रतिबंध लगा सकता है (जैसे third-party cookies को default से off रखना)।
  • कुछ लोग इन APIs को अपेक्षा से अधिक सक्षम और कम petty मानते हैं (JIT, multiprocess apparently संभव)।

Firefox, Extensions, और मौजूदा Workarounds

  • कई लोग अपने अलग engine और full extensions के साथ “real” Firefox को लेकर उत्साहित हैं, खासकर uBlock Origin के लिए।
  • अन्य लोग बताते हैं कि Orion पहले से ही WebKit के जरिए iOS पर कई Chrome/Firefox extensions support करता है, लेकिन सीमाओं के साथ (जैसे uBlock पूरी तरह काम नहीं करता)।
  • इस पर संदेह भी उठता है कि Mozilla हाल की कटौतियों और पहले छोड़े गए ports को देखते हुए EU-केवल iOS engine में भारी निवेश करेगा या नहीं।

Chromium का प्रभुत्व बनाम Engine विविधता

  • चिंता है कि इससे iOS Chromium की ओर धकेला जाएगा, जिससे web standards और tracking पर Google का नियंत्रण मजबूत होगा।
  • जवाब में कहा जाता है: एक अपूर्ण WebKit/Safari भी गैर-Chromium engine के रूप में उपयोगी है, ताकि Google की एकतरफा शक्ति सीमित रहे।
  • कुछ का तर्क है कि Safari की development गति और opacity इतनी खराब है कि व्यावहारिक रूप से Chromium monoculture ही बेहतर हो सकती है।

सुरक्षा, “Walled Garden,” और उपयोगकर्ता विकल्प

  • एक पक्ष: iOS खोलने से attack surface बढ़ता है और malware authors, trackers, तथा authoritarian regimes को फायदा होता है।
  • दूसरा पक्ष: Android और desktop पहले से multiple engines और stores की अनुमति देते हैं और आम users के लिए “ठीक” दिखते हैं; इन आशंकाओं को बढ़ा-चढ़ाकर बताया गया मानते हैं।
  • इस पर बहस कि क्या यह वास्तव में “user choice” है:
    • उपयोगकर्ताओं को essential apps तक पहुँचने के लिए developers के साथ alternative stores या engines की ओर मजबूर होना पड़ सकता है।
    • कुछ लोग regulatory intervention (DMA) को platform power का मुकाबला करने के लिए आवश्यक मानते हैं; अन्य कहते हैं कि लोग iOS को ही इसी कड़े control के लिए खरीदते हैं।

Advertising, Tracking, और PWAs

  • कई लोग उम्मीद करते हैं कि यह ad tech के लिए “huge win” होगा:
    • कम Safari users का मतलब कम Intelligent Tracking Prevention और लंबे समय तक चलने वाली cookies।
  • अन्य लोग संभावित लाभ भी देखते हैं: बेहतर PWA support और Apple पर Safari सुधारने का दबाव (जैसे Web Bluetooth)।

व्यावहारिक बातें और खुले प्रश्न

  • केवल EU-resident iOS users ही योग्य होंगे; Apple ID region बदलना संभव है लेकिन कष्टदायक है और कुछ apps तक पहुँच खो सकती है।
  • ये प्रश्न बने हुए हैं:
    • Chrome/Firefox कितनी जल्दी full engines ship कर सकते हैं।
    • क्या captive portal और system web views alternative browsers का सम्मान करेंगे।
    • क्या Web Bluetooth और इसी तरह के APIs third-party engines के जरिए आएँगे।