Japón: Apple debe levantar la prohibición de motores de navegador antes de diciembre
(open-web-advocacy.org)- El gobierno de Japón aprobó recientemente la Ley de Smartphones, que prohíbe directamente que Apple mantenga en iOS la prohibición de motores de navegador de terceros
- Hasta ahora, la exigencia de usar el motor WebKit bloqueaba de facto la competencia entre navegadores en iOS y reducía la competitividad de las web apps
- Las nuevas directrices especifican que Apple tampoco podrá imponer obstáculos técnica o comercialmente inviables
- Además, el acceso a las API del sistema operativo para los navegadores deberá garantizarse con equivalencia funcional, y no se permitirá una degradación discriminatoria del rendimiento
- Con la entrada en vigor de esta ley en Japón, junto con la UE y el Reino Unido, se está formando un entorno regulatorio para restaurar la competencia entre navegadores, y se perfila que 2026 será un punto de inflexión
Japón exige a Apple levantar la prohibición de motores de navegador
Japón aprobó recientemente de forma oficial la “Ley para la Promoción de la Competencia en el Software para Smartphones”, implementando una medida que prohíbe directamente la antigua política de Apple de vetar motores de navegador de terceros en iOS.
Estado actual de la prohibición de motores de navegador
- Hasta ahora, Apple solo permitía el uso del motor WebKit, lo que en la práctica excluía de iOS a todos los principales motores de navegador de Firefox, Chrome, Edge, Opera, Brave, Vivaldi y otros
- Esto bloqueaba en la práctica la competencia entre navegadores y provocaba una situación en la que las web apps no podían usar las API ni el rendimiento necesarios para competir en igualdad de condiciones con las apps nativas
Legislación y directrices en Japón
- Esta ley fue diseñada con base en un informe de la Oficina para la Competencia en Mercados Digitales, e incorporó también asesoría de Open Web Advocacy
- Recientemente se publicaron las directrices de la Ley de Competencia de Software Móvil (MSCA), que aclaran cómo se interpretará y aplicará realmente la ley
Prohibición de obstaculizar motores de navegador alternativos
- Las directrices prohíben explícitamente cualquier acto que obstaculice o perjudique la introducción de motores de navegador de terceros
- Esto incluye imponer restricciones técnicas excesivas a los proveedores de apps, trasladarles costos, o adoptar medidas que alejen a los usuarios de los navegadores alternativos
- Al determinar si existe una obstrucción, no solo cuenta el caso en que el proveedor la prohíba de forma explícita, sino también cuando la posibilidad real de adopción se vuelva notablemente baja
- Esta disposición significa que no se permitirá que Apple los autorice solo de manera nominal mientras en la práctica sigan siendo inutilizables o carezcan de sentido comercial
Equivalencia funcional en el acceso a las API del sistema operativo
- La MSCA establece que el acceso a las API del sistema operativo debe garantizarse con acceso funcionalmente equivalente
- Se permite ofrecer API alternativas, pero si su rendimiento es sustancialmente inferior en la práctica, no se considerará una equivalencia funcional
- Es decir, aunque el enfoque técnico sea distinto, los navegadores de terceros también deben tener garantizados el mismo nivel de rendimiento y accesibilidad del que disfrutan Apple y otros proveedores designados
Obligación de mostrar una pantalla de elección de navegador (Choice Screen)
- La ley obliga a ofrecer una pantalla de elección (Choice Screen) para navegadores (y otro software)
- Las directrices son más estrictas que en la UE: la pantalla de elección debe mostrarse inmediatamente “justo después de la activación inicial”
- Ya sea durante la configuración inicial del smartphone o al abrir por primera vez la app correspondiente, se debe inducir al usuario a elegir un software específico
Próximos movimientos
- Está previsto que la Ley de Competencia de Software Móvil entre en vigor en diciembre de 2025
- Japón se suma a la UE y al Reino Unido como jurisdicciones donde Apple deberá permitir motores de navegador de terceros
- Se espera que Japón prepare su aplicación tomando como referencia la experiencia regulatoria de Europa y el Reino Unido
- Como muestran los casos de la UE y el Reino Unido, la aplicación efectiva probablemente será un proceso largo y complejo
Conclusión e implicaciones
- Japón, la UE y el Reino Unido están impulsando la restauración de una competencia real entre navegadores en iOS al obligar a Apple a dar soporte a motores de navegador de terceros
- Es posible que 2026 marque un punto de inflexión en la estructura del mercado de navegadores
- El resultado final dependerá de la voluntad de aplicación de los reguladores y de los esfuerzos reales de Apple por introducir mejoras sustanciales
- Se destaca el papel del gobierno japonés y de las organizaciones relacionadas, que durante mucho tiempo han trabajado para mejorar el entorno competitivo de navegadores y web apps
7 comentarios
Mmm... a mí me parece una lástima, porque cuando todas las funciones de navegación pasan por una biblioteca base, si el sistema bloquea una URL, se mantiene una buena consistencia imposible de eludir en las funciones de navegación interna de todas las apps.
Se espera un fuerte avance de los navegadores con IA.
Desde la perspectiva de los desarrolladores, esto probablemente significa que habrá aún más entornos que tener en cuenta jaja..
Ahora sí hay que desarrollar siguiendo los estándares web. Y mejor no usar activamente las funciones que no existen.
Parece que hay muchos, pero al final, ¿no son Firefox y el motor de Chromium?
Con solo ver la lista de motores mencionados en el estado de la prohibición, ya me mareo @_@
Opinión de Hacker News
Todos están hablando de Chrome, pero yo tengo Chrome desactivado en Android y uso Firefox. Si le pones uBlock Origin a Firefox móvil, la experiencia se siente casi como la web de escritorio. No solo por el bloqueo de anuncios, sino porque también puedes bloquear al instante elementos que no te interesan con reglas RegEx como
:has-text. Chrome ya ni siquiera puede hacer eso en escritorio. Incluso he pensado en cambiarme por completo a Android como dispositivo principal. Pero la comodidad de poder responder chats directo desde la MacBook por iMessage es demasiado grande como para dejarlo tan fácil. Fuera de eso, Android es mucho mejor en general. Ni hablemos del teclado de iOS o de SiriLa combinación de FF con uBO es la killer app que me mantiene en Android. Si Apple hubiera permitido eso, me habría cambiado hace mucho. ¿Has considerado messages.google.com? Necesitas la app de mensajes de Google (no Samsung Messages), y te deja usar SMS y RCS en escritorio, así que funciona perfecto como reemplazo de iMessage
La extensión consent-o-matic en Firefox móvil también vale muchísimo la pena. Hace clic automáticamente en casi todos los banners de cookies, así que no tienes que estar lidiando con eso a cada rato en móvil y es mucho más cómodo
Yo también uso https://messages.google.com para armar una experiencia tipo iMessage de escritorio basada en Android. Tal vez también te sirva para tu caso. Aunque no uso iMessage, así que puede que no lo sepa bien
Si puedes vivir sin iMessage y te basta con SMS, KDE Connect permite mensajería de escritorio excelente desde Android (se puede usar en Linux, Windows y macOS; hay diferencias de funciones según la plataforma, pero todos soportan SMS). https://kdeconnect.kde.org/
Parece que Japón aprendió de los casos de “cumplimiento tramposo” que Apple mostró en la UE. Si vuelven a salir con algo así, ojalá que en Japón también les caiga una multa de verdad que sí les pegue. Yo creo que no es cuestión de "if", sino de "when"
A veces hasta imagino una prohibición de venta e importación; me pregunto cuánto tiempo tendría que cerrar la Apple Store para que Apple se arrodille
A mí me gusta el walled garden que evita que yo mismo meta la pata. También agradezco que Apple no ande regalando mis coordenadas ni que algún Monarch raro me esté rastreando, así que me preocupa menos la privacidad. (+4500 upvotes) En Reddit siempre me parecían sospechosos esos titulares anti-Apple con +30 mil votos, mientras que los comentarios pro-Apple recibían muchísimo menos en comparación. Me hacía pensar si no habría equipos de marketing o granjas de trolls haciendo gestión de reputación
Si este movimiento legislativo global termina llevando a un ecosistema de apps más abierto en iOS, sería algo realmente bienvenido. BrowserEngineKit no es más que un wrapper delgado sobre XPC y el sistema de extensiones de iOS. Si XPC fuera una API abierta, y Apple permitiera JIT en subprocesos aislados sin necesidad de su permiso, sería mucho mejor para desarrollar. Por ejemplo, una app de mensajería podría tener un subproceso aparte para manejar entradas no confiables (iMessage ya hace eso), se podrían aislar componentes inestables de una app para mejorar la usabilidad o la recuperación tras un crash, los emuladores de sistemas retro serían mucho más rápidos, también sería posible aprovechar WASM en iOS, y los navegadores podrían usar XPC sin necesidad de APIs especiales. El problema es que, si esto fuera posible, sería fácil cargar dentro de una app código que corre a velocidad nativa incluso después de pasar la revisión de la App Store, y ya sabemos que, según algunos, si llega ese mundo sería un desastre
Cuando llegue ese “desastre”, me gustaría ver el caos en sitios como MacRumors. Cuesta ser tan ingenuo como para pensar que Apple no patrocina la promoción de sitios que empujan narrativas en internet para su propio beneficio económico. Por ejemplo, se repite prácticamente todo el tiempo la idea absurda de que la libertad de usar tu teléfono libremente amenaza la seguridad y la privacidad de todos
Si se hace así, una gran parte de la carga de prevenir malware a nivel sistema pasaría al sandbox de las apps. De hecho, incluso hoy el sandbox es solo una de varias capas de defensa, junto con la notarización, los permisos, la revisión de apps y demás. Yo también estoy a favor de que la gente instale las apps que quiera, pero también hay que reconocer que eso dejaría al iPhone común más expuesto al malware, como pasa en Android. Detrás de esta política de Apple no solo hay deseo monopolístico; también hay preocupaciones de seguridad reales (aunque probablemente el motor principal sí sea la ganancia)
El navegador en sí también es una especie de tienda de apps, así que en la práctica ya estamos corriendo apps desde ahí todo el tiempo sin revisión de Apple. En ese contexto, no entiendo muy bien por qué Apple y sus fans insisten tanto en la seguridad de la App Store
Permitir JIT no solo se quedaría en emulación más rápida; también mejoraría la eficiencia al no tener que dar tantas vueltas con intérpretes, y podría ayudar tanto con la batería como con el calentamiento del teléfono al correr juegos de 2008
(Se omite una opinión sin sentido)
Si se interpreta ampliamente la “posibilidad de bloqueo”, entonces, por ejemplo, algo como “poner region lock para que los motores de navegador alternativos solo puedan lanzarse para cuentas japonesas de Apple” también podría considerarse, en esencia, una forma de impedir la existencia real de navegadores alternativos. Si fuera así, para Mozilla el público objetivo sería tan pequeño que no valdría la pena portar Firefox a iOS. No parece muy probable, pero quizá esto podría ser un pequeño punto de partida para la libertad de elegir navegador a nivel global
Poner region lock para permitir motores alternativos de navegador solo a ciertas cuentas es una de las cosas que Apple está haciendo en la UE
Tengo entendido que Gecko (el motor de Firefox) ya fue porteado a iOS
Su cuota de mercado ya es baja de por sí, así que no sé si valga la pena portarlo para sumar apenas un grupo diminuto más
Mozilla es una organización acostumbrada a tener una cuota pequeña. Esta situación tampoco sería tan distinta, y hasta podría servir como oportunidad para distribuir una versión QA con usuarios antes de una apertura de mercado más amplia
Después de la UE y el Reino Unido, ahora Japón también le pone fin a la prohibición de motores de navegador alternativos en iOS. Como los tres son mercados grandes, me pregunto si eso ya da suficiente incentivo para que Chrome o Firefox inviertan en versiones para iOS con sus propios motores (es decir, navegadores basados en Blink y Gecko). Ha habido muchos rumores de que el desarrollo se ha retrasado por esta razón
En el mismo sitio vi que Apple sigue poniendo todo tipo de obstáculos para que los grandes fabricantes de navegadores no puedan sacar su propio motor blog relacionado
En el caso del Reino Unido, entiendo que se dice que el gobierno ha hecho una aplicación poco activa de leyes relacionadas, como la Digital Markets Act de 2024
Por la cultura japonesa, probablemente este cambio no les quite mucho el sueño. Basta ver el uso de Linux en Japón: los usuarios intensos de nicho lo seguirán usando pase lo que pase, pero el público general simplemente usa lo que le resulta cómodo. No les gusta mucho meterse a modificar el sistema o la configuración
También hay quien lo ve como que Apple les ha hecho la vida tan difícil a los desarrolladores de navegadores que nadie ha podido superar esa barrera
Me pregunto si una opción más realista y fácil no sería que Firefox se cambiara a Blink y colaborara con Google para crear un motor alternativo para iOS
Me pregunto si este cambio realmente es algo bueno. También me preocupa si no terminará aumentando todavía más la cuota de Chromium en el mercado
Safari no es estructuralmente un buen navegador. Por los intereses de Apple, debilita deliberadamente la plataforma web. Si no son navegadores competitivos de verdad, no puedes obligar a los usuarios a usarlos; la competencia real del mercado es crear navegadores realmente buenos que la gente elija por decisión propia
Sí, eso es cierto. Al final, Safari era el último bastión que impedía que toda la web en iOS se convirtiera en "All Chrome Everywhere"
El gobierno podría resolver la dominación del mercado wiki de la demanda del DOJ de EE. UU. contra Google
Exacto, por eso el dilema es complicado. Por un lado, Apple sí debe verse obligada a abrir más iOS, pero por otro, eso termina fortaleciendo el monopolio de Chrome
La ventaja de poder usar un Firefox de verdad en iOS es grande. Y este es un cambio positivo. Reduce la influencia injustificada de Apple cuando recorta estándares web por su propio beneficio (por ejemplo, obstaculizar el soporte de SPIR-V en WebGPU)
(Narrador) Un año después, en Japón la cuota de Chrome llegó al 100% y todos los sitios web estaban diseñados exclusivamente para ese navegador
Japón tiene una relación particular con Apple. Por ejemplo, la función de boletos basada en Felica (el sistema NFC japonés) viene integrada en todos los iPhone, y eso hace que incluso usuarios de iOS del resto del mundo puedan vivir mucho más cómodamente en Japón. Lo más sorprendente es que para usar esos boletos ni siquiera hace falta ninguna app; basta con Apple Pay. Este tipo de evolución va reduciendo cada vez más las ventajas propias de las apps nativas (aunque todavía conservan ventajas únicas), pero por otro lado se vuelve difícil refutar la idea de que Apple simplemente está trasladando su papel de “gatekeeper” a otras áreas
El soporte para la red FeliCa se debe principalmente a que en Japón la tecnología de transporte y pagos móviles se estableció antes que el iPhone. Ya existían Mobile Suica y Osaifu-Keitai, así que Apple tuvo que sumarse de forma agresiva si quería seguir siendo competitiva. Empezó con iPhones SKU exclusivos para Japón y luego se expandió globalmente. Incluso ahora, en Japón el mercado de pagos móviles no es un monopolio. Cuando Apple siente presión competitiva, hay cambios, como añadir Express Transit para Suica. Y además, apps japonesas de pago con código QR como PayPay están más difundidas que los pagos con tarjeta de crédito
La cuota de iOS en Japón es incluso más alta que en EE. UU. (59%), el Reino Unido (47%) o Europa (34%): es de 64% fuente de statcounter
FeliCa es un tema de licencias de patentes. Parece que Apple consiguió un contrato favorable en algún momento. Los Google Pixel también traen el chip, pero si no son modelos japoneses esa función está bloqueada por software (aunque se puede habilitar con root)
Uno siente el poder de la frase “poder hacerlo”. Cuando un país lo logra, otros países que durante 20 años decían que era imposible empiezan a cambiar pensando “nosotros también podemos hacerlo y no podemos quedarnos atrás”
Hay que asumir que Google lleva tiempo preparándose de forma constante para lanzar el Chrome “de verdad” en iOS. Seguramente lo vienen haciendo desde hace tiempo para sacarlo apenas cambie la ley, ¿no?
Google está portando Blink (el motor de Chrome para iOS) y ha ido avanzando poco a poco. Hay un seguimiento en el bug tracker de Chromium enlace de seguimiento. Probablemente, por las políticas de bloqueo regional de Apple (geofencing en la UE) y varias limitaciones de BrowserEngineKit, todavía no le han asignado todos los recursos para un servicio real
Febrero de 2023: “Google comienza a trabajar para ejecutar Chrome en iOS con el motor Blink en lugar de Apple WebKit” artículo relacionado
(Blink es el motor de renderizado web de Chrome). En la documentación oficial sobre cómo compilar Chromium/Chrome para iOS, se indica que la ‘blink web platform’ es experimental y debe usarse solo con fines de análisis. También se menciona que los targets relacionados
content_shellychromeson útiles. documentación oficial de compilación