Prisioneros del desarrollo Android de Google

• Un pequeño trabajo de mantenimiento para subir el targetSdkVersion de una app Android heredada y cumplir con los requisitos de Google terminó convirtiéndose en un crash en producción en Android 13 y una larga espera de revisión en Google Play
• Para que una app existente siguiera estando disponible para usuarios con dispositivos en versiones de Android más nuevas que su nivel objetivo, debía apuntar a API level 31 o superior; el autor la subió de API level 30 a 33 y la publicó
• La primera versión fue aprobada en menos de una hora, pero en dispositivos reales con Android 13 la app se cerraba inesperadamente justo después de iniciar sesión, y no había forma de hacer rollback a la versión anterior que funcionaba
• El build corregido se envió inmediatamente después del cambio de código, pero quedó esperando revisión durante unas 72 horas y finalmente no se publicó en producción hasta el 4 de septiembre, 11 días después
• Aunque operes directamente el código fuente y la infraestructura de una app móvil nativa, el canal final de distribución sigue estando controlado por el operador de la tienda de apps, lo que limita las correcciones urgentes, los rollbacks y la velocidad de despliegue

---

Una pequeña actualización del SDK se convirtió en un incidente en producción

• La tarea de mantenimiento era una aplicación Android heredada usada por un cliente
  • Su funcionalidad llevaba años terminada y no era una app en desarrollo activo
  • Idealmente, se quería dejar intacta la versión estable
• Google avisó por correo el 18 de agosto de 2023 sobre los requisitos del nivel de API de Android
• El punto clave del aviso era que, para que una app existente siguiera disponible para usuarios con dispositivos en versiones más nuevas de Android, debía apuntar a API level 31 o superior
• El impacto exacto sobre apps ya instaladas no estaba del todo claro, así que se priorizó la actualización con una interpretación más conservadora
• Faltaban menos de 3 semanas para la fecha límite, y Google no había enviado recordatorios previos sobre este requisito

Cambio de targetSdkVersion 30 a 33

• El trabajo empezó el 23 de agosto y se subió el targetSdkVersion de la app de API level 30 a 33
• El primer build falló por una dependencia de analítica incompatible
  • Como esa dependencia no estaba muy ligada a la lógica de negocio, se pudo eliminar
• Después se ejecutó la app en el emulador de Android y las funciones principales parecían seguir funcionando como antes
• Este cambio era una actualización para cumplir con una política, no una mejora que aportara nuevo valor de negocio

Primer despliegue en Google Play y crash en Android 13

• Al principio, el proceso de despliegue en Google Play fue fluido
  • Como la app heredada solo se actualizaba una o dos veces al año, hubo que completar varios cuestionarios
  • La release pasó la revisión en menos de una hora y se publicó en producción
• Esa noche, alrededor de las 21:30, el problema salió a la luz cuando el cliente reportó que algunos usuarios no podían iniciar sesión con la nueva versión de la app
• Al probar en un dispositivo Android real, la aplicación crasheaba justo después del inicio de sesión
• Investigaciones adicionales mostraron que el problema ocurría en Android 13, que entonces era la versión más reciente de Android, mientras que las versiones anteriores funcionaban bien
• En el trabajo inicial solo se había probado con imágenes antiguas del emulador, por lo que el problema de compatibilidad no apareció
• Si se hubieran probado varias versiones de Android, el problema podría haberse detectado
  • El cambio era pequeño y había presión por la fecha límite, lo que generó una confianza equivocada, pero la falta de cobertura de pruebas fue un error del equipo

Una estructura de despliegue que bloquea el rollback

• La respuesta inicial más segura habría sido restaurar la release anterior que funcionaba y analizar el crash al siguiente horario laboral, pero en Google Play esa opción no existía
• No había forma de retirar la última release en producción y reactivar la versión anterior
• Como siguiente intento, se quiso volver el targetSdkVersion a 30, subir la versión de la app y publicar un nuevo build, pero Google Play lo rechazó
  • La guía publicada parecía indicar que se permitirían objetivos más bajos hasta el 1 de septiembre, pero apareció un error indicando que las nuevas actualizaciones debían apuntar a API level 33
• Se solicitó una extensión que permitiera API level 30 hasta el 1 de noviembre, pero el error de publicación siguió igual
• La única ruta posible era corregir el crash de Android 13 y enviar una nueva release

Corrección bajo presión y larga espera de revisión

• La versión rota se estaba entregando gradualmente a los usuarios mediante actualización automática, y cuanto antes llegara el build corregido a producción, menos clientes se verían afectados
• El crash se podía reproducir en el emulador de Android 13 y el cambio de código necesario no era grande
• Aun así, hubo que trabajar tarde por la noche y bajo presión, con tiempo limitado para hacer pruebas de regresión completas
• El plan de ese momento fue más bien una respuesta práctica
  • Corregir todos los crashes conocidos
  • Probar los flujos más importantes
  • Enviar de inmediato la versión corregida
  • Seguir haciendo pruebas más amplias y preparar actualizaciones adicionales si hacía falta
• El nuevo build se envió a Google Play, pero incluso dos horas después seguía esperando revisión, y cerca de la 01:00 aún no había sido aprobado
• A la mañana siguiente, la app seguía en estado in review
• Gran parte del día se fue en pruebas sobre Android 13 y en revisar Google Play Console, y se encontraron y corrigieron algunos problemas menores que no eran tan graves como el crash al iniciar sesión
• Incluso al terminar ese día, la corrección para producción aún no había sido aprobada
• En ese momento, el build corregido llevaba unas 72 horas esperando; el código ya estaba arreglado, pero el despliegue seguía atrapado en una cola de revisión opaca

Actualizaciones posteriores: revisión, chat de soporte y despliegue gradual

• El 27 de agosto se publicó el artículo en Hacker News, donde la discusión incluyó tanto estrategias de release en Android como críticas
  • El post llegó a la portada y recibió unos 130 mil visitantes únicos durante varios días
  • El sitio estático, alojado en un VPS de unos €5 al mes, soportó el tráfico
  • Esa atención no provocó una respuesta de Google, y la actualización de la app siguió en revisión
• El 1 de septiembre se descubrió el chat de soporte detrás del ícono de signo de interrogación en Google Play Console
  • El personal de soporte prometió acelerar la revisión, pero no dio un plazo claro ni una solución concreta
  • Llamó la atención que nadie hubiera mencionado esta vía en la gran discusión de Hacker News
  • Puede que, por la reputación de lo difícil que es acceder al soporte de Google, los desarrolladores ya ni esperen ayuda directa
• El 4 de septiembre, la actualización corregida finalmente se publicó tras 11 días de revisión
• Después, en vez de desplegarla de inmediato al 100% de los usuarios, se envió una release posterior más pequeña usando despliegue gradual, y esa actualización pasó la revisión en menos de una hora
• El 7 de septiembre se envió otra pequeña actualización para reemplazar una versión que había llegado al 99.9999% de los usuarios
  • En cuanto la nueva versión entró a revisión, Google detuvo automáticamente el rollout anterior sin previo aviso
  • Si la nueva revisión hubiera tardado varios días, los usuarios restantes ni siquiera habrían recibido la release anterior
  • Retirar el nuevo envío no restauró el rollout anterior
  • Por suerte, esta revisión terminó en menos de una hora

Cómo el control de la plataforma cambia la responsabilidad en producción

• Los desarrolladores móviles ya han vivido muchos casos parecidos en los que Google o Apple retrasan correcciones urgentes en producción, eliminan apps o apenas ofrecen explicaciones sobre sus decisiones
• Aunque un equipo técnico diagnostique y corrija rápido un fallo, el momento en que los usuarios reciben la solución sigue estando controlado por el operador de la tienda de apps
• Puede que para los usuarios generales no existan rollback, rutas alternativas de distribución ni formas confiables de acelerar la revisión
• Aunque poseas el código fuente y la infraestructura, si no controlas el canal final de distribución, la naturaleza de ser dueño de producción cambia
• Si no es estrictamente necesario tener una app móvil nativa, hay más motivos para preferir la plataforma web abierta
  • Las aplicaciones web muchas veces pueden ofrecer las funciones necesarias, mientras el equipo conserva control directo sobre despliegue, monitoreo y rollback
• Sí hay casos de uso válidos para apps nativas
  • Dependencia de funciones del dispositivo
  • Ejecución en segundo plano
  • Casos en que la distribución por tienda de apps sea necesaria
• Elegir móvil implica aceptar, junto con las ventajas del producto, el costo operativo de meter a un tercero muy poderoso dentro del proceso de release

[GN⁺]

Opiniones en Hacker News

• Recibí este correo tanto a título personal como en el trabajo.
  En lo personal, hago y mantengo voluntariamente una app open source para los sistemas de transporte público de 16 ciudades, y por una tarea que no beneficia a nadie tuve que actualizar 16 apps en 2 semanas.
  Mi app es una PWA, y la versión para Android es básicamente Cordova con algunos plugins que agregan unas pocas opciones nativas. Pero al subir Cordova para soportar la nueva API objetivo de Android, se rompieron plugins que todavía no estaban actualizados, así que tuve que pasarme todo el fin de semana trabajando y probando.
  Sinceramente, me gustaría eliminar la app y hacer que los usuarios vayan al sitio web e instalen la PWA, pero el usuario promedio todavía no sabe cómo hacerlo. El primer lugar donde los usuarios buscan una app sigue siendo Play Store. Bastaría con que Google permitiera enviar PWAs directamente a la tienda de apps, y no quiero repetir esto todos los años.
  En el trabajo también estamos reaccionando a toda prisa. Tenemos una app legacy que algunos clientes con soporte usan hasta fin de año; es bastante compleja, y con solo cambiar la versión de la API objetivo se rompieron varias cosas en las pruebas básicas. Conseguimos una prórroga, pero sabemos que una actualización sin ningún cambio funcional más que apaciguar a Google va a consumir 1 o 2 semanas de desarrollo y 1 o 2 semanas de QA. Y eso aunque es una app que vamos a retirar oficialmente de la tienda a fin de año cuando todos los clientes migren a la app nueva.

  • Para este tipo de casos existen las Trusted Web Activities (TWA). Permiten subir una PWA a Play Store sin frameworks como Cordova.
    https://rangle.io/blog/publishing-a-web-app-to-the-play-stor...
    https://developers.google.com/codelabs/pwa-in-play#0
  • Para dejarlo claro: no es solo que los usuarios no sepan cómo hacerlo. Es que Google y Apple no lo hicieron tan fácil como instalar apps desde sus propias tiendas. Eso es una decisión, y una decisión intencional.
  • Creo que malinterpretaste a los usuarios. No es simplemente un problema de ignorancia. Ojalá las apps volvieran a ser apps nativas de verdad, es decir, no Cordova. Casi no hay apps web que igualen la experiencia de una app real bien hecha, y no un producto web armado a medias.
  • Lo entiendo. Algunas de mis apps personales también se vieron afectadas.
    Dicho eso, este plazo se venía avisando desde hace meses, y estaba claro que en algún momento el aviso iba a hacerse más explícito. No me gustó la redacción, y tampoco tenía sentido quejarse de que la versión de producción estaba bien pero la de pruebas no cumplía el requisito.
    Además, siempre fue un problema de publicar una nueva actualización, y es así todos los años. La app podía seguir publicada durante un tiempo.
    Por eso, decir que solo hubo 2 semanas no es exacto.
  • No sé si te sirve, pero si estuviera en tu situación, publicaría varias actualizaciones de la app con una pantalla que explique cómo instalar la versión PWA, y saldría gradualmente de estos problemas. También podrías ofrecer un formulario de feedback sobre las dificultades que tengan los usuarios.

• Estoy de acuerdo en que desarrollar para Android es difícil, pero el autor cometió dos errores grandes.
  Primero, no probó la app en la versión más reciente de Android. Es un error muy importante, y es la razón por la que mantenemos 11 máquinas virtuales para todas las versiones de Android que soportamos.
  Segundo, al distribuir una app en Google Play, nunca hay que lanzarla al 100% de los usuarios desde el principio. El despliegue gradual es lo normal; nosotros, después de publicar un release, al principio no pasamos del 10% de los usuarios. Cuando ganamos confianza, lo desplegamos al 99%, no al 100%. Así, si por cualquier motivo hay que detener el despliegue, se puede parar fácilmente siempre que no haya llegado al 100%.
  Te gusten o no, estas dos prácticas son tácticas bien conocidas para desarrolladores Android con experiencia.

  • Estoy de acuerdo en que se podría haber hecho mejor en muchos aspectos. Pero, como expliqué, esta es una aplicación legacy, no una app que se desarrolle activamente hoy, así que no tiene sentido armar un sistema de QA tan sólido. Esta app la escribió otra empresa hace mucho tiempo y ni siquiera tiene pruebas unitarias simples. Esa es la realidad.
    Pero incluso con un sistema así de complejo, los errores ocurren, y el verdadero problema es que no hay forma de revertir, cancelar o hacer rollback de un release.
    En esta situación, ¿cómo ayuda el despliegue gradual a todos los clientes? Cuando un usuario final recibe una versión rota, ¿hay alguna forma de que reciba la versión que sí funciona?
  • Como tip: ese campo también acepta decimales. Nosotros siempre lo configuramos en 99.99999999% para que no quede ningún usuario fuera por accidente. Y, al mismo tiempo, como dijiste, sigue siendo posible cancelar el despliegue.
  • Si hay que mantener máquinas virtuales para cada versión soportada de Android, bueno, así será; pero al final uno se pregunta para qué demonios cobran la comisión del 30% de los ingresos.
  • Esto se siente un poco como culpar a la víctima. Esas dos cosas no deberían ser un problema en primer lugar.
  • Lo que dices es totalmente correcto, y es la única forma práctica de hacer actualizaciones y releases. Pero es lamentable que no se pueda esperar que una actualización de API simplemente funcione si compila.

• No entiendo las reacciones que acorralan al autor original. Claro, podría haber tenido más cuidado y podría haber probado el inicio de sesión en la versión más reciente de Android. ¿Pero qué tal si no hubiera sido un crash al iniciar sesión? ¿Y si funcionaba en la versión más reciente, pero no en otras? ¿Dónde se traza la línea?
  En algún punto hay que decir: “esta es una plataforma que literalmente usan millones de apps y millones de desarrolladores; los errores pueden ocurrir, y debería ser fácil corregirlos, por ejemplo volviendo a publicar de inmediato una versión anterior ya aprobada, aunque uno no sepa trucos como detener su propia distribución o hacer un rollout gradual”. Especialmente en lugares como una app store, que las cosas sean reversibles y recuperables es un principio básico de diseño

  • Soy el autor original, y gracias por pensarlo conmigo. Como ya dije en varias respuestas, estoy totalmente de acuerdo en que podría haberlo hecho mejor en materia de pruebas. Por supuesto, siempre hay margen para mejorar en eso
    Google puso una fecha límite y, repito, me enteré por primera vez el 18 de agosto; antes de eso no lo sabía. El cambio parecía menor en ese momento y, como la app funcionaba igual que antes en versiones antiguas de Android, no esperaba que fallara de una forma tan desastrosa
    No soy un desarrollador Android experimentado, pero tengo más de 15 años de experiencia en desarrollo de software en general, así que tengo cierta intuición sobre cómo deberían funcionar las cosas y qué esperar o temer. De verdad no sabía que la práctica recomendada para dejar abierta la posibilidad de “retirar” aunque sea parcialmente la versión más reciente fuera un rollout gradual del 99.99999999%
    Jamás imaginé que no hubiera forma de cancelar o eliminar la versión más reciente para volver a la versión anterior que funcionaba bien. Parece que estas cosas solo se aprenden al vivirlas
    Pueden culparme por no haber probado todas las funciones en todas las versiones de Android, y yo también lo pienso, pero espero que abran los ojos y entiendan que la forma en que Play Store maneja actualmente los lanzamientos no es algo que una persona razonable haría fuera de Play Store. Cualquiera puede enfrentarse algún día a un problema así, y espero que este artículo y este hilo reduzcan la cantidad de desarrolladores que pasen por una situación similar
  • “¿Y si funcionaba en la versión más reciente, pero no en otras?” es una excusa floja. Incluso en una app web hay que probar en varios navegadores
    Hacer un smoke test de una nueva versión es ética profesional básica
    Los rollouts graduales con rollback tampoco son un concepto nuevo
  • No tiene excusa haber portado la app a Android 13, es decir, a targetSdkVersion 33, sin hacer pruebas en Android 13

• Decir “volvamos a los estándares web abiertos y recuperemos el control” puede sonar distinto cuando uno se da cuenta de que la web también está medio controlada por Google, la misma empresa que está causando el problema ahora. Apple, con Safari, que en la práctica es el único navegador en iOS, tampoco es precisamente un aliado

  • Eso también es cierto, pero al menos este tipo de problema se puede manejar con algo como un rollback. En la situación actual, uno sabe que hay una build mala en producción y que los teléfonos se están actualizando automáticamente a ella, pero no puede hacer nada. Eso es lo peor
  • Si lo hospedas en la web, puede implicar más mantenimiento que simplemente pagar el costo
    Definitivamente prefiero un sitio web antes que una app cualquiera que existe solo para rastrear mejor, pero este artículo me pareció un caso de mantenimiento hecho medio a medias
  • Si te niegas a sumarte a la dirección de priorizar la privacidad y la seguridad de los usuarios, Apple definitivamente no es tu aliado. Esa sería la razón

• Es una situación imposible de ganar
  Microsoft invierte un esfuerzo enorme en la compatibilidad hacia atrás, y eso merece mucho reconocimiento. Pero eso también amplía mucho la superficie de ataque
  Del mismo modo, muchas de las peores facetas de C++, que recibe críticas injustas, vienen de su postura rígida sobre la compatibilidad hacia atrás. El código viejo, incluso código C viejo, debe seguir compilando y comportándose como se espera durante el mayor tiempo posible, hasta el punto de aceptar enlazar con binarios antiguos cuyo código fuente se perdió
  La mayoría no hace ese nivel de esfuerzo y deja obsoletas las cosas viejas por mantenibilidad, confiabilidad y seguridad
  Sea cual sea el punto de quiebre que elijas, alguien sale perjudicado. Si no, es que nadie usa ese código

  • Correcto. Ese es un lado del problema, y yo tampoco estoy pidiendo una compatibilidad hacia atrás excesiva. En esta situación específica, la mayor preocupación es que en Android no hay forma de revertir, cancelar o hacer rollback de un release, y todo queda bloqueado detrás del proceso de revisión de Google
    ¿Por qué es imposible “retirar” un release problemático y seguir mostrando el release anterior como la versión más reciente? En el contexto de este problema, eso resolvería la mayor parte
  • Creo que un punto medio que ayuda a todos es cambiar la API y romper la compilación. Que el desarrollador corrija los errores de compilación y use la API correctamente
    Pero no deberían cambiar el comportamiento de una función existente con la misma firma. Si eres proveedor de una API, deberías hacer todo lo posible para que la compilación tenga significado
  • No hay una opción ganadora ideal, pero también se puede distribuir la app por separado. Esto no es un requisito de Android, sino un requisito de Play Store
    En muchos casos no será nada sencillo ni se usará tanto como la versión de Play Store, pero es bueno que exista una vía de escape
  • Me pareció que la queja principal del autor era que Google actúa como juez sobre qué software pueden ejecutar los usuarios. El problema de la deprecación de APIs solo fue el detonante que nos hizo darnos cuenta de lo vulnerables que nos hemos vuelto a los caprichos de Google
  • Me cuesta aceptar esto como excusa de Google
    La mayoría de las aplicaciones distribuidas en Android apuntan al bytecode de Android. No son aplicaciones compiladas de forma nativa
    La razón por la que C++ crea problemas de seguridad difíciles de superar es por sus características de bajo nivel y por el hecho de que, una vez que existe un binario nativo, ahí termina todo
    Pero si se trata de bytecode de un lenguaje con seguridad de memoria, ¿por qué no se podrían hacer backports de correcciones de seguridad? Ejecutar ese tipo de código implica, por su propia naturaleza, estar recompilando el bytecode continuamente
    Para ver lo absurda que es esta postura por parte de Google, la JVM todavía puede ejecutar y usar clases orientadas a Java 1.0 de 1996
    Esto no es un problema de seguridad, sino un problema de “Google no quiere dar soporte a la plataforma”
    Puedo entender hasta cierto punto que Google sea más estricto con artefactos que contienen código compilado nativamente. Pero una política general del tipo “la app fue construida apuntando a una versión antigua de Android, así que ya no la vamos a soportar” no tiene sentido. Más que seguridad, parece una forma de podar apps antiguas de la tienda
    En especial, esta clase de políticas básicamente traslada una gran carga de mantenimiento a los desarrolladores de Android. Para dar soporte a una aplicación de la forma más amplia posible, se termina apuntando a la versión de Android más antigua posible. Casi nadie apunta a la versión más reciente de Android por miedo a excluir a demasiados clientes
    Si Google se tomara en serio la seguridad y el acceso amplio a las tecnologías más recientes de Android, intentaría separar el runtime de Android de la versión del sistema operativo. No hay razón para que los runtimes ART y Dalvik no puedan distribuirse mediante Google Play como otras partes del ecosistema Android. También eliminaría situaciones absurdas como “para hacer esto necesitas Android 17… ah, el fabricante del hardware no actualiza los drivers”
    Pero eso afectaría las ventas de dispositivos nuevos, así que supongo que sería inaceptable

• Siempre fue evidente que Play Store y la “comunidad” de desarrolladores atrapada dentro eran una trampa. Las actualizaciones forzadas de API son solo una faceta de eso
  Hay tareas en las que los teléfonos o las apps móviles claramente sobresalen. Por lo general, cosas relacionadas con el movimiento, como la navegación, o cosas que dependen de los sensores del teléfono, como determinar qué lado está “arriba”. Pero casi todo lo demás se puede hacer con un sitio web
  Si eres un desarrollador que mantiene solo una app móvil multiplataforma, debe ser realmente difícil, y lo entiendo. Aunque decidí hace mucho que no quería participar en el juego de las plataformas propietarias y los gatekeepers, así que mi empatía es completamente desde afuera

  • De hecho, esas dos cosas también se pueden hacer fácilmente en apps de navegador
    Lo único que casi no se puede hacer fácilmente en móviles hoy es algo como shaders de cómputo en GPU. Pero cuando WebGPU llegue desde los navegadores de escritorio, eso también caerá
    Otra cosa que se me ocurre es la administración general de archivos a nivel de todo el sistema. Eso probablemente nunca llegue. La File System API sí permite que el usuario otorgue acceso a ciertos directorios, pero no sé si ese permiso persiste después de recargar la página
  • Estaba convencido de que las app stores iban a fracasar. No pensé que se reunirían suficientes desarrolladores dispuestos a renunciar a la garantía de poder distribuir realmente sus propias apps
  • Es gracioso leer esto en un sitio que suele atacar a Google por no hacer suficiente gatekeeping de software en Android, y que ensalza al iPhone como mejor porque controla todo de forma más agresiva
  • ¿No querrás aferrarte ideológicamente a la soberanía del usuario sobre su propio dispositivo, verdad? Mejor actuar de forma inteligente y práctica, y seguir el camino de menor resistencia directo hacia el corral

• Es irónico si pensamos que uno de los principios de SRE de Google es que “hacer rollback es normal”
  https://cloud.google.com/blog/products/gcp/reliable-releases...
  “En Google, nuestra filosofía es que ‘hacer rollback es normal’. Si se encuentra un error en una nueva versión, o hay sospechas razonables de uno, el equipo de releases primero hace rollback y luego investiga el problema. Una solicitud de rollback no se interpreta como un ataque al equipo de releases ni a la persona que escribió el código con errores. Más bien, se entiende como lo correcto para hacer que el sistema sea lo más confiable posible para los usuarios. Siempre que la lista de cambios del rollback describa el problema observado, nadie pregunta ‘por qué se revirtió este cambio’”

  • Al menos hasta el año pasado, por la combinación de las políticas de Google Play y las actualizaciones de Android, si distribuyes una app por Play Store, la única forma de hacer rollback es desinstalarla y reinicializar los datos del usuario
    No se puede hacer downgrade a un versionCode más bajo, y el versionCode lo define el desarrollador
    Android 11 prohíbe escribir en el almacenamiento “permanente” del teléfono, salvo por excepciones para medios o por usar la API DocumentFile, que trata carpetas locales como almacenamiento en la nube. DocumentFile no sirve para muchos casos de uso
    El desarrollador puede configurar hasFragileUserData, y entonces al desinstalar la app debería preguntársele al usuario si quiere borrar los datos. Pero por bugs de Google/Android, es posible que ese diálogo no se muestre
    Si se desinstala la app y el usuario no borra los datos, Android impide el downgrade a un versionCode más bajo
    Si se solicita MANAGE_EXTERNAL_STRORAGE, se puede usar el java.io.File normal
    Google Play solo permite MANAGE_EXTERNAL_STRORAGE en casos excepcionales
  • “Rollback para mí, pero no para ti”

• Me pasó lo mismo con varias apps basadas en un framework que hice. Una nueva versión de la API chocó con dependencias existentes, y para volver exactamente al estado que ya existía hubo que hacer una cantidad enorme de trabajo
  Ahora respeto mucho más a Microsoft, porque cosas de los 90 corren con menos problemas en Windows moderno que una app móvil escrita para Android hace 4 años

  • Si el framework que usaste no venía de Google, eso es injusto
    No culparías a Microsoft porque Adobe Flash no funcione en la tienda de Windows 11, ¿no?

• Creo que obligar a distribuir apps únicamente a través de una sola tienda de apps “autoaprobada” tiene demasiadas desventajas y casi ninguna ventaja.
  La única ventaja, irónicamente, sería que el administrador de la tienda de apps revisa si hay malware y virus antes de publicar. Pero las apps llenas de anuncios de Google y rastreadores de Google/Facebook son bienvenidas en todas sus formas.
  También está el hecho de que facilita a los usuarios buscar, instalar y actualizar apps. Siempre y cuando puedan encontrar lo que quieren entre miles de millones de apps de juegos y apps casi idénticas publicadas solo para mostrar anuncios o recolectar datos personales.
  La desventaja es quedar atado a los caprichos del administrador de la tienda de apps y no tener control sobre el proceso de publicación de la app. No puedo decidir si puedo publicar una app ni cuándo; lo decide el administrador de la App Store según le convenga. Creo que ese derecho debería pertenecer únicamente al usuario.
  En el caso de apps nativas comerciales, por ejemplo una app de banca en casa, preferiría iniciar sesión en el área privada del sitio web del desarrollador y descargarla desde ahí. La app debería estar firmada con GPG y permitir verificar la integridad del paquete. También podría tener actualizaciones automáticas.
  Para apps open source existe la tienda F-Droid y se pueden agregar repositorios propios. Reconozco que es algo técnico y no es para todos. Ayudaría mucho que F-Droid viniera preinstalado en los teléfonos nuevos, pero no creo que Google lo permita.
  Otra opción realista son las PWA. En mi opinión, muy pocas apps necesitan funciones nativas, y casi todo lo demás se puede hacer con tecnología PWA. Ni siquiera hace falta enviar actualizaciones al usuario ni pedirle que actualice.
  Las tiendas de apps propietarias y comerciales, operadas con el pretexto de facilitarle la vida al usuario y ofrecer “mejor seguridad”, son un “excelente” medio para que Apple y Google ganen miles de millones de dólares con el trabajo de desarrolladores independientes y, en el caso de Google, recolecten y vendan datos personales de los usuarios y vendan publicidad de todo tipo de formas.

  • Se me pasó otra ventaja. Puedes mantener al Boston Strangler[0] fuera de casa. Si atas las manos del usuario a la espalda, puedes decidir en qué condiciones usa tu trabajo. No hay piratería, no hay bloqueo de anuncios.
    Esta es la razón por la que los desarrolladores de juegos en los 80 y 90 en general siguieron el modelo “Licensed by Nintendo”, y por la que los desarrolladores de apps móviles a fines de los 2000 hicieron lo mismo con la iOS App Store. No quieren colaborar directamente con los usuarios para saltarse al dueño de la plataforma. Quieren que el dueño de la plataforma ate las manos del usuario, y aceptan que en el proceso también les ate las suyas.
    Por ejemplo, veamos el caso de una app bancaria: el banco quiere una atestación remota segura. Quiere bloquear a usuarios que hagan ataques de credential stuffing contra la app, impedir que el malware abra la app del banco y presione el botón de “transferir dinero al estafador”, impedir que el usuario extraiga los secretos criptográficos relacionados con tap-to-pay, y también impedir que secretos robados se inyecten en la app del teléfono.
    La app no puede verificar por sí misma si el usuario tiene las manos atadas. Se necesita un tercero confiable para el banco, no para el usuario, que exista en la cadena de arranque o en EL3. Por eso no quieren simplemente darte la app y una firma: quieren que Google haga lo necesario para que Google pueda atar las manos del usuario.
    Es importante notar que todos los beneficios de las tiendas de apps para el usuario son racionalizaciones posteriores. Desde el principio, el objetivo era mantener al usuario atado. Porque para ellos el usuario es como un pequeño mosquito ladrón. Esa es la “parte silenciosa” que no dicen en voz alta.
    De verdad espero que la propuesta WEI de Google no se vuelva realidad y que las PWA no tengan acceso a funciones de atestación. Google ya está con la tontería de “no puedes iniciar sesión desde un navegador desconocido”, y no hace falta que ese cáncer se propague.
    F-Droid es excelente. Hay que frenar las maniobras de Google en Android. La UE podría haberlo hecho, pero EE. UU. también debería hacerlo y hacer que se aplique internacionalmente.
    [0] Nombre en clave que usaba la MPAA para referirse a las copias pequeñas no comerciales, es decir, grabar programas de TV con una VCR. Jack Valenti sí que era una persona horrible, ¿no?

• Yo también me he opuesto durante años al desarrollo de apps móviles, porque en el momento en que decides desarrollar una app móvil entregas el control de tu producto o servicio a un tercero.
  No es difícil estar de acuerdo.
  Si el “soporte” se reduce a esperar recibir atención útil en HN o Twitter, vamos por mal camino.