Japão: Apple deve acabar com a proibição de motores de navegador até dezembro
(open-web-advocacy.org)- O governo japonês aprovou recentemente a lei dos smartphones, proibindo diretamente a política da Apple de banir motores de navegador de terceiros no iOS
- Até agora, a exigência do motor WebKit bloqueava na prática a concorrência entre navegadores no iOS e reduzia a competitividade dos web apps
- As novas diretrizes deixam claro que a Apple também não poderá impor obstáculos técnica ou comercialmente inviáveis
- Além disso, o acesso às APIs do sistema operacional para navegadores deve ser garantido com equivalência funcional, sem degradação discriminatória de desempenho
- Com a entrada em vigor da lei japonesa, junto com UE e Reino Unido, forma-se um ambiente regulatório para restaurar a concorrência entre navegadores, e 2026 deve ser um ponto de virada
Japão exige que a Apple acabe com a proibição de motores de navegador
O Japão aprovou oficialmente recentemente a “Lei de Promoção da Concorrência em Software para Smartphones”, implementando uma medida que proíbe diretamente a antiga política da Apple de vetar motores de navegador de terceiros no iOS
Situação da proibição de motores de navegador
- Antes, a Apple permitia apenas o uso do motor WebKit, o que na prática excluía do iOS todos os principais motores de navegador usados por Firefox, Chrome, Edge, Opera, Brave, Vivaldi e outros
- Isso bloqueava efetivamente a concorrência entre navegadores e criava uma situação em que web apps não podiam usar APIs nem desempenho necessários para competir em igualdade com apps nativos
Legislação e diretrizes no Japão
- A lei foi planejada com base em um relatório da Sede de Competição no Mercado Digital, e também incorporou consultoria da Open Web Advocacy
- Recentemente, foram publicadas as diretrizes da Lei de Concorrência em Software Móvel (MSCA), esclarecendo de forma concreta como a lei será interpretada e aplicada
Proibição de dificultar motores de navegador alternativos
- As diretrizes proíbem explicitamente qualquer ato que obstrua ou dificulte a adoção de motores de navegador de terceiros
- Isso inclui impor restrições técnicas excessivas aos fornecedores de apps, repassar custos excessivos ou adotar medidas que afastem os usuários de navegadores alternativos
- Ao avaliar se há obstrução, não se considera apenas quando o fornecedor proíbe de forma explícita, mas também casos em que a possibilidade real de adoção se torna extremamente baixa
- Essa cláusula significa que não será permitido à Apple autorizar apenas nominalmente algo que, na prática, seja inutilizável ou comercialmente irrelevante
Equivalência funcional no acesso às APIs do sistema operacional
- A MSCA determina que o acesso às APIs do sistema operacional deve garantir acesso funcionalmente equivalente
- É permitido fornecer APIs alternativas, mas, se o desempenho for substancialmente inferior na prática, isso não será considerado equivalência funcional
- Ou seja, mesmo que a abordagem técnica seja diferente, navegadores de terceiros também devem receber desempenho e acessibilidade equivalentes aos de que desfrutam a Apple e outros fornecedores designados
Obrigação de tela de escolha de navegador (Choice Screen)
- A lei torna obrigatória a oferta de uma tela de escolha (Choice Screen) para navegadores (e outros softwares)
- Em uma diretriz mais rígida que a da UE, a tela de escolha deve ser exibida imediatamente “logo após a ativação inicial”
- Na primeira configuração do smartphone ou na primeira execução do app correspondente, o usuário deve ser levado a escolher um software específico
Próximos desdobramentos
- A Lei de Concorrência em Software Móvel deve entrar em vigor em dezembro de 2025
- O Japão se junta à UE e ao Reino Unido entre os locais onde a Apple terá de permitir motores de navegador de terceiros
- Espera-se que o Japão prepare a aplicação da lei com base na experiência regulatória da Europa e do Reino Unido
- Como mostram os casos da UE e do Reino Unido, a aplicação efetiva deve ser um processo longo e complexo
Conclusão e implicações
- Japão, UE e Reino Unido estão avançando na restauração da concorrência real entre navegadores no iOS ao obrigar a Apple a dar suporte a motores de navegador de terceiros
- 2026 pode se tornar um ponto de virada para a mudança na estrutura do mercado de navegadores
- O sucesso final dependerá da disposição das autoridades regulatórias para aplicar a lei e dos esforços reais da Apple para implementar mudanças
- Destaca-se o papel do governo japonês e de organizações relacionadas, que vêm trabalhando há muito tempo para melhorar o ambiente competitivo de navegadores e web apps
7 comentários
Hmm... para mim, é uma pena, porque quando todos os recursos de navegação passam por uma biblioteca base, se o sistema bloqueia uma URL específica, isso garante uma consistência boa e impossível de contornar em todos os recursos de navegação interna dos apps.
Espera-se uma forte ascensão dos navegadores de IA
Do ponto de vista dos desenvolvedores, isso acaba significando que haverá ainda mais ambientes a considerar haha..
Agora vai ter que desenvolver de acordo com os padrões da web. E melhor evitar usar de forma agressiva recursos que nem existem.
Parece que há muitos, mas no fim não são só o Firefox e o motor do Chromium?
Só de ver a lista de motores mencionados no status da proibição já dá tontura @_@
Comentários no Hacker News
Todo mundo está falando do Chrome, mas eu desativei o Chrome no Android e uso Firefox. Com
uBlock Originno Firefox móvel, a experiência fica quase igual à da web no desktop. Não é só bloqueio de anúncios; também dá para bloquear na hora elementos com os quais eu não me importo usando regras RegEx como:has-text. O Chrome nem no desktop consegue mais fazer isso. Estou quase considerando migrar de vez para o Android como meu dispositivo principal. Só que a praticidade de responder mensagens direto do MacBook por causa do iMessage é boa demais para largar fácil. Tirando isso, o Android é muito melhor no geral. Melhor nem começar a falar do teclado do iOS ou da SiriA combinação FF + uBO é o app matador que me faz continuar no Android. Se a Apple permitisse isso, eu já teria migrado faz tempo. Já pensou em messages.google.com? Precisa do app de mensagens do Google (não o Samsung Messages), e aí dá para usar SMS e RCS no desktop, então funciona muito bem como substituto do iMessage
A extensão consent-o-matic no Firefox móvel também é realmente útil. Ela clica automaticamente em quase todos os banners de cookies, então você não precisa ficar lidando com isso no celular e tudo fica bem mais conveniente
Eu também uso https://messages.google.com para criar uma experiência tipo iMessage no desktop baseada em Android. Talvez sirva para o seu caso também? Eu não uso iMessage, então posso não ser a melhor referência
Se dá para viver sem iMessage e usar só SMS, o KDE Connect oferece mensagens no desktop de forma excelente a partir do Android (funciona em Linux, Windows e MacOS; há diferenças de recursos entre plataformas, mas SMS é suportado em todas). https://kdeconnect.kde.org/
Parece que o Japão aprendeu com os casos de “conformidade por tecnicalidade” que a Apple mostrou na UE. Se vier com esse tipo de postura, espero que a Apple também tome no Japão uma multa de verdade que realmente doa. Para mim não é uma questão de "if", e sim de "when"
Já imaginei até proibição de vendas e importação; aí fico curioso para saber por quanto tempo a Apple teria de manter a Apple Store fechada até se render
Eu gosto de um walled garden que me impeça de fazer besteira sozinho. Sou grato porque a Apple não sai entregando minha localização de qualquer jeito nem deixa algum Monarch esquisito me rastrear, então me preocupo menos com vazamento de privacidade. (+4500 upvotes) Sempre achei suspeito que, no Reddit, manchetes anti-Apple pegassem +30 mil upvotes, enquanto os comentários pró-Apple fossem muito menos numerosos em comparação. Fico pensando se equipe de marketing ou troll farm não andou fazendo gestão de reputação
Se esse movimento legislativo global levar a um ecossistema de apps mais aberto no iOS, é algo muito bem-vindo. O BrowserEngineKit não passa de um wrapper fino em torno de XPC e do sistema de extensões do iOS. Se o XPC fosse uma API aberta, e se a Apple permitisse JIT em subprocessos isolados sem depender de autorização dela, seria muito melhor para desenvolver. Por exemplo, um app de mensagens poderia ter um subprocesso separado para lidar com entradas não confiáveis (o iMessage já faz isso), componentes instáveis do app poderiam ser isolados, melhorando usabilidade e recuperação de crashes, emuladores de sistemas antigos ficariam muito mais rápidos, seria possível aproveitar WASM no iOS, e os navegadores também poderiam usar XPC sem precisar de APIs especiais. O problema é que, se isso se tornar possível, ficaria fácil carregar dentro dos apps código que roda em velocidade nativa mesmo depois da revisão da App Store, e, como todos sabemos, se esse mundo chegar será um desastre
Se esse “desastre” vier, eu quero assistir ao caos em sites como o MacRumors. É difícil ser ingênuo a ponto de achar que a Apple não patrocina a promoção de narrativas na internet em favor dos próprios interesses econômicos. Por exemplo, fica se repetindo praticamente sem parar essa ideia absurda de que a liberdade de usar seu próprio telefone ameaça a segurança e a privacidade de todos
Isso colocaria uma grande parte da responsabilidade de defesa contra malware no nível do sandbox de apps. Na verdade, mesmo hoje o sandbox já é só uma das várias camadas de defesa, junto com notarização, permissões, revisão de apps etc. Eu também sou a favor de o usuário instalar o que quiser, mas, se isso acontecer, é preciso reconhecer que um iPhone comum ficaria mais exposto a malware, como já acontece no Android. Além do desejo monopolista, também existem preocupações reais de segurança por trás dessa política da Apple (embora o principal motor provavelmente seja o lucro)
O próprio navegador já é uma espécie de app store, então na prática já rodamos apps ali o tempo todo sem revisão da Apple. Nesse contexto, nunca entendi muito bem por que a Apple e seus fãs enfatizam tanto a segurança da App Store
Se JIT for permitido, não é só uma questão de emulação mais rápida; também melhora a eficiência por não precisar ficar girando em interpretador, o que pode ajudar tanto na bateria quanto no aquecimento do telefone ao rodar jogos de 2008
(opinião sem sentido omitida)
Se interpretarmos “possibilidade de bloqueio” de forma ampla, por exemplo, “colocar bloqueio regional para que motores de navegador alternativos só possam ser lançados para contas Apple do Japão” também pode ser considerado, em essência, uma forma de impedir a existência prática de navegadores alternativos. Nesse caso, a Mozilla também não teria motivo para portar o Firefox para iOS, porque o público-alvo seria pequeno demais. É improvável, mas talvez isso possa ser um pequeno começo para a liberdade global de escolha de navegadores
Fazer bloqueio regional e permitir motores alternativos só para contas específicas é uma das coisas que a Apple está fazendo na UE
Pelo que sei, o Gecko (motor do Firefox) já foi portado para iOS
A participação de mercado já é pequena por natureza; fico em dúvida se vale portar só para aumentar um pouquinho esse número minúsculo
A Mozilla já está acostumada a trabalhar com baixa participação de mercado. Isso não seria tão diferente, e talvez até sirva como oportunidade de distribuir uma versão de QA para usuários antes da abertura maior do mercado
Depois da UE e do Reino Unido, agora o Japão também está encerrando a proibição de motores de navegador alternativos no iOS. Como os três são mercados grandes, fico curioso se isso já cria incentivo suficiente para Chrome e Firefox investirem em versões do iOS com seus próprios motores — isto é, navegadores baseados em Blink e Gecko. Há muitos rumores de que o desenvolvimento ficou travado por causa disso até aqui
Vi no mesmo site que a Apple continua fazendo de tudo para impedir que grandes fabricantes de navegador lancem seus próprios motores blog relacionado
No caso do Reino Unido, pelo que sei, o governo vem aplicando de forma pouco enérgica leis relacionadas, como o Digital Markets Act de 2024
Pela cultura japonesa, talvez esse tipo de mudança nem gere tanta preocupação. Basta ver o uso de Linux no Japão: os poucos usuários entusiastas continuam usando de qualquer jeito, mas o público geral só usa o que for mais conveniente. Não gostam muito de mexer no sistema nem ficar alterando configurações
Também existe a visão de que ninguém conseguiu superar essa barreira porque a Apple torna a vida dos desenvolvedores de navegador extremamente difícil
Fico pensando se não seria mais realista e fácil o Firefox mudar para Blink e cooperar com o Google para criar um motor alternativo para iOS
Fico me perguntando se essa mudança é realmente boa. Não acaba aumentando ainda mais a fatia do Chromium no mercado?
O Safari não é estruturalmente um bom navegador. Por interesse próprio, a Apple enfraquece deliberadamente a plataforma web. Se não houver navegadores realmente competitivos, não dá para obrigar os usuários a usá-lo; concorrência de verdade é criar um navegador genuinamente bom que as pessoas escolham por vontade própria
É verdade. No fim, o Safari era a última linha de defesa contra a web inteira no iOS virar "All Chrome Everywhere"
O governo pode resolver monopólios de mercado wiki do processo do DOJ dos EUA contra o Google
Exato, por isso o dilema é complicado. Por um lado, a Apple realmente precisa ser forçada a abrir mais o iOS; por outro, isso acaba fortalecendo o monopólio do Chrome
O grande benefício é poder usar um Firefox de verdade no iOS. E isso é uma mudança positiva. A influência indevida da Apple em reduzir padrões da web para atender aos próprios interesses (por exemplo, atrapalhando o suporte a SPIR-V no WebGPU) diminui
(Narrador) Um ano depois, a participação do Chrome no Japão chegou a 100%, e todos os sites passaram a ser feitos exclusivamente para esse navegador
O Japão tem uma relação peculiar com a Apple. Por exemplo, recursos de bilhetagem baseados em FeliCa (o sistema NFC japonês) vêm integrados a todos os iPhones, o que permite que usuários de iOS do mundo todo tenham uma vida muito mais prática no Japão. Mais surpreendente ainda é que, para usar os bilhetes de fato, não é necessário app algum; basta ter o Apple Pay. Esse movimento vai reduzindo cada vez mais as vantagens próprias dos apps nativos (embora eles ainda tenham pontos fortes exclusivos), mas, ao mesmo tempo, fica difícil rebater a ideia de que a Apple apenas transfere seu papel de “porteira” para outras áreas
O suporte à rede FeliCa existe principalmente porque tecnologias de transporte e pagamento móvel já estavam estabelecidas no Japão antes do iPhone. Como já existiam Mobile Suica e Osaifu-Keitai, a Apple precisava correr atrás de forma agressiva para se manter competitiva. Começou com SKUs de iPhone exclusivos para o Japão e depois foi expandido globalmente. Mesmo hoje, o mercado de pagamentos móveis no Japão não é monopolizado. Quando a Apple sofre pressão competitiva, mudanças acontecem, como a adição de recursos como o Express Transit do Suica. E apps japoneses de pagamento por QR code, como o PayPay, são mais difundidos do que pagamentos com cartão de crédito
A participação do iOS no Japão é ainda maior do que nos EUA (59%), no Reino Unido (47%) e na Europa (34%): é de 64% fonte Statcounter
FeliCa é uma questão de licenciamento de patentes. A Apple aparentemente conseguiu um contrato vantajoso em algum momento. O Google Pixel também vem com o chip em todos os aparelhos, mas em modelos que não são do Japão esse recurso é bloqueado por software (dá para desbloquear com root)
Dá para sentir o poder do “ser possível”. Quando um país consegue fazer isso, outros países que passaram 20 anos dizendo que era impossível começam a mudar com a mentalidade de “nós também podemos, não dá para ficar para trás”
É inevitável supor que o Google vem se preparando há tempo para lançar o Chrome “de verdade” no iOS. Provavelmente eles já vêm construindo isso há bastante tempo para lançar assim que a lei mudar, certo?
O Google está portando o Blink (motor do Chrome para iOS), e o progresso vem avançando aos poucos. Há um rastreamento no bug tracker do Chromium link de rastreamento. Provavelmente, por causa da política de bloqueio regional da Apple (geofencing na UE) e das várias limitações do BrowserEngineKit, ainda não houve muito investimento de recursos para levar isso a produção
Fevereiro de 2023: “Google começa a trabalhar para rodar o Chrome no iOS com o motor Blink em vez do Apple WebKit” matéria relacionada
(Blink é o motor de renderização web do Chrome) Na documentação oficial de como compilar Chromium/Chrome para iOS, há um aviso dizendo que a “blink web platform” é experimental e deve ser usada apenas para análise. Também é mencionado que os alvos
content_shellechromesão úteis para isso. documentação oficial de build