La respuesta corta
Publicar una app Flutter en las dos tiendas por primera vez no es difícil: es largo, y casi todo lo que retrasa no es código. Son cuentas, firmas, fichas y revisiones.
Lo que sí es puramente técnico está bien documentado y se resuelve en un día. Lo demás —cuentas de desarrollador verificadas, certificados, textos legales, capturas por dispositivo— es lo que conviene arrancar semanas antes.
Esta es la secuencia, con lo que se puede ir haciendo en paralelo.
Antes de tocar nada: las cuentas
Es el camino crítico y el que más veces se descubre tarde.
- Cuenta de organización de Apple, con su verificación: entidad legal, D-U-N-S, web propia en el dominio de la empresa, autoridad para firmar. Los seis requisitos están en la cuenta de empresa de Apple.
- Cuenta de Google Play del cliente, no de la agencia.
- Y la decisión que se paga durante años: a nombre de quién van. El detalle en quién custodia los certificados de firma.
Android: firma y bundle
La firma se configura una vez y hay que hacerlo bien porque no tiene marcha atrás.
Se genera el keystore de subida:
keytool -genkey -v -keystore ~/upload-keystore.jks -keyalg RSA \
-storetype JKS -keysize 2048 -validity 10000 -alias upload
Se referencia desde android/key.properties —con storePassword, keyPassword, keyAlias y storeFile— y se engancha en android/app/build.gradle.kts creando la configuración de firma de release.
⚠️ Ni key.properties ni el keystore van al control de versiones. Van al gestor de secretos del cliente. Y conviene activar Play App Signing: con él, la llave que no se puede perder la custodia Google y la de subida es reemplazable.
Repaso previo
AndroidManifest.xml: queandroid:labelsea el nombre definitivo y que estéandroid.permission.INTERNETsi hace falta.- Application ID en dominio invertido y en el dominio del cliente. Es para siempre.
compileSdk,minSdk,targetSdkrevisados. La versión objetivo tiene fecha límite en Play y no es negociable.- Versión en
pubspec.yamlcon el formato1.0.0+1, que mapea aversionNameyversionCode. Se puede sobrescribir con--build-namey--build-numberdesde CI. - Icono en los
mipmap-*y referenciado en el manifiesto.
Construir
flutter build appbundle
Sale en build/app/outputs/bundle/release/app.aab, y cubre armeabi-v7a, arm64-v8a y x86-64. El app bundle es la vía preferida; si hace falta APK, mejor --split-per-abi que un APK gordo con todas las arquitecturas dentro, que solo abulta.
R8 está activado por defecto en release. Y si el proyecto supera los 64k métodos con minSdk bajo, Flutter detecta y propone activar multidex.
Probar antes de subir
Dos pasos que ahorran un rechazo:
- Probar el bundle en local con
bundletool, generando los APK e instalándolos en dispositivos reales. - Subir primero a un canal interno de pruebas, no directo a producción.
iOS: lo mismo, con más burocracia
El flujo es equivalente —identificador de app, certificados de distribución, perfil, archivo y subida— pero con dos diferencias que afectan al calendario:
- Solo hay un certificado de distribución por equipo y solo el Account Holder o un Admin pueden crearlo o revocarlo.
- Todo pasa por App Review. Presupuestar que sale a la primera es presupuestar mal.
La ficha: lo que más se subestima
Se puede ir haciendo en paralelo al desarrollo, y casi nunca se hace:
- Capturas por tamaño de dispositivo, en cada idioma y cada territorio.
- Textos: nombre, subtítulo, descripción, novedades.
- Política de privacidad publicada en una URL viva. Sin ella no se publica.
- Declaración de datos en las dos tiendas, incluyendo lo que recogen los SDK de terceros. Está en privacidad, permisos y declaración de datos.
- Clasificación por edad y categorías.
El calendario realista
Lo que se puede paralelizar, y en qué orden empezarlo:
| Semanas antes | Qué |
|---|---|
| 6-8 | Alta y verificación de cuentas de desarrollador |
| 4-6 | Política de privacidad, textos legales, decisión de identificadores |
| 2-4 | Capturas, textos de ficha, declaración de datos |
| 1-2 | Firma, bundle, canal interno de pruebas |
| 0 | Envío, revisión y despliegue por fases |
Si las cuentas se piden la semana antes, el lanzamiento se retrasa por un trámite administrativo mientras el equipo mira. Pasa constantemente.
Y el día del lanzamiento
No al 100 % de golpe. Despliegue por fases, con indicadores decididos antes y un umbral que obligue a detener — está en actualizar sin perder valoraciones ni ranking.
Y si la app es interna y no va a la tienda pública, el canal es otro completamente: las cinco vías están en cómo distribuir una app interna.
Fuente primaria, consultada el 14 de agosto de 2026: Build and release an Android app en la documentación de Flutter.
