LaunchLint Academy
Respuesta breve
- EAS Submit sube el archivo final de la app, pero no completa la ficha, la privacidad, las capturas ni las indicaciones para el equipo de revisión.
- Antes de crear la app, verifica identidad, versiones, complementos y permisos. Después, prueba la versión de producción en dispositivos reales y compara el flujo con App Store Connect y Play Console.
- Incluye la eliminación de cuenta, el acceso de prueba, las compras y el tratamiento de datos de servicios externos en cada publicación. Un proceso técnico correcto no equivale a aprobación.
1. Qué hace EAS Submit y qué sigue siendo tu responsabilidad
EAS Submit entrega el archivo iOS o Android a la tienda. En iOS llega a App Store Connect o TestFlight; en Android, al canal configurado. Reduce pasos manuales, pero Apple y Google siguen revisando la app, los datos de la ficha y las indicaciones proporcionadas.
Un EAS Build y EAS Submit correctos solo prueban que el archivo se pudo crear y transferir. No prueban que el inicio de sesión funcione para un evaluador nuevo, que los permisos estén bien explicados, que las declaraciones sean completas o que las compras y páginas públicas funcionen.
Después de subir la app aún debes:
- Completar ficha, categoría, clasificación y disponibilidad
- Comparar capturas y descripción con la versión de producción
- Completar App Privacy y Data Safety
- Añadir contacto, cuenta de prueba y pasos especiales
- Hacer visibles compras y suscripciones
- Enviar la app procesada a revisión
2. Fija identidad y versiones antes del build de producción
Bundle Identifier y Android Package Name conectan el binario con la ficha, firma, push y con frecuencia OAuth y deep links. Revísalos antes del primer upload. Una identidad publicada no se renombra como el nombre visible de la app.
Separa versión comercial y número técnico. Cada binario iOS nuevo necesita un buildNumber superior; Android usa versionCode. Con app.config dinámica, inspecciona los valores resueltos para producción y no una configuración de desarrollo.
{
"expo": {
"name": "My Production App",
"slug": "my-production-app",
"version": "1.0.0",
"ios": {
"bundleIdentifier": "com.example.myapp",
"buildNumber": "1"
},
"android": {
"package": "com.example.myapp",
"versionCode": 1
}
}
}Comprueba:
- Identificadores y fichas coinciden
- buildNumber y versionCode aumentan
- Producción usa dominios API, OAuth y deep-link correctos
- Icono, splash y nombre son finales
- Conoces qué valores llegan desde variables de entorno
3. Explica los permisos desde el flujo del usuario
Las librerías Expo pueden añadir permisos mediante Config Plugins o Android manifests incluidos. Inventaría dependencias, revisa la configuración resultante y elimina permisos que el flujo real no necesita.
En iOS, el Purpose String debe explicar una función verificable. ‘La app necesita la cámara’ repite el diálogo; ‘Usa la cámara para escanear el QR de una entrada’ explica valor y momento. Los cambios de Info.plist requieren un binario nuevo y no se corrigen vía OTA.
{
"expo": {
"ios": {
"infoPlist": {
"NSCameraUsageDescription":
"Use the camera to scan the QR code on an event ticket."
}
},
"android": {
"blockedPermissions": [
"android.permission.RECORD_AUDIO"
]
}
}
}- Pedir acceso solo donde se necesita
- Ofrecer alternativa al rechazo
- Explicar finalidad y valor
- Permitir activar acceso más tarde
- Eliminar permisos nativos no utilizados
4. Alinea archivos del proyecto, comportamiento y declaraciones de privacidad
package.json muestra posibles bibliotecas y servicios externos, pero no genera una declaración completa. Los servicios de análisis, errores, inicio de sesión, publicidad o pagos pueden transmitir datos; la configuración y el uso real determinan qué se envía, cuándo, para qué y a quién.
| Capa | Pruebas útiles | ¿Suficiente? |
|---|---|---|
| Archivos del proyecto | Servicios externos, permisos, extensiones y direcciones web | No: solo son señales |
| App en ejecución | Momento, consentimiento, uso opcional y transmisión | No: faltan servidores y proveedores |
| Consola | Datos, finalidades, uso compartido y borrado declarados | No: debe coincidir con la app |
Google incluye en Data Safety los datos transmitidos por servicios de terceros y mantiene al desarrollador como responsable. Documenta por servicio el tipo de dato, receptor, finalidad, obligatoriedad, retención y borrado; luego compáralo con la política de privacidad y ambos formularios.
5. Prueba el acceso y la eliminación como un evaluador externo
Si funciones centrales requieren login, invitación, rol, región o suscripción, proporciona una ruta estable. Apple solicita una cuenta demo activa o un modo demo completo. Evita datos personales, dispositivos internos y códigos temporales.
Datos fiables para el equipo de revisión:
- Cuenta dedicada y servidor disponible
- Pasos cortos hacia la función protegida
- Detalles de roles, QR, hardware o ubicación
- Estado de prueba para compras
- Contacto disponible durante la revisión
La eliminación de cuenta es un flujo completo. Apple exige iniciarlo dentro de la app; Google añade una URL web para solicitudes. Prueba confirmación, reautenticación, datos vinculados, suscripciones y cualquier retención que debas explicar.
6. Compara capturas, promesas y compras con la app
Los datos de la ficha también se revisan. Elimina promesas de funciones ausentes o internas. Las capturas deben mostrar pantallas alcanzables. Abre soporte y privacidad en un navegador móvil sin iniciar sesión.
Los productos digitales deben ser visibles y funcionar durante la revisión. Explica condiciones especiales y prueba la restauración, los errores, una suscripción activa y la reinstalación. Tener una biblioteca de pagos no demuestra que esos casos estén resueltos.
- Nombre y descripción coinciden con la app
- Capturas reales y alcanzables
- Páginas públicas con HTTPS
- Compras visibles para el equipo de revisión
- Indicaciones breves para el equipo
- Sin textos provisionales ni avisos internos
7. Preflight de 24 horas
Congela brevemente la release, genera el build desde el commit previsto y prueba exactamente ese artefacto. Un cambio posterior de permisos, configuración nativa o SDK obliga a crear y revisar otro binario.
- Registrar commit y configuración
- Instalar builds iOS y Android en dispositivos reales
- Probar inicio, login, rechazo de permiso, núcleo, compra y borrado
- Comparar SDKs con privacidad
- Revisar screenshots, textos, URLs y notas
- Validar credenciales en otro dispositivo
- Subir, comprobar procesamiento y enviar
Guarda una lista ligera con build ID, flujo, resultado esperado, resultado real y responsable. Tras una incidencia podrás separar mejor un defecto del binario de un problema de ficha o comunicación.
8. Qué aporta una revisión estática de los archivos del proyecto
El análisis estático encuentra identificadores, servicios externos, extensiones, textos de permisos y señales de inicio de sesión, pagos o seguimiento en archivos concretos. No puede demostrar todo el servidor, la cuenta de prueba ni cada interacción de la app en funcionamiento.
LaunchLint nunca ejecuta código ajeno. La revisión orienta la comprobación manual y relaciona pruebas con preguntas de la tienda, pero no reemplaza la responsabilidad del desarrollador ni la decisión final.
Preguntas habituales antes de enviar con Expo
¿Un EAS Build correcto basta para enviar?
No. Solo prueba que se creó el archivo de la app. El acceso de prueba, los datos de la ficha, la privacidad, las compras y los flujos reales se revisan aparte.
¿Puedo corregir un permiso iOS por OTA?
No. Los cambios de Info.plist requieren un binario nativo nuevo.
¿La cuenta demo debe tener datos reales?
No. Usa una cuenta dedicada sin datos personales ni códigos temporales.
¿LaunchLint garantiza aprobación?
No. Identifica riesgos y pruebas en los archivos del proyecto; Apple y Google toman la decisión final.