Auditoría de una app móvil: checklist antes de rediseñar o rehacer

Define qué decisión debe salir de la auditoría

Antes de pedir acceso al repositorio, concreta la pregunta. Puede ser si la app soportará el crecimiento previsto, por qué cae la conversión, cuánto riesgo implica cambiar de proveedor o si resulta más sensato reparar que rehacer. Anota también el horizonte: no se estudia igual una versión de rescate para el próximo mes que una plataforma prevista para varios años.

Delimita aplicaciones, mercados, roles, versiones, servicios del backend e integraciones. Sin ese límite, la auditoría se convierte en una investigación interminable. Con él, cada comprobación puede relacionarse con una decisión y una fecha.

Reúne pruebas y accesos antes de opinar

La primera carpeta debería contener objetivos de negocio, mapa de recorridos, reseñas de las tiendas, incidencias de soporte, datos de cancelación, analítica, informes de fallos, notas de versiones y diseño actual. Después vienen repositorios, documentación de API, entornos de prueba y sistemas externos.

Crea un registro de propiedad. Debe mostrar quién controla App Store Connect, Google Play Console, nube, dominio, código, analítica, notificaciones, pasarela de pago y certificados de firma. Que falte una cuenta no es una molestia menor: puede impedir publicar. La guía de documentación y traspaso detalla el paquete que debería recibir un equipo nuevo.

Comprueba primero el producto y sus recorridos

Pide al responsable que explique en una frase para quién es la app y qué resultado útil debe obtener esa persona. Luego contrasta la promesa con el comportamiento real. En un marketplace, el cuello de botella puede estar en la gestión del vendedor; en una aplicación de cursos, en que el progreso no se guarda; en una app de reservas, en los cambios de última hora.

Agrupa tickets, entrevistas y reseñas por recorrido y consecuencia. No confundas frecuencia con gravedad. Dos pagos cobrados sin pedido confirmado merecen más atención que muchas quejas sobre un color. Cuando no haya datos suficientes, registra la incertidumbre en lugar de completar el hueco con una suposición.

Selecciona entre cinco y ocho tareas críticas y ejecútalas en dispositivos reales: primera instalación, vuelta de un usuario, mala conexión, permisos rechazados, sesión caducada, pago interrumpido y recuperación tras un error. Anota estado inicial, acción, resultado esperado, resultado real y prueba. Un vídeo corto suele ser más útil que una descripción ambigua.

No uses el embudo hasta validar la analítica

Un evento disparado dos veces puede simular más conversiones; uno enviado antes de confirmar el cobro puede ocultar pedidos fallidos. Compara el diccionario de eventos con el código y recorre el flujo con una cuenta conocida. Revisa nombre, momento y parámetros de cada evento, y contrasta compras o reservas con el backend.

Comprueba que desarrollo y producción no se mezclen, que las versiones estén identificadas y que iOS y Android midan lo mismo. Si la instrumentación no es fiable, marca como provisionales las conclusiones sobre conversión. Nuestra guía de analítica para apps explica cómo preparar una base medible.

Evalúa estabilidad, rendimiento y accesibilidad

Segmenta cierres y bloqueos por versión, sistema, dispositivo, mercado y recorrido. Android Vitals utiliza métricas percibidas por el usuario, como cierres y ANR; la documentación de Android Vitals permite interpretar los umbrales y los problemas por modelo. Para iOS, App Store Connect App Analytics aporta señales de adquisición, uso y rendimiento.

Mide arranque, acceso, búsqueda, pago, carga de archivos y sincronización con buena y mala conexión. No te quedes en la media: el grupo que tarda diez segundos puede ser pequeño, pero también puede ser el que más compra.

La accesibilidad forma parte de las tareas. Prueba ampliación de texto, contraste, orden de foco, lector de pantalla, tamaño de objetivos, movimiento y mensajes de error. Una herramienta automática ayuda, pero no sustituye la navegación con tecnologías de apoyo. La explicación de Accessible.org sobre auditorías móviles resume bien esa diferencia.

Sigue un recorrido desde la pantalla hasta la base de datos

La revisión técnica no debería premiar un framework concreto. Busca riesgo de cambio: módulos demasiado acoplados, reglas duplicadas, dependencias abandonadas, secretos, pruebas, tratamiento de errores y capacidad de generar una versión limpia. Si solo una persona sabe compilar, la empresa tiene un problema operativo aunque la app funcione hoy.

Elige dos recorridos y síguelos por código móvil, API, base de datos y servicios externos. Comprueba validación, reintentos, operaciones repetidas, caché, migraciones y registros. Así aparecen defectos que una revisión aislada del cliente no detecta, como dos pedidos creados tras recuperar la conexión.

Pregunta además qué datos se recogen, dónde se guardan, durante cuánto tiempo y cómo se exportan o eliminan. En salud, infancia, finanzas o ubicación hace falta una revisión jurídica y de seguridad adecuada. La auditoría general debe reconocer ese límite.

Pide una demostración del proceso de publicación

No basta con leer un documento. Pide que el equipo genere una versión firmada, ejecute pruebas, publique cambios del servidor y explique cómo volver atrás. Revisa entornos, integración continua, secretos, alertas y responsables de incidentes.

Confirma también los derechos sobre código, diseños, tipografías, imágenes y bibliotecas de pago. Las cuentas principales deben pertenecer a la empresa y dar accesos individuales por rol. Una contraseña compartida por mensajería no garantiza continuidad.

Convierte hallazgos en cinco tipos de acción

Separa gravedad y confianza. La primera describe el daño; la segunda, la calidad de la prueba. Un fallo de pago posible pero no reproducido exige investigación urgente, no una afirmación tajante.

Clasifica cada componente así:

• Conservar: cumple su función, tiene propietario y encaja en la hoja de ruta.
• Reparar: el defecto está acotado y puede corregirse sin cambiar la estructura.
• Refactorizar: el comportamiento sirve, pero el interior dificulta cambios seguros.
• Rediseñar: la tecnología funciona, pero el recorrido confunde o bloquea.
• Rehacer: mantener la pieza cuesta más o deja más riesgo que sustituirla.

Una reconstrucción necesita razones verificables: tecnología sin soporte, tratamiento inseguro de datos, publicaciones irreproducibles o costes de cambio estructurales. La edad del código, por sí sola, no basta. Consulta también las diferencias entre rediseño y modernización y el análisis del coste de rediseñar una app.

Qué debe entregar una buena auditoría

El informe útil incluye alcance, inventario de pruebas, arquitectura actual, recorridos examinados, confianza de la analítica, línea base de estabilidad, propiedad, riesgos y plan por fases. Cada hallazgo importante lleva consecuencia, evidencia, recomendación, dependencia, responsable y esfuerzo aproximado.

Separa un plan de estabilización para los próximos 30 días de la evolución posterior. Así los accesos, cierres o pagos urgentes no desaparecen dentro de un proyecto visual. Además, una estimación basada en problemas comprobados necesita menos margen para incógnitas.

En Appfyl usamos este trabajo para proteger lo que ya funciona. A veces basta una versión de reparación. En otros casos se conserva el diseño y se refuerza el backend. Solo proponemos rehacer cuando los datos indican que cambiar por partes sería más caro o mantendría un riesgo importante. Puedes describir tu situación en el brief de estimación de Appfyl.

Preguntas frecuentes