Todavía no he pasado por una revisión real de Google Play
Voy a empezar dejando esto claro: Caladero, la app de pesca que estoy desarrollando, no está publicada en Google Play. Todavía está en fase de desarrollo, sin beta pública ni ficha de tienda. Así que este artículo no habla de "cómo pasé la revisión", sino de la checklist que voy construyendo mientras me preparo para ese momento, basada en la documentación oficial de Google y en los errores que ya he detectado en mis propias pruebas internas.
Prefiero ser honesto con esto porque he visto demasiado contenido que da consejos "de experiencia" sobre procesos que nunca han vivido. No es mi caso aquí, y prefiero decirlo antes de que lo preguntes.
Coherencia entre lo que declaro y lo que la app hace
El primer bloque de errores que reviso no tiene que ver con el código, sino con la coherencia entre la documentación de la ficha y el comportamiento real de la app:
- Que el formulario de Data Safety describa exactamente los datos que se recogen, no una versión optimista de "lo que planeo recoger en el futuro".
- Que la política de privacidad enlazada esté accesible públicamente y no detrás de un login.
- Que los permisos solicitados en tiempo de ejecución coincidan con los declarados: si pido ubicación precisa pero la app solo la usa para una función concreta, ese contexto debe quedar claro en el propio flujo, no solo en un texto legal.
Esto lo desarrollo con más detalle en cómo preparo Data Safety sin esperar al final del desarrollo y en qué debe explicar la política de privacidad de una app Android.
Pruebas funcionales que no dependen de mi propio dispositivo
El segundo error habitual, y el que más me ha costado corregir como hábito, es probar solo en el dispositivo con el que desarrollo. Mi teléfono tiene más memoria RAM y una versión de Android más reciente que buena parte de los dispositivos reales que puede usar cualquier persona.
Antes de considerar una build lista para avanzar, intento:
- Instalarla en al menos un dispositivo físico distinto al habitual, con otra versión de Android.
- Probar el flujo completo con la conexión de datos limitada o intermitente, no solo con wifi estable.
- Forzar el cierre de la app en mitad de una acción (por ejemplo, guardando un punto en el mapa) y comprobar que al reabrirla no queda en un estado inconsistente.
- Revisar el comportamiento cuando se deniegan permisos, no solo cuando se conceden. Una app que se cae al negar el permiso de ubicación es un fallo grave, no un caso límite.
Contenido y capturas que reflejan la realidad
Otro error que veo con frecuencia, y que vigilo especialmente en mi propio proyecto, es que las capturas de pantalla o el texto de la ficha muestren funciones que todavía no existen o que están en un estado muy distinto al real. Es tentador maquillar una función a medio construir, pero genera reseñas negativas en cuanto el usuario nota la diferencia.
En mi caso, mientras Caladero siga en desarrollo, prefiero no mostrar públicamente ninguna captura como si fuera el producto final. Cuando llegue el momento de publicar, quiero que las capturas y el texto describan exactamente lo que la persona va a encontrar al instalar la app, ni más ni menos. Hablo de esto con más detalle en capturas, icono y gráfico destacado para Google Play.
Errores de política que son fáciles de pasar por alto
Hay una categoría de errores que no son técnicos sino de política, y que suelen sorprender a quien publica por primera vez:
- Usar contenido con derechos de terceros (iconos, mapas, fuentes) sin verificar la licencia.
- No implementar un flujo de eliminación de cuenta cuando la app permite crear una cuenta, algo que trato en eliminación de cuenta: una función que no conviene dejar para el final.
- Pedir permisos "por si acaso" en lugar de solo los que la funcionalidad actual necesita de verdad, algo que desarrollo en permisos Android: pedir solo lo necesario.
Ninguno de estos puntos es exclusivo de apps grandes; afectan igual a un proyecto pequeño desarrollado por una sola persona.
Textos de la ficha que se quedan desactualizados
Hay un tipo de error que no aparece la primera vez que se revisa la ficha, sino varias versiones después: el texto descriptivo deja de coincidir con lo que la app hace realmente porque la app ha cambiado y la ficha no. Esto pasa con facilidad cuando una función se retira temporalmente para rediseñarla, o cuando cambia el flujo de una pantalla que el texto describía con detalle.
Por eso trato la ficha de Google Play como un documento vivo que hay que revisar en cada versión relevante, no como un texto que se escribe una vez y se olvida. Antes de subir una build nueva con cambios de funcionalidad visibles, reviso si algún párrafo de la descripción larga o corta ha quedado desfasado. Es un paso que se salta fácilmente porque no es un error de código y no aparece en ningún log; solo se detecta releyendo el texto con ojos críticos, comparándolo con la app tal como está hoy, no como estaba cuando se escribió la ficha.
Los límites de esta lista
Quiero ser claro sobre lo que esta checklist no puede garantizar: no elimina el riesgo de un rechazo por un motivo que no había previsto, ni sustituye la lectura completa de las políticas de Google Play. Las políticas cambian, y lo que era válido hace un año puede no serlo ahora. Por eso reviso periódicamente el centro de políticas para desarrolladores en lugar de fiarme de una lista fija para siempre.
Conclusión
Esta lista no es un certificado de que todo vaya a salir bien la primera vez; es simplemente la forma que tengo de reducir los errores previsibles antes de someter algo a revisión externa. Cuando trabajas solo, sin nadie que revise el trabajo antes que tú, el mayor riesgo no suele ser un error complicado, sino uno tonto que se podría haber detectado con cinco minutos de atención antes de pulsar "enviar".