La respuesta corta

Auditar una app que no escribiste no es leerla de arriba abajo. Es buscar señales: indicadores baratos de comprobar que predicen bien cuánto va a costar mantenerla.

Y hay que empezar por lo que caduca solo, porque eso es coste ya devengado que no depende de la calidad del código.

Primero el reloj

Antes de abrir un solo fichero: mira contra qué versión de plataforma compila. Google Play tiene fechas duras y la próxima es inminente.

Desde el 31 de agosto de 2026, las apps nuevas y las actualizaciones deben apuntar a Android 16 (API 36) o superior. Para Wear OS y Android Automotive el mínimo es Android 15 (API 35); para Android TV y Android XR, Android 14 (API 34).

Lo que le pasa a una app que no llega es más sutil de lo que suele contarse, y conviene decirlo bien: no se retira de la tienda. Lo que ocurre es que deja de estar disponible para usuarios nuevos en dispositivos más modernos — la app solo aparece en dispositivos con una versión de Android igual o inferior a la que la app declara como objetivo. Quien ya la tenía instalada la conserva y puede reinstalarla en dispositivos compatibles.

Traducido a negocio: no es una caída, es una hemorragia lenta de instalaciones nuevas que nadie atribuye a su causa real.

Hay prórroga hasta el 1 de noviembre de 2026, solicitable desde la página de estado de políticas de Play Console para las apps afectadas.

Si la app que auditas no llega a API 36, eso es lo primero del informe, con fecha.

Señales en el repositorio

Se ven en diez minutos y dicen mucho:

  • ¿Hay histórico? Un repositorio que empieza con un commit «initial commit» de 40.000 ficheros es una copia, no un histórico. Has perdido la memoria del proyecto.
  • Frecuencia y tamaño de los commits. Commits enormes y espaciados indican trabajo sin integración continua y revisiones que no existieron.
  • Cuántas personas distintas. Un único autor en tres años es el riesgo de continuidad más caro que existe, por encima de cualquier deuda técnica.
  • Ramas vivas sin fusionar durante meses: trabajo que alguien empezó y nadie cerró, y que probablemente ya no compila.
  • Etiquetas de versión. Si no puedes identificar qué commit corresponde a la versión que hay en la tienda, no puedes reproducir un fallo de producción.

Señales en el build

Aquí es donde se descubre si el proyecto es mantenible o solo era mantenible por ellos:

  • ¿Compila en una máquina limpia? La prueba es esa: un portátil nuevo, el README, y cronómetro. Todo lo que haya que preguntar es documentación que falta.
  • ¿Están los secretos en el repositorio? Búscalos. Si aparecen claves en el histórico, no basta con borrarlas: hay que rotarlas, porque el histórico es público para todo el que clonó.
  • ¿Hay dependencias privadas —paquetes internos, submódulos, registros propios— a las que no tienes acceso? Es el motivo número uno de que la primera compilación falle tras un traspaso.
  • ¿El proceso de release está automatizado o vive en una máquina? Si publicar exige el portátil de una persona concreta, tienes un punto único de fallo con nombre y apellidos.

Señales en el código

Sin entrar a juzgar el estilo, que es lo menos importante:

  • Ficheros desproporcionados. Una pantalla de 3.000 líneas no es un problema estético: es un sitio donde nadie puede tocar nada sin romper otra cosa.
  • Lógica de negocio dentro de la interfaz. Determina si se puede probar automáticamente algo o no.
  • Llamadas de red repartidas por toda la app, sin una capa que las agrupe. Cambiar de backend o añadir reintentos se convierte en una cacería.
  • Gestión de estado sin criterio único. Tres enfoques distintos conviviendo suele significar tres etapas del proyecto con tres equipos distintos.
  • Manejo de errores por omisión: bloques que capturan la excepción y no hacen nada. Cada uno es un fallo silencioso que en producción se convierte en un ticket sin causa.
  • Comentarios que contradicen al código. Señal de que se editó sin leerlo.

Señales en producción

  • ¿Hay crash reporting y alguien lo mira? Sin observabilidad no hay métricas de calidad, hay opiniones.
  • Cuántas versiones distintas están vivas en el parque de usuarios. Muchas versiones antiguas activas significa que las actualizaciones no llegan, y eso condiciona cualquier plan de migración.
  • Permisos que la app pide y no usa. Suele delatar una funcionalidad abandonada a medias.
  • Tamaño de la descarga y su evolución. Un binario que solo crece es un proyecto donde nunca se ha borrado nada.

Cómo se puntúa

Un informe útil no da nota. Clasifica en tres cajas:

  1. Obligatorio con fecha: lo que caduca solo. Target API, dependencias sin mantenimiento en el camino crítico, certificados que vencen.
  2. Riesgo de continuidad: lo que se rompe si desaparece una persona o un acceso.
  3. Deuda opcional: lo que se puede vivir con ello, con su coste anual estimado de convivencia.

Las dos primeras cajas justifican presupuesto solas. La tercera es una conversación de producto, no de ingeniería.

Qué NO es señal de alarma

Conviene decirlo porque el sesgo del que llega nuevo es implacable:

  • Que el código no siga tus convenciones. No es deuda, es que lo escribió otro.
  • Que use una librería que tú no habrías elegido. Lo relevante es si está mantenida y si es sustituible.
  • Que no haya tests en todo. Lo relevante es si los hay donde se mueve el dinero y los datos sensibles.
  • Que la arquitectura sea sencilla. Una app sencilla bien hecha es mejor activo que una compleja mal entendida.

Casi todas las decisiones que parecen absurdas tenían un contexto —un plazo, un presupuesto, una restricción del cliente— que no está escrito en ninguna parte. Un informe que ignora eso es un informe que nadie de la otra parte va a firmar.

Esto es exactamente lo que hacemos en una auditoría técnica de app móvil, y lo que precede a cualquier propuesta de migración a Flutter: primero se sabe qué hay, después se decide qué se hace.

Fuente primaria, consultada el 14 de agosto de 2026: Target API level requirements for Google Play apps.