Tim Sweeney: Apple perjudica las web apps del iPhone en la UE de forma anticompetitiva
(techcrunch.com)- Tras el recorte de la función de web apps en la pantalla de inicio del iPhone como respuesta a la Digital Markets Act (DMA) de la UE, el CEO de Epic Games, Tim Sweeney, cuestionó si Apple no está intentando frenar las PWA, que podrían amenazar los ingresos de la App Store
- Apple explicó que, por la DMA, debe permitir motores de navegador alternativos además de WebKit, y que el modelo de seguridad de las web apps existentes en la pantalla de inicio dependía de WebKit
- Se confirmó que el problema por el que las PWA no funcionan correctamente en la beta de iOS para la UE no era un simple bug, sino un cambio intencional de Apple, y las web apps pasaron a parecerse más a marcadores de sitios web, perdiendo almacenamiento local, badges, notificaciones y ventana dedicada
- Apple señaló que, para ofrecer soporte seguro a web apps basadas en motores de navegador alternativos, se necesitaría una nueva arquitectura de integración que no existe en iOS, pero que no la implementó por la carga que ya implica cumplir con la DMA y por el bajo nivel de uso
- Si los navegadores competidores soportan las PWA mejor que Safari, las web apps podrían convertirse en un competidor “no gravado” de las apps nativas, lo que pone en conflicto la explicación de seguridad de Apple con las perspectivas de crecimiento del mercado de PWA
Web apps del iPhone reducidas en la UE
- Apple confirmó que redujo deliberadamente la funcionalidad de las web apps del iPhone en la UE, alegando cumplimiento de la DMA
- El problema salió a la luz recientemente cuando las progressive web apps (PWA) dejaron de funcionar con normalidad en la beta de iOS para la UE
- Al principio se habló de la posibilidad de que fuera un bug de la beta, pero Apple aclaró que no era un simple error, sino un cambio de política
- La explicación correspondiente se agregó a la página de soporte para desarrolladores sobre la DMA
La lógica de Apple: un modelo de seguridad basado en WebKit
- La DMA exige que Apple soporte otros motores de navegador web además de WebKit en Safari
- Las web apps existentes en la pantalla de inicio de iOS han funcionado bajo el supuesto de WebKit y su arquitectura de seguridad
- aislamiento del almacenamiento
- obligación de mostrar prompts del sistema al acceder a funciones que afectan la privacidad
- Apple explicó que, sin ese aislamiento y esas restricciones, una web app maliciosa podría leer datos de otras apps o acceder a la cámara, el micrófono o la ubicación aprovechándose del consentimiento del usuario
- Como resultado, la experiencia de las web apps en iOS para usuarios de la UE se redujo drásticamente, y en la práctica las web apps pasaron a comportarse como marcadores de sitios web
- sin soporte para almacenamiento local
- sin soporte para badges
- sin soporte para notificaciones
- sin soporte para ventana dedicada
La réplica de Tim Sweeney: las PWA como competidor potencial de la App Store
- El CEO de Epic Games, Tim Sweeney, publicó en X que la razón real de Apple podría ser que las web apps del iPhone no le generan ingresos
- Sweeney tiene un interés claro en este tema, ya que es el CEO de Epic Games, empresa que demandó a Apple por cuestiones antimonopolio relacionadas con las comisiones de la App Store
- El punto en disputa es si la decisión de Apple busca proteger la seguridad de los usuarios o si se trata de una elección para reducir una amenaza potencial a su negocio
- Sweeney cree que los navegadores rivales podrían ofrecer un soporte mucho mejor para las PWA que las capacidades web limitadas de Safari, y que en ese caso las PWA podrían convertirse en un “competidor legal y no gravado” de las apps nativas
Hay una solución técnica, pero su implementación queda en pausa
- Apple reconoció que existe una forma técnica de resolver los problemas de seguridad y privacidad de las web apps que usan motores de navegador alternativos
- Sin embargo, para ello tendría que construir una arquitectura de integración completamente nueva que hoy no existe en iOS
- Apple afirmó que cumplir con la DMA ya requirió “más de 600 nuevas APIs y diversas herramientas para desarrolladores”, y consideró que construir esa arquitectura no era práctico debido al muy bajo nivel de uso de las web apps en la pantalla de inicio
- Como la DMA es una regulación que lleva años preparándose, no es que Apple no pudiera prever este cambio
Choque entre el argumento de bajo uso y las perspectivas de crecimiento de las PWA
- Apple minimiza el impacto del recorte de funciones argumentando que las web apps en la pantalla de inicio tienen un uso muy bajo
- Sin embargo, en el pasado Apple fue agregando funciones para que las PWA pudieran comportarse como apps nativas y distribuirse fácilmente fuera de la App Store
- Las proyecciones del mercado de PWA apuntan en una dirección distinta a la lógica de bajo uso de Apple
- analistas estiman que el mercado de PWA alcanzará los 10.44 mil millones de dólares en 2027
- la tasa de crecimiento anual compuesta sería de 31.9%
- Si los motores de navegador alternativos logran hacer más útiles a las PWA, las web apps podrían convertirse en una amenaza directa para el negocio de la App Store
- Apple no respondió por separado a las solicitudes de comentario sobre su decisión respecto a las PWA, y en cambio publicó su explicación en el sitio web sobre la DMA
1 comentarios
Opiniones de Hacker News
Él tiene razón. Apple lleva años frenando el avance de las apps web en iOS, e intentó mantener su comisión del 30% impidiendo que las apps web compitieran con las apps nativas de la App Store.
Ahora que Apple tiene que permitir motores de navegador de terceros, las apps web podrían volverse mucho más potentes, pero Apple decidió no aceptarlo y, en cambio, desactivar una función útil para todos.
Creo que esto le va a salir mal, y degradar sus propias funciones para molestar a los competidores solo aumentará el rechazo de usuarios, empresas, desarrolladores y legisladores. Su propuesta de cumplimiento de la Digital Markets Act también está cerca de no cumplir: la DMA exige interoperabilidad libre, pero Apple le puso una tarifa extremadamente anticompetitiva. Si se elimina eso, los desarrolladores podrán distribuir libremente las apps nativas que quieran y, a estas alturas, habrá muchos desarrolladores que se muden a otras tiendas de apps.
La gente simplemente va a la App Store y descarga apps de sitios web al azar, y no le importa si en realidad solo son apps de navegador que renderizan un sitio web. Para que haya un boicot a Apple, tendrían que quitar algo que a la gente sí le importe de verdad.
Aun sabiendo que esta función existe, e incluso habiendo escrito código que la soporta, me tomó casi 5 minutos encontrar el botón. Es realmente tonto que lo hayan escondido dentro de la hoja de compartir.
Apple ha impulsado muchas funciones web que hacen que la web se sienta más como apps nativas, y en muchos casos creó especificaciones o las adoptó antes que otros. Creo que cosas como backdrop-filter, position: sticky y los puntos de ajuste de CSS contribuyen mucho más a que los sitios web se vean como apps nativas que funciones como WebMIDI.
En sus respuestas recientes relacionadas con la DMA hay mucho cumplimiento malicioso y mezquindad, pero no creo que eliminar los marcadores de pantalla de inicio sin chrome haya sido una de ellas. Más bien hicieron una interpretación estricta de la norma y, como no estaban muy apegados a esa función, simplemente la eliminaron.
Apple parece tener una filosofía y prioridades distintas para la plataforma web, con más énfasis que Chrome en privacidad, rendimiento y eficiencia.
En los comentarios que leí, mucha gente quisiera que la DMA exigiera interoperabilidad gratuita, pero no sé si realmente dice eso. Más bien parece permitir, hasta cierto punto de forma explícita, que los gatekeepers sigan cobrando costos de acceso.
El considerando 62 empieza diciendo: “En relación con las tiendas de aplicaciones de software, los motores de búsqueda en línea y los servicios de redes sociales en línea incluidos en la decisión de designación, los gatekeepers deben publicar y aplicar condiciones generales de acceso justas, razonables y no discriminatorias”, así que este punto trata sobre las tiendas de apps.
El segundo párrafo comienza: “Los precios u otras condiciones generales de acceso deben considerarse injustos si generan un desequilibrio entre los derechos y obligaciones impuestos a los usuarios empresariales, o si confieren al gatekeeper una ventaja que no guarda proporción con el servicio que presta a los usuarios empresariales, o si generan una desventaja para los usuarios empresariales al prestar los mismos servicios o servicios similares que el gatekeeper”.
A mí ese texto me parece indicar que, como mínimo, contempla la posibilidad de cobrar. Me gustaría saber en qué parte de https://eur-lex.europa.eu/eli/reg/2022/1925/oj se exige “interoperabilidad gratuita”.
Si te refieres al artículo 6.7, no estoy de acuerdo. En mi opinión solo cubre cosas como acceso al SDK, especificaciones de puertos del dispositivo y la capacidad de hacer llamadas al sistema como las aplicaciones del gatekeeper.
El artículo 6.7 dice: “El gatekeeper deberá permitir a los proveedores de servicios y a los proveedores de hardware, de forma gratuita y efectiva, la interoperabilidad con, y el acceso para fines de interoperabilidad a, las mismas funciones de hardware y software a las que se accede o que se controlan a través del sistema operativo o el asistente virtual incluidos en la decisión de designación conforme al artículo 3, apartado 9, y que estén disponibles para los servicios o hardware prestados por el gatekeeper. Además, el gatekeeper deberá permitir a los usuarios empresariales y a los proveedores alternativos de servicios prestados junto con los servicios básicos de plataforma o en apoyo de estos, de forma gratuita y efectiva, la interoperabilidad con, y el acceso para fines de interoperabilidad a, las mismas funciones del sistema operativo, hardware o software que estén disponibles para el gatekeeper o que este utilice al prestar dichos servicios, independientemente de si esas funciones forman parte del sistema operativo”.
Pero con medidas como esta y viendo la dirección en la que Apple está llevando SwiftUI, más bien me está volviendo a interesar las apps web.
Desde la perspectiva de Apple, es enormemente conveniente que las funciones de seguridad y el comportamiento anticompetitivo se superpongan.
Cuando alguien dice “no me gusta el lock-in de proveedor”, Apple de inmediato lo da vuelta como “¿entonces no te importa la seguridad?”
Pero muchas veces esa es una falsa dicotomía creada por Apple. Está bien revisar y rechazar apps para evitar fraudes y malware, pero Apple mezcló eso con rechazar una app por usar la palabra “Android” o con hacer la curaduría que ellos quieren.
La interfaz de suscripción de un toque incluida por defecto es segura y cómoda para el usuario, pero gracias al duopolio móvil y al control de la plataforma pueden cobrar lo que quieran. Apple habla como si permitir otros procesadores de pago llevara a sitios web sospechosos donde no se pueden cancelar suscripciones ni pedir reembolsos, pero esa también es una falsa dicotomía creada por Apple. Podrían exigir que, para usar un procesador de pago alternativo, se integre con la API de gestión de suscripciones de iOS, y ya soportan PayPal como backend.
Con esto pasa lo mismo: a Apple le resulta demasiado conveniente que abrir APIs internas a terceros sin protecciones sea peligroso. Pero no hace falta ejecutar navegadores de terceros sin sandbox, ni permitir que cualquier app cree iconos en la pantalla de inicio a su antojo. Agregar a la pantalla de inicio ya es una acción del usuario mediante la hoja de compartir y está mediada por el sistema operativo. Los navegadores, de todos modos, deben estar dentro de un sandbox, y las web apps ya tenían permitido ejecutarse en pantalla completa.
Esto no es simplemente que falte una función. Durante años Apple sostuvo que la App Store no era indispensable y que cualquiera podía crear una web app. Debido a las restricciones de Safari, eso nunca fue del todo cierto desde el principio, pero ahora ya es simplemente una farsa.
“En cambio, la app fraudulenta LassPass te induce a crear una suscripción de cuenta ‘pro’ de US$2 al mes, US$10 al año o US$50 de por vida. Para ser una app fraudulenta, en realidad es un precio bajo. Muchas apps fraudulentas intentan cobrar tarifas como US$10 por semana”.
Además, sin tener forma de saberlo, afirmó que “no parece haber sido creada para robar credenciales de LastPass”. Todo el texto tenía el tono de “sí, es algo malo y no debería pasar, pero no es para tanto. ¿Por qué le reclaman tanto a Apple?”.
¿Apple cree que estas jugarretas van a provocar rechazo contra la regulación de la UE?
Cada vez que leo una nueva estupidez, me hierve la sangre, y mi postura frente a Apple y otras grandes empresas anticompetitivas se vuelve más dura.
Las cosas por las que debería hervirte la sangre son las que no puedes evitar fácilmente en tu vida. Al final, esto no es más que un teléfono y una computadora, y estás gastando tu pasión en algo completamente inútil.
Ojalá la gente que se queja de Apple, en vez de lloriquear, hiciera una huelga y dejara de desarrollar para hardware de Apple.
Mejor aún, que construyan su propio hardware sin toda esa carga de software; muchas de las empresas que se quejan valen miles de millones de dólares, así que podrían permitírselo.
Claro que no lo harán, porque igual que Apple también quieren dinero. Aun así, si Spotify, Epic y otras dejaran de dar soporte a dispositivos iOS, Apple consideraría cambiar su comportamiento.
Si desarrolladores y usuarios se pasan a Android, Apple cambiará. ¿Android es realmente tan malo como para estar obligado a usar iOS?
Es como que a nadie le gusta mantener cinco suscripciones para acceder a Netflix, HBO, Prime, Disney y Hulu. Ya es un milagro que al menos haya un duopolio en vez de un monopolio.
Estas personas no asumen ni la más mínima responsabilidad y simplemente siguen comprando esa maldita cosa.
Para mí, la parte clave es: “Ahora las web apps se comportan como marcadores de sitios web, sin soporte para almacenamiento local, insignias, notificaciones ni ventanas dedicadas”.
No es que el acceso desde la pantalla de inicio esté completamente bloqueado. Mi web app simple puede vivir sin notificaciones ni almacenamiento local.
Pero mucha gente necesita aplicaciones web progresivas, así que entiendo que este cambio sea especialmente perverso para ellos.
Esto claramente es una maldad descarada de Apple, así que parece que llegó el momento de cambiar el hardware que llevamos en el bolsillo si queremos apoyar software justo y amigable.
Un sitio web en modo independiente es una “app” web, pero si no puede quitar la barra del navegador aunque use todas las funciones web modernas, entonces en Safari no son posibles las web apps. Eso es solo un acceso directo a un sitio web en modo pestaña.
Además, todavía no sabemos qué funciones web planea prohibir Apple en los sitios web, ni si también estarán prohibidas en navegadores competidores.
Tampoco está claro si serán posibles los sitios web offline que usan caché con service workers. Según algunos beta testers, parece estar desactivado.
Puede que personalmente el almacenamiento local no te importe, pero hay que pensar en cuánta desventaja representa para la programación web que Apple borre el almacenamiento local sin permiso del usuario, como hace en las pestañas de Safari.
La falta de garantías a futuro es uno de los mayores problemas. La programación web es una estrategia que las empresas eligen ahora para poder lanzar buenas web apps dentro de 2 o 3 años.
Supongamos que Apple hubiera dejado las PWA sin ningún cambio, es decir, hardcodeadas en Safari. ¿Mozilla o Microsoft no habrían demandado o cuestionado de inmediato a Apple por violar la DMA, porque no podrían ejecutar su propio motor de navegador desde los íconos de la pantalla de inicio agregados por el usuario?
Entonces, dejar las PWA existentes tal cual habría implicado asumir en la UE el riesgo de multas astronómicas, ¿no?
Si los desarrolladores de iOS son tan malos, podían pagarles a los desarrolladores de macOS para que implementaran los cambios necesarios en un fin de semana. Ambos sistemas operativos son de la familia Unix y en macOS es totalmente posible; Apple tuvo años para hacerlo.
Si Apple quiere jugar la carta de “es demasiado difícil”, según la DMA debería demostrar por qué es una carga tan grande. Pero en realidad no lo es, así que no puede demostrarlo. Aun así, podría haber negociado con la UE una excepción para no romper las apps web de Safari hasta que todos los navegadores web estuvieran listos para usar apps web en iOS.
Lo que hizo en realidad fue romper todas las apps web de iOS que solo eran posibles en Safari, pelear un año más con la UE y, si pierde, volver a permitirlas.
¿Se puede decir que esto no es malicioso? Se atreven a hacer esto porque ahora los usuarios que usan apps web son pocos.
Decir que es difícil cubrir todos los casos en unos meses solo termina dándoles una excusa por haberlo postergado tanto.
Digamos que quiero crear un pequeño dashboard para mi servidor doméstico que pueda verse en pantalla completa en el iPhone. Si vivo en la UE, ¿cómo debería agregarlo a la pantalla de inicio?
Como es para un servidor local, no pasaría la revisión, así que no podría subirlo a la App Store aunque quisiera. Las builds locales de debug también caducan más o menos después de una semana. ¿Qué se puede hacer en este caso?
No intento defender a Apple. Me opongo a muchas de sus decisiones que limitan lo que puedo hacer con el hardware que compré, incluida la política de “solo WebKit”. Aun así, dado que entiendo en cierta medida el estado actual de los productos de Apple, me cuesta un poco empatizar con alguien que compra un iPhone esperando este tipo de interoperabilidad personalizada.
Es mucho menos probable que los usuarios no técnicos quieran este nivel de personalización, y los usuarios técnicos deberían saber más del tema.
Dicho eso, realmente me gustaría que eso cambiara. Ojalá el hardware de propósito general pudiera considerarse razonablemente útil para fines verdaderamente generales.
Las PWA son perfectas para apps privadas e internas. En Europa, parece que bastantes proveedores de salud usan PWA para brindar atención a pacientes. Apple terminaría rompiendo esas apps y destruyendo sin aviso los datos guardados de los usuarios.
Al fin y al cabo, no es más que un enlace a una página web.
Nunca implementé una PWA y tampoco soy usuario de Apple, así que quizá me falta contexto. Aun así, parece una buena forma de desarrollar una app simple multiplataforma.
Por lo que entiendo, las PWA ya no se abrirán en pantalla completa ni se verán como apps nativas, sino que ahora se abrirán como marcadores dentro del navegador.
Pero si es simplemente una página web, ¿no debería seguir “funcionando”?
Si Apple rompió la API de notificaciones, entonces las notificaciones no funcionarán, pero muchos sitios las usan. Por ejemplo, ¿también se rompe ahora el popup para activar notificaciones de escritorio en WhatsApp Web?
Cuando dicen que no hay almacenamiento local, ¿se refieren a sessionStorage/localStorage de JavaScript? Si rompen eso, muchos sitios web dejarían de funcionar. El almacenamiento de cookies no es algo que puedan romper así como así, ¿no?
Puede que una PWA ya no se vea como una app pulida, pero para un dashboard personal simple no parece un gran problema.
Las API de HTML/JavaScript permiten pantalla completa.
Apple dijo que “una app web maliciosa puede leer datos de otras apps y, con el consentimiento del usuario, acceder a la cámara, el micrófono y la ubicación”; la explicación es que, como por exigencia de la DMA tenía que permitir motores de navegador alternativos, redujo la experiencia de apps web de iOS para los usuarios de la UE con el fin de evitar riesgos para los usuarios.
Pero el acceso a la cámara, el micrófono y la ubicación del usuario sigue siendo posible. Es bastante extraño.
Seguramente habrá alguien que se crea esa lógica.
Hasta donde sé, Epic no crea PWA, así que esto se parece más a una crítica general lanzada contra Apple.
A pesar de la posición dominante de Apple, entiendo el deseo de reducir la superficie de ataque y eliminar una función usada por poquísimos usuarios. Las PWA están en un espacio ambiguo entre una app web común y una app completa. Las apps web comunes también, hasta donde sé, se pueden guardar como marcadores en la pantalla de inicio, pueden cachear recursos con los encabezados HTTP E-Tag y Cache-Control, y también tienen localStorage.
No queda claro cuál es exactamente la ventaja de una PWA frente a una app web común. ¿Puede recibir algo como push del servidor siempre activo? Pero ¿cuántos usuarios realmente quieren eso?
Personalmente, nunca usé ni creé una PWA. Si quiero apuntar a iOS o Android nativo, levanto un proyecto de React Native como una persona normal.
Me gusta tanto como a cualquiera atacar las prácticas monopólicas de Apple, pero este caso me parece exagerado. Las PWA son como un hijo ilegítimo y ambiguo del desarrollo de apps web, y tiene sentido abandonar su soporte para simplificar el sistema operativo y las API relacionadas.
Me molesta que la conversación siempre sea secuestrada por gente que no tiene derecho a tirar piedras, y que cosas que no tendrían por qué ser polémicas se conviertan en “debates”.