BrowserEngineKit – Documentação para Desenvolvedores da Apple

Artigo original ↗ Discussão no Hacker News ↗

O novo framework BrowserEngineKit da Apple permitirá, pela primeira vez, que motores de navegador de terceiros como Chromium e Gecko rodem nativamente no iOS — mas apenas para usuários na UE, onde o Digital Markets Act está forçando a Apple a afrouxar suas restrições de plataforma. Os comentaristas ponderam os benefícios de navegadores reais baseados em Firefox e Chrome com suporte completo a extensões contra preocupações com maior superfície de ataque, rastreamento e a probabilidade de consolidar ainda mais o domínio do Chromium sobre os padrões da web. Muitos também questionam o quanto os usuários comuns se importarão, observando que a escolha do navegador costuma ser mais influenciada por padrões e poder corporativo do que por qualidade técnica.

Âmbito da mudança do BrowserEngineKit da Apple

  • Permite motores de navegador alternativos no iOS, mas apenas na UE e com condições estritas:
    • O app deve ser apenas para a UE, binário separado da versão baseada em WebKit, e não pode ter a entitlement de navegador padrão.
    • Entitlement exigida; a Apple pode controlar quem distribui um motor e impor restrições de privacidade (por exemplo, cookies de terceiros desativados por padrão).
  • Alguns veem as APIs como mais capazes e menos mesquinhas do que o esperado (JIT, multiprocess aparentemente possíveis).

Firefox, extensões e contornos existentes

  • Muitos estão animados com um “verdadeiro” Firefox com seu próprio motor e extensões completas, especialmente para uBlock Origin.
  • Outros observam que o Orion já suporta muitas extensões do Chrome/Firefox no iOS via WebKit, mas com limitações (por exemplo, uBlock não funciona completamente).
  • Surgem dúvidas sobre se a Mozilla investirá pesadamente em um motor para iOS exclusivo da UE, dadas as recentes reduções e ports anteriores abandonados.

Domínio do Chromium vs diversidade de motores

  • Preocupação de que isso empurre o iOS em direção ao Chromium, fortalecendo o controle do Google sobre padrões da web e rastreamento.
  • Contra-argumento: até mesmo um WebKit/Safari imperfeito é útil como um motor não-Chromium para limitar o poder unilateral do Google.
  • Alguns argumentam que o ritmo de desenvolvimento e a opacidade do Safari são tão ruins que, na prática, uma monocultura do Chromium poderia ser preferível.

Segurança, “jardim murado” e escolha do usuário

  • Um lado: abrir o iOS aumenta a superfície de ataque e beneficia criadores de malware, rastreadores e regimes autoritários.
  • Outro lado: Android e desktop já permitem múltiplos motores e lojas e “parecem funcionar bem” para usuários típicos; os medos são vistos como exagerados.
  • Debate sobre se isso é realmente “escolha do usuário”:
    • Usuários podem ser forçados a seguir desenvolvedores para lojas ou motores alternativos para acessar apps essenciais.
    • Alguns veem a intervenção regulatória (DMA) como necessária para conter o poder da plataforma; outros dizem que as pessoas compram iOS justamente pelo controle rígido.

Publicidade, rastreamento e PWAs

  • Vários esperam que isso seja uma “grande vitória” para a ad tech:
    • Menos usuários do Safari significam menos Intelligent Tracking Prevention e cookies com vida útil mais longa.
  • Outros apontam possíveis vantagens: melhor suporte a PWAs e pressão sobre a Apple para melhorar o Safari (por exemplo, Web Bluetooth).

Questões práticas e em aberto

  • Apenas usuários de iOS residentes na UE se qualificam; trocar a região do Apple ID é possível, mas trabalhoso e pode custar acesso a alguns apps.
  • Permanecem dúvidas sobre:
    • Quão rápido Chrome/Firefox podem lançar motores completos.
    • Se captive portal e visualizações web do sistema respeitarão navegadores alternativos.
    • Se Web Bluetooth e APIs semelhantes aparecerão por meio de motores de terceiros.