Tras el lanzamiento: mantenimiento y gestión de versiones
El lanzamiento no es la meta. Cómo las actualizaciones del sistema, las reglas de versión de las tiendas y un calendario mantienen viva una app.
Equipo de rabbitclipPublicación: 5 min. de lectura
En breve
Una app móvil necesita actualizarse varias veces al año tras el lanzamiento; sistemas operativos, reglas de tienda y librerías cambian todos, y una app sin mantenimiento acaba fallando o siendo retirada de la tienda.
Aquí es donde se diferencia de un sitio web. Una página web actualizada para una nueva versión de navegador suele seguir abriéndose sin problema; una app móvil puede quedar descolocada cuando el sistema operativo se actualiza, y una versión sin mantenimiento puede caer de la tienda en cuanto entra en vigor una nueva regla mínima.
Qué significa realmente el mantenimiento
El mantenimiento consiste en mantener actualizadas las librerías de la app, su compatibilidad con el sistema operativo y su cumplimiento de las políticas de la tienda; es un trabajo distinto de añadir nuevas funciones, y sigue un calendario regular y predecible.
Una app no es un producto que se escribe una vez y se abandona; como cualquier software vivo, necesita cambiar a medida que su entorno cambia.
Vale la pena dejar clara la distinción: el mantenimiento mantiene la app tal como está; el trabajo de nuevas funciones la hace crecer. El mismo equipo puede hacer ambas cosas, pero necesitan partidas de presupuesto separadas, o el mantenimiento va perdiendo terreno cada vez frente al trabajo de crecimiento.
Por qué las actualizaciones del sistema generan presión
Apple y Google publican cada uno una versión mayor del sistema al año; con cada versión, algunas API quedan obsoletas y algunos comportamientos de permisos cambian. Un código que funcionaba bien el año anterior puede comportarse de forma inesperada en la nueva versión.
Por eso la app necesita probarse contra cada versión mayor del sistema cuando aparece; retrasar esa prueba suele traducirse en quejas de usuarios.
Un flujo de permiso que antes cabía en una sola pantalla, por ejemplo, puede dividirse en dos pasos en una versión nueva; el código sigue funcionando, pero el usuario nunca ve la pantalla que esperaba. Cambios así solo salen a la luz en pruebas reales, no en una revisión de código.
Actualizaciones obligatorias por parte de la tienda
Google Play sube su nivel mínimo de API objetivo cada año; las apps que se quedan por debajo pierden la capacidad de instalarse de nuevo o actualizarse. Eso significa que la app puede desaparecer efectivamente de la tienda aunque el código en sí no esté roto.
Del lado de Apple, de forma parecida, las apps compiladas con un SDK antiguo dejan de aceptarse para envío al cabo de un tiempo; por eso un ciclo anual de recompilación y pruebas forma parte del trabajo.
Cómo montar un calendario de mantenimiento
Lo que funciona en la práctica es definir dos o tres ventanas de mantenimiento fijas al año: actualización de librerías, pruebas del nuevo sistema operativo, revisión de políticas de la tienda. Fuera de esas ventanas, solo un error realmente crítico desencadena una intervención urgente.
- Pruebas de compatibilidad cuando sale una nueva versión del sistema
- Una recompilación cuando cambia el requisito de API/SDK objetivo de la tienda
- Actualizaciones de seguridad de las librerías de terceros en uso
- Revisión regular de comentarios de usuarios e informes de fallos
Qué pasa sin mantenimiento
En el caso más leve, la app se va volviendo lenta o da errores en algunas pantallas. En el peor caso, la tienda la cierra a nuevos usuarios o la retira por completo cuando el nivel de API objetivo queda demasiado desactualizado. Ambos casos tardan en revertirse.
La app de distribuidores de un taller de muebles, sin tocar durante dos años, perdió la capacidad de instalarse de nuevo cuando Google Play subió su nivel de API objetivo; los distribuidores que cambiaban de teléfono ya no podían reinstalarla. Arreglarlo tomó una semana, pero notar el problema tomó casi seis meses, porque nadie revisaba con regularidad.
Quién debería encargarse del mantenimiento: interno o una agencia
En una empresa pequeña, decirle a una persona 'ocúpate también de la app' suena sencillo, pero el mantenimiento acaba apretado entre el trabajo real de esa persona y se pospone cada vez. Así es como el mantenimiento deja de suceder con más frecuencia, en silencio.
La prueba de decisión es esta: la carga anual de mantenimiento de la app (pruebas, recompilación, revisiones de tienda) es lo bastante pequeña para ser una tarea regular y repetible de una sola persona, o necesita su propio presupuesto y calendario. Si es lo segundo, entregar el mantenimiento a un equipo externo bajo un acuerdo permanente evita que el trabajo se pierda en los huecos.
Errores frecuentes
El error más frecuente es tratar el mantenimiento con la lógica de 'ya lo veremos si algo se rompe'; los requisitos de la tienda llegan en silencio, sin un problema evidente antes, y la app puede caer de la tienda antes de que alguien lo note. El mantenimiento debe ser programado, no reactivo.
El segundo es probar una nueva versión del sistema solo cuando sale oficialmente; probarla desde el momento en que aparece la beta da tiempo para detectar y corregir problemas antes de que llegue la versión pública.
- Acordarse del mantenimiento solo cuando algo se rompe
- Probar un sistema operativo nuevo solo en su versión oficial
- Dejar el mantenimiento en manos de una sola persona sin un calendario por escrito
El lanzamiento no es un final; es el comienzo de un ciclo de mantenimiento regular, y ese ciclo avanza sin sorpresas en cuanto tiene un calendario definido detrás. Si su app aún no tiene un calendario de mantenimiento, vale la pena montar uno juntos.
Preguntas frecuentes
¿Qué pasa si una app nunca se actualiza?
Puede funcionar bien durante un tiempo, pero en cuanto cambia el sistema operativo o una regla de tienda, queda descolocada y puede acabar cerrada a nuevas instalaciones.
¿Cuántas actualizaciones al año bastan para el mantenimiento?
Normalmente dos o tres actualizaciones planificadas; un fallo grave recibe una corrección urgente fuera de ese calendario.
¿Debe probarse la app en cuanto sale un nuevo sistema operativo?
Probarla contra la versión beta, antes de que salga la versión pública, permite detectar problemas antes en vez de después de que los usuarios los reporten.
¿Corre riesgo una app sin acuerdo de mantenimiento?
Con el tiempo, sí; sin alguien que lo siga, los requisitos de tienda o los cambios de sistema operativo pueden pasar desapercibidos hasta que la app se ve afectada.
