Checklist de App Móvil para Startups: 34 Puntos del MVP a la Aprobación en la App Store (2026)

Checklist de App Móvil para Startups: 34 Puntos del MVP a la Aprobación en la App Store (2026)

La Directriz 5.1.1(v) de Revisión de la App Store de Apple ha tumbado más fechas de lanzamiento de startups que cualquier bug que hayamos enviado jamás. Un solo botón de eliminación de cuenta que falta, enviado la noche anterior a un demo day, y todo el cronograma se desliza una semana. Este checklist de app móvil para startups existe porque ese error es por completo evitable, y casi nadie anota el número de directriz que lo provoca.

Puntos clave:

• Apple rechaza apps sin flujo de eliminación de cuenta y sin enlace a la política de privacidad: las Directrices 5.1.1 y 1.5 lo nombran exactamente.
• Google Play exige una ruta de eliminación de cuenta tanto dentro de la app como en una web pública, con aplicación efectiva tras la prórroga del 31 de mayo de 2024.
• Los checklists de envío para iOS y Android son distintos; tratarlos como una sola lista combinada es la causa número uno de retrasos de lanzamiento a última hora.

Antes de Escribir Código

Antes de diseñar una sola pantalla, hay tres cosas que deben quedar cerradas: qué es realmente tu MVP, si necesitas una política de privacidad (sí, la necesitas) y si el GDPR o la KVKK de Turquía aplican a tus usuarios. Saltarse esta etapa es la razón por la que los fundadores acaban escribiendo páginas legales a toda prisa la misma semana que querían enviar.

Un MVP, en una frase, es la versión más pequeña de tu producto que pone a prueba tu suposición central con usuarios reales. No es una versión recortada de tu visión completa. Si aún no tienes claro el alcance, definir bien el alcance de tu proyecto antes de escribir una línea de código te ahorra recortar funciones a mitad de desarrollo en vez de antes de empezar.

Las propias directrices de Apple son directas sobre el requisito de la política de privacidad: la Directriz 5.1.1(i) establece que las apps "deben incluir un enlace a su política de privacidad" en los metadatos de App Store Connect y, en muchos casos, dentro de la propia app. No es una sugerencia. Si falta, es un bloqueo de envío.

• Define el alcance de tu MVP en una sola frase
• Confirma que necesitas una política de privacidad (casi siempre sí)
• Redacta una URL de soporte (la Directriz 1.5 de Apple la exige)
• Comprueba si aplican el GDPR o la KVKK si tienes usuarios en la UE o Turquía
• Decide entre stack nativo o multiplataforma

La Semana de Desarrollo del MVP

La semana de desarrollo del MVP es donde decides qué se envía de verdad y qué se corta, y la respuesta honesta es: más de lo que los fundadores esperan. Las analíticas y el reporte de cierres entran durante el desarrollo, no después. Añadirlos a posteriori, ya lanzado, significa perder justo los datos que necesitabas para validar tu primera suposición.

Lo que de verdad solemos cortar del alcance de una v1, la mayoría de las veces, es todo lo que no sea la única cosa que se está poniendo a prueba. Las notificaciones push, el login social, una pantalla de ajustes con seis interruptores, todo eso puede esperar. Los fundadores se resisten, y es comprensible; se siente como enviar algo sin terminar. Está sin terminar. Ese es justo el punto.

Como lo expresó un fundador que ya ha enviado varias apps en un post de checklist en dev.to, saltarse el mecanismo de feedback al principio es un error del que se ha "arrepentido siempre". Intégralo ahora, no después de que llegue tu primera reseña. Si quieres acelerar la propia conversación sobre el alcance, usar IA para acelerar la definición del alcance merece una mirada antes de que empiece el desarrollo.

• Instrumenta analíticas antes de tu primer build de TestFlight o interno
• Integra el reporte de cierres (Sentry o Firebase Crashlytics)
• Construye un mecanismo de feedback dentro de la app
• Corta cualquier función que no sea central para lo único que estás probando
• Escribe tu primera cadena de versión (ver versionado más abajo)

La Semana Antes del Envío

Esta es la etapa que todos los checklists de la competencia se saltan por completo, y es donde ocurren los retrasos más evitables. El versionado semántico para apps sigue el patrón MAJOR.MINOR.BUILD (1.0.0, luego 1.0.1 para un parche, 1.1.0 para una función nueva). Elige un esquema ahora, porque los números de versión inconsistentes confunden tanto a las tiendas como a tu propio equipo.

Un lanzamiento escalonado libera tu actualización primero a un porcentaje pequeño de usuarios (a menudo 1%, luego 10%, luego 50%) antes de llegar a todos. Solo uno de los tres checklists de la competencia que revisamos lo menciona, y aun así solo de pasada. Si un cuelgue se escapa, un lanzamiento escalonado limita el radio de impacto en vez de golpear al 100% de los usuarios a la vez.

Las preguntas que hacemos antes de dar luz verde al envío de un cliente son simples: ¿funciona la ruta crítica de punta a punta, ahora mismo, en un dispositivo real? No en el simulador. ¿Es aceptable la tasa de usuarios sin bloqueos? ¿Están realmente definitivos los recursos de la ficha de la tienda, y no son marcadores de posición?

• Confirma que tu número de versión sigue un esquema consistente
• Prueba tu ruta crítica de punta a punta una vez más
• Prepara tu porcentaje de lanzamiento escalonado si la tienda lo admite
• Confirma que la tasa de usuarios sin bloqueos es aceptable antes de enviar
• Captura y prepara todos los recursos de la ficha de la tienda

Día de Envío: iOS vs. Android

Los envíos de iOS y Android fracasan por razones distintas, y tratarlos como un solo checklist combinado es la mayor causa de retrasos de lanzamiento a última hora que vemos. Las Directrices de Revisión de la App Store de Apple y las políticas para desarrolladores de Google Play nombran cada una requisitos específicos y verificables, y la mayoría de los fundadores se enteran de ellos solo después de un correo de rechazo.

En nuestros propios envíos de apps, las dos cosas que más suelen hacer tropezar a los fundadores primerizos son el requisito de eliminación de cuenta y una URL de soporte inaccesible. Ambas son arreglos de una sola línea si las detectas antes de enviar. Ambas provocan un rechazo automático si no lo haces.

Las Directrices de Revisión de la App Store de Apple son específicas: la Directriz 5.1.1(v) exige que las apps que admiten creación de cuenta ofrezcan también eliminación de cuenta dentro de la app, la Directriz 1.6 cubre las declaraciones de Seguridad de los datos, y la Directriz 1.5 exige una URL de soporte que funcione. En Android, la política para desarrolladores de Google Play exige tanto una ruta de eliminación dentro de la app como una URL web pública para las solicitudes de eliminación de cuenta. Google anunció el requisito en abril de 2023, fijó el 7 de diciembre de 2023 como fecha límite para las preguntas de eliminación de datos del formulario de Seguridad de los datos, y concedió prórrogas hasta el 31 de mayo de 2024, tras las cuales las apps que no cumplan se exponen a medidas. Esta no es una regla heredada que se haya perdonado a las apps pequeñas; sigue aplicando.

Los dos flujos de envío también divergen en la mecánica, no solo sobre el papel. En iOS, subes un build a través de Xcode o Transporter, App Store Connect lo procesa (esto tarda desde unos minutos hasta más de una hora), y a partir de ahí o lo envías a TestFlight para testers internos y externos o lo mandas directamente a Revisión de la App. TestFlight no es papeleo opcional: es la forma en que Apple espera que detectes los bugs por los que un revisor te rechazaría. En Android, Google Play Console funciona por pistas en vez de un único envío, avanzando por pruebas internas, luego pruebas cerradas o abiertas, y luego producción, cada una con su propia audiencia y su propio paso de promoción. Un lanzamiento escalonado solo aparece una vez que estás actualizando una versión de producción existente. Como dice la propia documentación de releases de Google, "si estás lanzando tu primera versión, no verás la opción de seleccionar un porcentaje de lanzamiento", así que no planes tu primer lanzamiento alrededor de una rampa de porcentaje, eso llega después.

El papeleo, no el código, es lo que de verdad bloquea la mayoría de los primeros envíos. Apple exige un manifiesto de privacidad para una lista definida de SDK de terceros de uso común (redes publicitarias, analíticas, reportes de cierres), y su propia orientación es directa sobre quién responde: "cuando usas un SDK de terceros con tu app, eres responsable de todo el código que el SDK incluye en tu app, y necesitas conocer sus prácticas de recopilación y uso de datos", según la página de requisitos de SDK de terceros de Apple. Sáltate el manifiesto de un SDK listado y tu build no pasará App Store Connect. El equivalente de Google Play como filtro de papeleo es el formulario de Seguridad de los datos, y es obligatorio para toda app en toda pista excepto los builds solo de pruebas internas: "todos los desarrolladores que tengan una app publicada en Google Play deben completar el formulario de Seguridad de los datos, incluidas las apps en pistas de pruebas cerradas, abiertas o de producción", según la documentación de Seguridad de los datos de Google Play. Si te equivocas, Google dice sin rodeos que "puede tomar las medidas oportunas, incluidas medidas de aplicación" cuando surja una discrepancia entre el comportamiento declarado y el real de tu app.

Hay un tercer modo de fallo que no tiene nada que ver con el texto de las políticas: el revisor literalmente no puede probar tu app. La Directriz 2.1 de Apple lo dice sin rodeos: "incluye los datos de la cuenta de demostración (¡y enciende tu servicio de backend!) si tu app incluye un login". Sin credenciales de demo que funcionen, sin backend activo durante la ventana de revisión, sin URL de soporte accesible, y te rebotarán da igual lo conforme que esté tu flujo de eliminación de cuenta. Si cualquier parte de tu app está detrás de un muro de pago o de un login, escribe notas para el revisor explicando exactamente cómo llegar. Es un paso de dos minutos que los fundadores primerizos se saltan constantemente.

Un filtro más, exclusivo de Android, pertenece a la misma conversación: el nivel de API objetivo. La propia documentación para desarrolladores de Android afirma que "las apps nuevas y las actualizaciones deben estar dirigidas" al nivel de API de Android exigido actualmente "para poder enviarse a Google Play", y que "las apps desactualizadas no están disponibles para los usuarios nuevos de dispositivos que ejecutan versiones más recientes de Android". No tiene nada que ver con la eliminación de cuenta ni con la Seguridad de los datos, pero bloquea un envío igual de en seco, y es el tipo de requisito que cambia cada año, así que comprueba el número actual antes de construir tu release.

Ninguna de las checklists mejor posicionadas para esta búsqueda exacta cita un solo número de directriz de la App Store. Nosotros sí, porque adivinar sobre la conformidad es la manera de que los lanzamientos se retrasen una semana tras otra. Si estás construyendo tu postura más amplia de manejo de datos, tu checklist de manejo de datos antes del lanzamiento cubre la parte de seguridad que aquí no duplicamos.

Checklist de envío para iOS:

• URL de la política de privacidad publicada y accesible
• Ruta de eliminación de cuenta dentro de la app enviada (Directriz 5.1.1(v))
• URL de soporte publicada (Directriz 1.5)
• Declaraciones de Seguridad de los datos completadas (Directriz 1.6)
• Build de TestFlight aprobado antes del envío público

Checklist de envío para Android:

• Formulario de Seguridad de los datos completado en Play Console
• Ruta de eliminación de cuenta dentro de la app enviada
• URL web pública para solicitudes de eliminación de cuenta publicada (requisito de Google Play)
• Porcentaje de lanzamiento escalonado configurado
• El nivel de API objetivo cumple el requisito actual de Play

Día de Lanzamiento

El día de lanzamiento es el día en que tu app llega de verdad a usuarios reales, aparte del envío, que puede ocurrir días o semanas antes, y aparte de la primera semana, que es donde llegan las consecuencias. El monitoreo del lanzamiento escalonado el día uno es lo que te dice si seguir ampliando o pausar.

Vigila tu panel de App Store Connect o de Play Console cada hora, no cada día, durante las primeras 24 horas. Si tu tasa de usuarios sin bloqueos cae, quieres enterarte en la hora, no a la mañana siguiente cuando cien usuarios más hayan chocado con el mismo bug. Ten listo un build de reversión. La misma disciplina de endurecer-estabilizar-desplegar que usamos para las funciones de IA aplica aquí igual de directamente.

• Monitorea la tasa de usuarios sin bloqueos cada hora durante las primeras 24 horas
• Ten tu canal de soporte atendido y listo
• Confirma que tu lanzamiento escalonado se está ampliando según lo planeado
• Mantén un build de reversión listo por si hay un bug crítico

Tu Primera Semana en Producción

La primera semana en producción es donde ocurre la mayor parte del trabajo real, aunque casi nadie la planifica. La revisión diaria de reportes de cierres y responder a tus primeras reseñas de la tienda importan más que cualquier cosa que hicieras el propio día de lanzamiento.

"El lanzamiento en sí importa menos de lo que crees. Lo que importa es lo que haces en las semanas siguientes", como escribió un fundador en su propio checklist post-lanzamiento. Esa es la versión honesta de la primera semana: parchea rápido, responde tú mismo, y comprueba de verdad que tu flujo de eliminación de datos funciona antes de que un usuario real lo ponga a prueba por ti. Si ahora te preguntas cuánto cuesta todo esto de construir y mantener, presupuestar el mantenimiento y las actualizaciones post-lanzamiento es la pieza complementaria. Este post cubre la preparación; ese cubre la factura.

• Revisa los reportes de cierres a diario durante la primera semana
• Responde personalmente a tus primeras 10 reseñas de la tienda
• Clasifica y parchea cualquier bug crítico en menos de 48 horas
• Confirma que tu proceso de solicitud de eliminación de datos funciona de verdad de punta a punta
• Fija una cadencia para contrastar las analíticas con tu hipótesis original del MVP

Cómo Enfoca Esto Techsy

Tratamos la revisión previa al envío de la misma manera para cada build de cliente: antes de dar luz verde a un envío, preguntamos si la ruta crítica funciona en un dispositivo real, si la tasa de usuarios sin bloqueos aguanta, y si cada flujo exigido por las directrices (eliminación de cuenta, política de privacidad, URL de soporte) funciona de verdad, no solo existe en una maqueta. Es una lista corta, pero es la lista que determina si una app pasa la revisión al primer intento.

Si prefieres que alguien que ya ha pasado por estas directrices antes se encargue de tu envío, nuestro proceso de desarrollo de apps móviles está construido exactamente alrededor de este paso de revisión previa al envío. No es un sustituto de hacer tus propios deberes, es lo que hacemos después de que tú los hayas hecho.

Preguntas Frecuentes

¿Qué es un MVP y por qué importa para un checklist de lanzamiento?

Un MVP es la versión más pequeña de tu producto que pone a prueba una suposición central con usuarios reales. Aquí importa porque cada punto de este checklist escala con el alcance: un MVP más ajustado significa menos cosas que pueden fallar en el envío y menos funciones que instrumentar, monitorear y parchear en la primera semana.

¿Por qué rechazan las apps en la App Store?

Las razones prevenibles más comunes son la falta del enlace a la política de privacidad (Directriz 5.1.1(i)), la ausencia de eliminación de cuenta dentro de la app (Directriz 5.1.1(v)) y una URL de soporte inaccesible (Directriz 1.5). Ninguna de estas requiere esfuerzo de ingeniería para arreglarse: son puntos de checklist, no bugs.

¿Qué pasa si no añado una opción de eliminación de cuenta a mi app?

En iOS, la Directriz 5.1.1(v) lo convierte en motivo de rechazo automático si tu app admite creación de cuenta. En Android, Google Play exige tanto una ruta de eliminación dentro de la app como una pública en la web, y las apps que no cumplan se exponen a medidas tras la prórroga del 31 de mayo de 2024; omitirla bloquea el envío en ambas plataformas.

¿Necesitan las startups una política de privacidad para una app móvil?

Sí, casi siempre. Apple exige una política de privacidad enlazada bajo la Directriz 5.1.1(i), y Google Play la exige dentro del formulario de Seguridad de los datos. Si recopilas cualquier dato de usuario, aunque sea solo un correo para el registro, necesitas una antes de enviar.

¿Cuál es la diferencia entre enviar a la App Store y a Google Play?

La revisión de Apple se basa en directrices con cláusulas nombradas (5.1.1, 1.5, 1.6) y un revisor humano; Google Play se apoya en el formulario de Seguridad de los datos y en comprobaciones automáticas. El requisito de eliminación de cuenta es parecido en espíritu pero distinto en la mecánica; mira la tabla comparativa de arriba.

¿Cuánto tarda de verdad la revisión de la tienda de apps?

Ninguna de las dos tiendas publica un plazo garantizado, así que trata cualquier número que leas como una expectativa aproximada y no como una promesa. En nuestros propios envíos de clientes, las aprobaciones de Apple han llegado generalmente en uno o dos días, y todo lo que toca eliminación de cuenta o declaración de datos tarda más. Google Play suele ser más rápido. Planea tu fecha de lanzamiento con margen de todas formas.

¿Qué es un lanzamiento escalonado y debería usarlo?

Un lanzamiento escalonado libera una actualización primero a un porcentaje pequeño de usuarios y luego se amplía de forma gradual, en vez de salir al 100% de golpe. Úsalo siempre que la tienda lo admita; limita cuántos usuarios chocan con un bug antes de que puedas pausar y arreglarlo.

¿Necesito una URL de soporte para enviar mi app?

Sí. La Directriz 1.5 de Apple exige una URL de soporte que funcione como parte del envío, y Google Play espera también un contacto de soporte. Un enlace muerto o una bandeja sin vigilar aquí es un motivo de rechazo fácil y evitable.

¿Qué debería monitorear en la primera semana de mi app en producción?

Los reportes de cierres a diario, tus primeras diez reseñas de la tienda, y si tu proceso de solicitud de eliminación de datos funciona de verdad de punta a punta. Este es también el momento en que empiezas a contrastar los datos de uso reales con la suposición que tu MVP se construyó para probar.

¿Son el GDPR o la KVKK relevantes para la app de una startup pequeña?

Si tienes usuarios en la UE, el GDPR aplica sin importar el tamaño de tu empresa. Si tienes usuarios en Turquía, la KVKK aplica de la misma manera. Ninguna de las dos leyes tiene una exención para startups pequeñas, así que comprueba la aplicabilidad durante la definición del alcance, no después de tener datos reales de usuarios que proteger.

Conclusión

Un checklist de app móvil para startups solo se gana su sitio si es lo bastante específico como para actuar hoy: define tu MVP en una frase, instrumenta analíticas antes de desarrollar, revisa tu esquema de versión la semana antes del envío, y separa tus checklists de iOS y Android en vez de tratarlos como una sola lista. Solo los puntos de eliminación de cuenta y política de privacidad concentran la mayoría de los rechazos evitables que vemos.

Imprime el checklist, recórrelo etapa por etapa, y no te saltes la primera semana en producción, porque esa es la parte que todos los checklists de la competencia omiten, y es la parte que de verdad determina si tu lanzamiento se sostiene. Si prefieres unos segundos ojos sobre tu envío antes de mandarlo, obtén una consulta gratuita →.