Checklist para enviar tu primera app Flutter a App Store y Google Play

Antes de enviar ChronoFlow a App Store y a Google Play armamos una lista con todo lo que había que tener listo. Esta es esa lista, limpia y en orden, con el motivo de cada punto. No es un manual de las tiendas: es lo que a un equipo pequeño le habría ahorrado tiempo la primera vez. Estamos justo en esa etapa, así que no decimos que ya hayamos pasado la revisión, sino qué dejamos preparado.

Antes del primer build

• Cuentas y acuerdos. Una cuenta de desarrollador en cada tienda, con los acuerdos aceptados. Sin ellos, ni siquiera puedes configurar la suscripción.
• Registra la app antes de subir nada. La tienda tiene que conocer el identificador de tu app antes de aceptar la primera compilación, y ese identificador no se puede cambiar después. Decídelo una vez.
• Comprueba el nombre pronto. En App Store el nombre tiene que ser único. «ChronoFlow» ya estaba tomado, y también «ChronoFlow by Delphos», así que la ficha se llama «ChronoFlow: Media Signage». El nombre que aparece en el teléfono puede ser distinto del de la tienda.
• Declara el cifrado. Si tu app solo usa HTTPS estándar, indícalo en la configuración de iOS. Así no tienes que responder el cuestionario de exportación en cada build.
• Revisa los textos de permisos. Cada permiso (cámara, fotos, micrófono, seguimiento) lleva una frase que lee el revisor. Tiene que decir lo que la app realmente hace con él.

El canal de pruebas

• Prueba en TestFlight y en las pruebas internas de Play. Con la configuración de pruebas, no con la de producción. Es un binario para testers, no para la tienda.
• Registra las redirecciones de inicio de sesión. Si usas Google, Microsoft o Apple, el identificador que usa el build de tienda tiene que estar dado de alta en cada proveedor. Un inicio de sesión que funciona en pruebas y falla en producción es una sorpresa fácil de evitar.

El build de tienda

• Recompílalo, no lo reutilices. El binario de pruebas apunta a la API de staging. El de tienda sale del mismo commit, pero con la configuración de producción y un número de build nuevo. La historia completa está en cómo automatizamos los releases.
• Distingue versión y número de build. La versión es lo que ve la gente; el número de build solo crece y no se repite. Cada tienda lleva el suyo, así que no los mezcles en un mismo contador.

La ficha

• Respeta los límites. En Google Play: nombre de 30 caracteres, descripción corta de 80 y descripción larga de 4.000. En App Store: nombre de 30, subtítulo de 30, texto promocional de 170, descripción de 4.000 y palabras clave en 100 en total. Cuenta los caracteres antes de pegar.
• Anuncia solo lo que ya existe. Nada de funciones que llegarán después. Lo que prometes en la ficha es lo que el revisor busca en la app.
• Prepara las capturas por dispositivo. En Play, el teléfono admite un máximo de 8. Si declaras otro formato, como televisor, necesita sus propias capturas.
• Un texto por idioma. ChronoFlow tiene cuatro idiomas (español, inglés, portugués y francés), así que la ficha también.
• Decide los países. Ambas tiendas piden una lista de disponibilidad. Mantén una sola y úsala en las dos.
• La suscripción tiene su propia ficha. Cada tienda pide nombre, descripción y beneficios aparte, con límites distintos. En App Store la descripción de la suscripción es muy corta. Usa el mismo identificador de producto en las dos.

URLs legales

• Política de privacidad, pública. Una URL que abra sin iniciar sesión y que diga lo que la app realmente hace.
• Una página para eliminar la cuenta. Google pide un enlace público a ella en el formulario de seguridad de datos, además de la opción dentro de la app. Debe ser una página distinta de la política de privacidad.
• Términos de uso. Los exige App Store para las suscripciones y conviene enlazarlos también en la ficha de Play.

Lo que revisan en la revisión

Estas son las reglas que más nos condicionaron. Las dejamos resueltas en la app antes de enviar; aún no sabemos el resultado de la revisión.

• Eliminar la cuenta desde la app. Si la app deja crear una cuenta, la regla 5.1.1(v) de App Store pide que también se pueda iniciar su eliminación dentro de la app. Añadimos una acción de eliminar cuenta en la pantalla de cuenta.
• Iniciar sesión con Apple. La regla 4.8 pide ofrecer, junto a cualquier inicio de sesión de terceros, una opción que proteja la privacidad. Iniciar sesión con Apple cumple ese papel. Lo añadimos a las opciones de acceso.
• Suscripciones. La regla 3.1.2 pide mostrar el precio y la duración, y enlazar los términos de uso y la política de privacidad dentro de la app. También hace falta un botón para restaurar compras.
• Consentimiento de anuncios. Si la app muestra anuncios, hay que pedir el consentimiento donde corresponda y dejar que la persona vuelva a abrir sus opciones de privacidad. Lo resolvimos con el formulario de consentimiento del SDK de anuncios y un acceso desde la app.

Notas para el revisor

• Explica lo que necesita hardware. ChronoFlow necesita una pantalla para emparejar y reproducir. Dilo en las notas, y ten lista una grabación de pantalla por si el revisor la pide.
• Da una forma de entrar. Si la app requiere una cuenta, entrega una de prueba. Un revisor que no puede entrar no puede aprobar.

Lo que una lista no reemplaza

Puedes cumplir todo esto y que aun así te pidan un cambio: cada revisor lee la app a su manera. Lo que sí hace la lista es que las sorpresas sean pocas y que ninguna sea por algo que se podía comprobar el día anterior.

Para seguir leyendo

Las guías oficiales mandan: App Store Review Guidelines, ayuda de App Store Connect, políticas para desarrolladores de Google Play y ayuda de Play Console. Cómo publicamos las versiones: releases automatizados. El mapa de todas las guías: Construyendo ChronoFlow. Si necesitas llevar tu app a las tiendas: Servicios.