Cómo se actualiza una app sin que el usuario note nada
Resumen:
- Siempre habrá usuarios con versiones viejas: entre el veinte y el treinta por ciento del uso en apps de consumo.
- Versionar la API es lo que evita que un cambio en el servidor rompa todas las apps instaladas a la vez.
- El lanzamiento gradual convierte un error masivo en un error contenido.
- La actualización forzada es una herramienta válida y cara: se usa cuando la versión vieja produce daño.
- Publicar entre martes y jueves por la mañana es una decisión operativa, no una superstición.
Un sistema web se actualiza y listo: todos los usuarios tienen la versión nueva en su siguiente carga de página. Una app no. La app vive instalada en teléfonos que no controlas, de gente que puede tener las actualizaciones automáticas apagadas, el almacenamiento lleno o una versión de sistema operativo que ya no soporta tu código nuevo. Esa diferencia es la que hace que actualizar una app sea una disciplina y no un botón.
La realidad del parque instalado
Si mides qué versión de tu app está usando la gente, el resultado incomoda. Una semana después de publicar, entre el cuarenta y el sesenta por ciento está en la versión nueva. Un mes después, el ochenta. Y queda un remanente estable de usuarios en versiones de seis meses o más que no se mueve nunca.
Ese remanente no es descuido del usuario. Son teléfonos con dos gigabytes libres donde la tienda no puede descargar nada, planes de datos donde las actualizaciones automáticas están apagadas a propósito, y modelos viejos cuyo sistema operativo tu versión nueva ya no soporta. Diseñar asumiendo que todos van a actualizar es diseñar para un mundo que no existe.
Versionar la API: la pieza que casi nadie pone al principio
Aquí está el error que produce las caídas más feas. La app pide datos al servidor y el servidor responde con una estructura. Un día el equipo cambia esa estructura porque la versión nueva de la app necesita un campo distinto. La app nueva funciona perfecto. Todas las versiones instaladas, que esperaban la estructura anterior, empiezan a tronar al mismo tiempo, sin aviso y sin que el usuario haya hecho nada.
La solución es mantener direcciones separadas por versión en el servidor, y conservar las viejas funcionando mientras haya uso real en ellas. Cuando el uso de una versión cae por debajo de un umbral, se avisa y se retira. Cuesta trabajo y es lo que separa una app que se puede evolucionar de una que se rompe cada vez que se toca.
| Tipo de cambio | Rompe versiones viejas | Qué hacer |
|---|---|---|
| Agregar un campo nuevo a la respuesta | No | Publicar sin más |
| Quitar o renombrar un campo | Sí | Versión nueva de API, conservar la anterior |
| Cambiar el tipo de un dato | Sí | Versión nueva de API |
| Agregar una pantalla nueva | No | Publicar sin más |
| Cambiar una regla de negocio en el servidor | Depende | Evaluar qué hace la app vieja con el resultado nuevo |
| Corregir un cálculo que estaba mal | Sí, de hecho conviene | Actualización forzada |
Lanzamiento gradual y la pantalla de actualización obligatoria
Las dos tiendas permiten publicar una actualización a un porcentaje de usuarios. Es gratis y casi nadie lo usa. La mecánica sana es publicar al diez por ciento, esperar veinticuatro o cuarenta y ocho horas revisando los reportes de errores, y si la tasa de fallas no subió, abrir al cien.
En el otro extremo está la actualización obligatoria: una pantalla que impide usar la app hasta que se actualice. Es la herramienta correcta cuando la versión vieja hace daño, por ejemplo si calculaba mal un total o si tenía un hueco de seguridad. Para eso tiene que existir desde la primera versión un mecanismo donde la app, al abrir, le pregunte al servidor si su versión sigue siendo aceptable. Si no se construyó al inicio, el día que lo necesites no lo vas a tener, porque justamente no puedes actualizar a quien no abre la app actualizada.
El caso de la app de pedidos que tronó un lunes
Una comercializadora de materiales en Toluca tenía una app donde sus clientes mayoristas levantaban pedidos. En mayo el equipo renombró un campo en la respuesta del servidor, de "precio" a "precio_unitario", porque era más claro. Publicaron el cambio del servidor un viernes por la tarde junto con la app nueva.
El lunes a las siete de la mañana, los trescientos cuarenta clientes que no habían actualizado abrieron la app y vieron todos los precios en cero. Cuarenta y un pedidos entraron con importe cero antes de que alguien lo notara. El arreglo del servidor tomó dos horas; revertir los pedidos y llamar a los clientes tomó tres días, y dos de ellos dejaron de usar la app.
Lo que cambió después: direcciones versionadas en el servidor, la pantalla de versión mínima que no existía, lanzamientos graduales al diez por ciento y una regla simple de no publicar viernes. Ninguna de las cuatro cosas era compleja. Las cuatro se construyeron en una semana, después de que costaran tres días de operación.
¿Puedo obligar a los usuarios a actualizar la app?
Puedes mostrar una pantalla que bloquee el uso hasta que actualicen, y a veces es necesario, por ejemplo cuando una versión vieja produce datos incorrectos. Pero es una medida agresiva: hay usuarios con el teléfono lleno o con una versión de sistema que ya no soporta tu app nueva, y para ellos el bloqueo equivale a perderlos. Se reserva para cambios que de verdad lo justifican.
¿Por qué sigue habiendo usuarios con versiones de hace un año?
Porque las actualizaciones automáticas no están activadas en todos los teléfonos, porque muchos usuarios no tienen espacio libre y porque algunos desactivan las actualizaciones por datos. En una app de consumo es normal tener un veinte o treinta por ciento del uso en versiones de más de seis meses. Hay que diseñar asumiéndolo, no desearlo distinto.
¿Qué es versionar la API y por qué importa?
Es mantener la puerta de entrada al servidor estable para las versiones de app que ya están instaladas, y abrir una puerta nueva para la versión nueva. Si cambias la respuesta del servidor sin versionar, todas las apps instaladas que esperaban la respuesta anterior empiezan a fallar al mismo tiempo, sin que nadie haya hecho nada.
¿Qué es un lanzamiento gradual?
Es publicar la actualización al cinco o diez por ciento de los usuarios, esperar un día o dos viendo los reportes de errores, y recién entonces abrirla a todos. Las dos tiendas lo permiten sin costo. Es la diferencia entre un problema que afecta a quinientas personas y uno que afecta a diez mil antes de que te enteres.
¿Cuándo conviene publicar una actualización?
Entre martes y jueves por la mañana, nunca un viernes ni antes de un puente. La razón es práctica: si algo sale mal necesitas gente disponible para arreglarlo y para publicar la corrección, y la revisión de las tiendas también toma tiempo. Un error publicado un viernes vive hasta el lunes.