BrowserEngineKit – Documentación para desarrolladores de Apple
El nuevo framework BrowserEngineKit de Apple permitirá, por primera vez, que motores de navegador de terceros como Chromium y Gecko se ejecuten de forma nativa en iOS, pero solo para usuarios de la UE, donde la Ley de Mercados Digitales obliga a Apple a relajar las restricciones de su plataforma. Los comentaristas sopesan los beneficios de navegadores verdaderos basados en Firefox y Chrome con compatibilidad total de extensiones frente a las preocupaciones por una mayor superficie de ataque, el rastreo y la probabilidad de afianzar aún más el dominio de Chromium sobre los estándares web. Muchos también cuestionan cuánto importará esto a los usuarios comunes, señalando que la elección del navegador suele estar más impulsada por valores predeterminados y poder corporativo que por la calidad técnica.
Alcance del cambio de BrowserEngineKit de Apple
- Permite motores de navegador alternativos en iOS, pero solo para la UE y con condiciones estrictas:
- La app debe ser exclusiva de la UE, un binario separado de la versión basada en WebKit, y no puede tener la autorización de navegador predeterminado.
- Se requiere autorización; Apple puede decidir quién puede distribuir un motor e imponer restricciones de privacidad (por ejemplo, cookies de terceros desactivadas por defecto).
- Algunos ven las APIs como más capaces y menos mezquinas de lo esperado (JIT, aparentemente es posible multiproceso).
Firefox, extensiones y soluciones alternativas existentes
- Muchos están entusiasmados con un “Firefox real” con su propio motor y extensiones completas, especialmente para uBlock Origin.
- Otros señalan que Orion ya admite muchas extensiones de Chrome/Firefox en iOS mediante WebKit, pero con limitaciones (por ejemplo, uBlock no funciona por completo).
- Surgen dudas sobre si Mozilla invertirá mucho en un motor para iOS exclusivo de la UE, dada la reducción reciente y anteriores puertos abandonados.
Dominio de Chromium frente a diversidad de motores
- Preocupa que esto empuje iOS hacia Chromium, reforzando el control de Google sobre los estándares web y el rastreo.
- Contraargumento: incluso un WebKit/Safari imperfecto es útil como motor no Chromium para limitar el poder unilateral de Google.
- Algunos sostienen que el ritmo de desarrollo y la opacidad de Safari son tan malos que, en la práctica, una monocultura de Chromium podría ser preferible.
Seguridad, “jardín amurallado” y elección del usuario
- Una postura: abrir iOS aumenta la superficie de ataque y beneficia a autores de malware, rastreadores y regímenes autoritarios.
- La otra: Android y escritorio ya permiten varios motores y tiendas y “se ven bien” para usuarios típicos; se considera que los temores están exagerados.
- Debate sobre si esto es realmente “elección del usuario”:
- Puede que los usuarios se vean obligados a seguir a los desarrolladores hacia tiendas o motores alternativos para acceder a apps esenciales.
- Algunos consideran necesaria la intervención regulatoria (DMA) para contrarrestar el poder de la plataforma; otros dicen que la gente compra iOS precisamente por su control estricto.
Publicidad, rastreo y PWA
- Varios esperan que esto sea una “gran victoria” para la tecnología publicitaria:
- Menos usuarios de Safari significa menos Intelligent Tracking Prevention y cookies de mayor duración.
- Otros señalan posibles ventajas: mejor compatibilidad con PWA y presión sobre Apple para mejorar Safari (por ejemplo, Web Bluetooth).
Aspectos prácticos y preguntas abiertas
- Solo califican usuarios de iOS residentes en la UE; cambiar la región del Apple ID es posible, pero engorroso y puede hacer perder acceso a algunas apps.
- Siguen abiertas preguntas sobre:
- Qué tan rápido Chrome/Firefox podrán lanzar motores completos.
- Si el portal cautivo y las vistas web del sistema respetarán los navegadores alternativos.
- Si Web Bluetooth y APIs similares aparecerán a través de motores de terceros.