Cómo vigilar los fallos de una app móvil después del lanzamiento

El billete desaparece justo delante del torno

Una viajera abre el billete en el móvil y la aplicación se cierra antes de mostrar el código. Quizá todas las pruebas anteriores salieron bien. Para quien espera pasar, lo único importante es si ahora puede hacerlo. La imagen de cabecera representa una situación posible, no un caso real de un cliente de Appfyl.

Tras publicar, la pregunta no debería ser solamente «¿cuántos cierres hubo?». Es más útil preguntar qué personas no pudieron hacer qué cosa, en qué versión y quién va a responder. La lista de preparación del lanzamiento ayuda a llegar a la tienda. Aquí nos ocupamos de lo que ocurre después, cuando aparecen dispositivos y hábitos que el equipo no había previsto.

Tres problemas que no se ven en el mismo gráfico

Un cierre inesperado devuelve al usuario fuera de la app. En Android, un ANR es un bloqueo: la pantalla deja de responder aunque la aplicación siga abierta. Y existe el fallo silencioso: el formulario dice «reserva confirmada», pero el servidor no registró nada. Este último puede perjudicar más al negocio que un cierre aislado.

Firebase distingue entre usuarios y sesiones sin cierres. Son indicadores útiles para fallos graves, no para todas las acciones fallidas. Una media tranquilizadora puede ocultar que justo quienes intentan pagar no llegan al final. Antes de sacar conclusiones, separa la versión pública de las pruebas y comprueba que el gráfico recibe actividad real.

Un cero en el panel no es una prueba

Pide una demostración sencilla: provocar un fallo controlado en una compilación equivalente a la que saldrá a producción y localizar su informe. Deben verse versión, plataforma, dispositivo y una traza que el desarrollador pueda interpretar. Si faltan los símbolos de iOS o los archivos de correspondencia de Android, llegará la alerta, pero investigar será más difícil. Repite la comprobación cuando cambie el proceso de compilación.

Después, prueba el aviso humano. ¿Quién recibe una incidencia nueva? ¿Quién sustituye a esa persona si no está? ¿Quién puede parar la expansión de la nueva versión? La documentación de Firebase indica que algunas alertas requieren elegir expresamente el canal de entrega. Una notificación guardada en una consola que nadie consulta no evita daños.

No incluyas información privada para compensar la falta de contexto técnico. La versión, un identificador anónimo y el último paso seguro suelen bastar para empezar. Contraseñas, tokens, datos sanitarios o tarjetas no deben acabar en el registro del error. Al incorporar un servicio de diagnóstico, revisa también la política de privacidad de la app.

Qué aporta cada fuente de datos

Android vitals muestra señales de estabilidad observadas por Google Play. Un servicio dentro de la aplicación, como Crashlytics, ayuda a agrupar problemas y comparar versiones. Sentry es otra opción cuando se quiere unir el seguimiento de errores con el rendimiento. Ninguno sustituye el registro de pagos del servidor ni las llamadas de usuarios al soporte.

Quien dirige el producto necesita un resumen manejable: adopción de la nueva versión, errores nuevos o reaparecidos, personas afectadas y recorrido interrumpido. Firebase Release Monitoring ofrece una vista de la versión reciente y su comparación con la anterior. Combínala con los eventos definidos en la guía de analítica móvil para detectar, por ejemplo, que se completan menos reservas aunque no suban los cierres.

Detener una publicación es una decisión de producto

Piensa en un gimnasio a la hora de entrada. La app abre sin problemas, pero el registro de asistencia no llega. El personal deja pasar a los socios y apunta las entradas a mano. Lo urgente es mantener el acceso y poder reconstruir la lista, no celebrar que el porcentaje de sesiones sin cierres sigue alto.

Antes del lanzamiento, decidid qué situaciones exigen una pausa: cierres nuevos que se extienden, acceso o pagos bloqueados, pérdida de datos y problemas de seguridad o privacidad. Una desalineación visual puede esperar. Valora el número de afectados, la importancia del recorrido, la versión y la posibilidad de continuar por otra vía. No existe un porcentaje mágico válido para una app de billetes y para una de contenido ocasional.

En un despliegue gradual se puede detener la distribución mientras se investiga y soporte ayuda a quienes ya actualizaron. Detenerla no restaura una base de datos modificada; hace falta un plan de recuperación propio. Después del arreglo, incorpora el caso a las pruebas previas al siguiente lanzamiento.

Qué hacer durante el primer día

Deja por escrito quién observa la publicación, dónde llegan las alertas, qué recorridos deben funcionar y quién toma la decisión de detenerla. Comprueba primero que la nueva versión tiene sesiones: un panel vacío no dice nada. Compara con la anterior, completa una acción importante en un dispositivo real y verifica el resultado en el servidor o en los eventos. Vuelve a mirar cuando más personas y modelos hayan actualizado.

Cuando aparezca un problema, anota la primera versión afectada, la tarea interrumpida, una solución provisional, el responsable y el momento de la siguiente revisión. Informa a soporte. Una corrección no termina al integrar código: hay que comprobar la versión publicada y vigilar que el fallo no reaparezca. Esa disciplina forma parte del mantenimiento posterior al lanzamiento.

Si vas a entregar una app inestable a un equipo nuevo, reúne las fichas de las tiendas, la versión, el paso que falla, algunos avisos del soporte y el acceso a los informes actuales. «Que no se rompa» no es todavía un diagnóstico. Appfyl puede partir de un breve cuestionario del proyecto para delimitar si procede investigar un fallo concreto o revisar una parte mayor del producto.

Preguntas frecuentes