El primer envío a la tienda debe hacerse varias semanas antes del lanzamiento, no el día en que termina la compilación. No porque la revisión sea lenta, sino porque el trabajo relacionado con la cuenta y los metadatos suele subestimarse constantemente.
La configuración de la cuenta tarda más que la revisión
Antes de poder enviar cualquier cosa, debe existir una cuenta de desarrollador. Para una cuenta empresarial, generalmente se requieren documentos de registro de la empresa y un paso de verificación que tarda de días a semanas, según la jurisdicción y la rapidez con la que coincidan los documentos.
Los retrasos son rutinarios y predecibles: un nombre de empresa que no coincide exactamente con el registro, un formato de dirección que la verificación no acepta o un tipo de entidad jurídica que necesita pruebas adicionales. Ninguno es difícil; todos requieren tiempo.
Esto debe comenzar al principio del proyecto, no al final. Es la causa individual más común de que se retrase una fecha de lanzamiento por motivos no relacionados con el desarrollo.
Los rechazos que se repiten
La mayoría de los rechazos del primer envío se encuadran en un pequeño número de categorías:
- Información incompleta para la revisión. Si la aplicación requiere iniciar sesión, deben proporcionarse credenciales de prueba funcionales. Los revisores que no pueden acceder rechazan el envío. Cuando un flujo de trabajo necesita datos específicos o un estado concreto del dispositivo, hay que explicarlo.
- Cierres inesperados o errores evidentes. Los revisores utilizan la aplicación y la rechazan si se producen cierres inesperados.
- Divulgaciones de privacidad ausentes o incoherentes. Se requiere una política de privacidad, debe estar disponible en una URL activa y debe coincidir con los datos que la aplicación realmente recopila. Declarar que no se recopilan datos mientras se solicitan permisos de contactos es una incoherencia que los revisores comprueban.
- Permisos solicitados sin una finalidad evidente. Solicitar la ubicación, la cámara o los contactos requiere una justificación que el revisor considere plausible, y el texto explicativo dentro de la aplicación debe ser específico en lugar de genérico.
- Contenido provisional. Lorem ipsum, pantallas vacías, botones que no funcionan o secciones con el texto «próximamente». La ficha de una tienda es para un producto terminado.
- Gestión de pagos que no sigue las reglas de la plataforma. Las reglas sobre qué debe utilizar el propio mecanismo de pago de la plataforma son específicas y se aplican estrictamente. Equivocarse en esto puede requerir rehacer un flujo principal.
- Incoherencias en los metadatos. Capturas de pantalla que muestran funciones que no están disponibles o descripciones que prometen funcionalidades inexistentes.
Todos estos problemas pueden prevenirse antes del envío, y una revisión previa al envío basada en esta lista cuesta una hora.
Los metadatos requieren trabajo
La ficha necesita, para cada plataforma y cada idioma:
- Nombre y subtítulo de la aplicación, dentro de los límites de caracteres.
- Descripción, normalmente en versiones corta y larga.
- Palabras clave, cuando la plataforma las utiliza.
- Capturas de pantalla con los tamaños requeridos para varias clases de dispositivos.
- Un icono en varias resoluciones.
- Categoría, clasificación por edad y declaraciones de contenido.
- URL de soporte y de la política de privacidad, ambas activas.
Las capturas de pantalla con tamaños de dispositivo específicos son el elemento que más a menudo provoca una situación de urgencia, porque requieren una compilación funcional en esos tamaños de dispositivo. Producirlas correctamente lleva un día, y hacerlo con prisas genera una ficha que infravalora el producto.
Plazos de revisión
La revisión suele completarse en uno o dos días en las principales plataformas, aunque varía y se ralentiza durante las vacaciones. Planifica varios días y cuenta con al menos un rechazo en el primer envío; es normal y no un fracaso, y volver a enviar la aplicación después de corregir el problema suele ser más rápido.
No programes un evento de lanzamiento para el día posterior al envío. Envía la aplicación, obtén la aprobación y mantén el lanzamiento en espera hasta que estés listo; ambas plataformas principales permiten aprobar una compilación y publicarla más tarde, lo que elimina por completo el riesgo de sincronización.
Después del primer lanzamiento
Las actualizaciones también pasan por revisión. Para cualquier elemento urgente, como una corrección de un error grave, reserva uno o dos días para la revisión en lugar de asumir una publicación inmediata.
Ten en cuenta también que no todos los usuarios actualizan. Una proporción significativa permanece durante mucho tiempo en versiones antiguas, lo que significa que los cambios del lado del servidor deben seguir siendo compatibles con las versiones que todavía están en uso, y conviene decidir pronto durante cuánto tiempo las admitirás.
Servicios relacionados de Manboo
- Desarrollo de aplicaciones Flutter para MVP de iOS y Android.
- Desarrollo de software empresarial para sistemas de CRM, reservas, inventario y flujos de trabajo.
- Desarrollo de paneles de administración para paneles operativos y gestión del backend.
- Integración de API de IA cuando tu producto esté listo para búsquedas inteligentes, chat o automatización.
- Solicita una revisión del alcance y un presupuesto del proyecto cuando estés listo para planificar la primera versión.