Mantener una app fitness: lanzar fue el principio

El día del lanzamiento todo está reciente. Sabes dónde están las cosas, recuerdas cada decisión y tienes ganas de mejorar. Seis meses después, un cliente abre la app en un móvil nuevo, una librería ha cambiado, el servicio de correo rechaza mensajes y la persona que te ayudó con el código ya no está disponible.

Esto no significa que desarrollar fuera un error. Significa que una app es un servicio continuo. Si forma parte de tu coaching, su mantenimiento ya forma parte de la experiencia que vendes.

1. Observabilidad: enterarte antes que el cliente

Un mensaje como «no me sale el entreno» aporta muy poca información. ¿No se cargó, no estaba asignado, caducó la sesión o falló una migración? La observabilidad combina varias señales para reconstruir lo ocurrido.

Instalar una herramienta de errores no basta. Hay que decidir qué alerta despierta a alguien, quién la recibe y qué acción puede tomar. Si todas las excepciones envían un correo, pronto nadie lee ninguno.

2. Una incidencia necesita un proceso, aunque seas una sola persona

Imagina que las rutinas nuevas dejan de aparecer para una parte de los clientes. El arreglo técnico es solo una fase:

• Confirmar: separar un fallo real de un problema de uso o de conexión.
• Acotar: saber desde cuándo ocurre, a quién afecta y qué versiones intervienen.
• Contener: detener despliegues, desactivar la función o recuperar la versión anterior.
• Corregir: crear un cambio pequeño, revisarlo y probar los flujos relacionados.
• Recuperar: reprocesar asignaciones fallidas o restaurar datos si hace falta.
• Comunicar: decir qué ocurre, qué puede hacer el cliente y cuándo habrá otra actualización.
• Aprender: añadir una prueba o alerta que impida repetir el mismo incidente.

3. Las actualizaciones obligatorias existen

Una app móvil depende de SDK, herramientas de compilación, permisos, notificaciones y políticas de tienda. En la fecha de publicación de esta guía, Google Play exige que las nuevas apps y actualizaciones generales apunten a Android 16 (nivel API 36) desde el 31 de agosto de 2026. El requisito volverá a cambiar con futuras versiones; consulta siempre la página oficial de requisitos.

Apple también revisa privacidad, funcionamiento, cuentas de prueba y cumplimiento en cada envío. Si tu app crea cuentas, debe permitir iniciar su eliminación dentro de la app. Estas reglas no son un trámite único: una actualización puede ser rechazada y retrasar una corrección urgente. Las directrices de revisión de Apple forman parte de la documentación de mantenimiento.

• Revisar dependencias y avisos de seguridad.
• Probar en versiones actuales y anteriores de los sistemas soportados.
• Actualizar capturas, declaraciones de privacidad y notas de revisión cuando cambie el producto.
• Mantener certificados, claves de firma y acceso a las cuentas de desarrollador.
• Preparar una entrega urgente sin saltarse revisión y pruebas.

4. Cada mejora puede romper algo que ya funcionaba

Pedir a una IA «añade pagos recurrentes» puede producir una pantalla convincente. Después hay que probar renovaciones, rechazos, duplicados, reembolsos, zonas horarias, notificaciones y el efecto de borrar una cuenta. La complejidad crece por las combinaciones, no solo por el número de pantallas.

Conserva una lista corta de flujos críticos y ejecútala antes de publicar: alta, acceso, recuperación de contraseña, invitación, asignación, registro de entrenamiento, subida de archivo, exportación y borrado. Automatizar parte de estas pruebas reduce trabajo, pero alguien debe decidir qué comportamiento es correcto.

5. El soporte se convierte en soporte técnico

Cuando usas un proveedor, puedes escalar una incidencia. En una app propia, la conversación termina en ti. Necesitas obtener datos útiles sin pedir contraseñas ni capturas con información sensible.

• Canal: dónde reportan los usuarios y en qué horario respondes.
• Contexto: versión de app, dispositivo, hora aproximada y pasos realizados.
• Prioridad: distinguir una duda, una función degradada y un bloqueo general.
• Estado: confirmar recepción y actualizar sin prometer una hora que no puedes cumplir.
• Privacidad: no mover datos personales a chats, correos o herramientas no previstas.

El soporte también revela problemas de diseño. Si diez personas preguntan lo mismo, quizá no necesitas una respuesta guardada, sino cambiar el flujo. Eso requiere tiempo de producto además de tiempo técnico.

6. Un calendario de mantenimiento realista

La frecuencia exacta cambia según el riesgo y el uso. La idea importante es presupuestarla antes de lanzar. Si solo puedes mantener la app cuando «sobre tiempo», el mantenimiento competirá siempre con tus clientes.

7. La decisión final: ¿quieres un activo tecnológico o una herramienta?

Una app propia puede ser un activo si genera una ventaja que compensa su coste, existe un equipo capaz de cuidarla y forma parte de una estrategia de producto. Puede ser una carga si reproduce funciones estándar y depende de una sola persona que además debe vender, entrenar y atender clientes.

La salida no tiene que ser abandonar toda personalización. Puedes usar software especializado para las funciones comunes y construir solo la capa que te diferencia. Esa frontera pequeña es más fácil de entender, probar, mantener y sustituir.

Serie completa

• Parte 1: coste real y cuándo compensa
• Parte 2: infraestructura, datos y backups
• Parte 3: seguridad, privacidad y datos de clientes
• Parte 4: mantenimiento, observabilidad, actualizaciones y soporte (estás aquí)

Preguntas frecuentes