LaunchLint Academy
La respuesta breve
- Explica acceso, navegación, requisitos, funciones no evidentes, compras y cambios tras un rechazo; no repitas la descripción.
- Ofrece una cuenta demo duradera, mantén el backend disponible y prueba el recorrido en un dispositivo limpio con el build enviado.
- Escribe de forma breve y verificable. Nunca compartas API keys, acceso admin o datos reales de clientes.
1. Para qué sirven las indicaciones para el equipo de revisión
Apple pide explicaciones de funciones y compras no evidentes. Las notes son privadas y complementan contacto, cuenta demo y adjuntos. Evitan preguntas y rutas bloqueadas.
No son otra descripción. ‘La app funciona’ no ayuda; ‘Projects > Demo Project > Export abre el PDF sin compra’ sí puede probarse.
2. Información mínima
Mantén nombre, teléfono, email y necesidad de demo actualizados y monitorizados. Un contacto ausente retrasa la review.
Empieza con versión y build; añade solo cambios y requisitos de ese artefacto. Elimina instrucciones antiguas.
- Versión y build
- Cambio principal
- Cuenta o demo mode
- Ruta corta
- Rol, región, QR o hardware
- Condiciones de IAP
- Contacto monitorizado
3. Una cuenta demo resistente
No debe depender de tu teléfono, email temporal, aprobación manual o magic link caducable. Mantén backend y medios online.
Usa datos ficticios que muestren estados relevantes. Decide si una cuenta cubre roles o si hacen falta varias. Prueba fuera de tu red.
- Sin cuenta personal
- Sin datos de clientes
- Password estable
- 2FA documentado
- Datos de ejemplo
- Sin limpieza automática
- Monitoring y responsable
4. Describir flujos no evidentes
Indica requisito, navegación, acción y resultado. No obligues a adivinar feature flags, roles, QR, ubicación, Bluetooth o contenido aprobado. Adjunta un ejemplo ficticio si hace falta.
Para permisos nombra la función; para borrado, la ruta; para UGC, reportar y bloquear; para región, la activa en demo.
| Vago | Nota |
|---|---|
| Login funciona | Entrar con demo; Projects muestra dos ejemplos |
| Cámara necesaria | Project > Scan receipt abre cámara |
| Hay borrado | Settings > Account > Delete |
| Premium probado | Demo tiene test subscription; Export está en Demo Project |
5. Compras y suscripciones revisables
Los IAP deben estar completos, actuales, visibles y funcionales. Explica una paywall condicionada, producto regional o compra ligada a un rol.
Nombra producto visible y ruta. Prueba restore, suscripción activa, error y reinstalación. Si demo ya es premium, explica cómo ver paywall.
- Productos listos
- Agreements activos
- Paywall accesible
- Términos coherentes
- Restore
- Sandbox probado
- Condición en una frase
6. Plantilla práctica
Usa estructura repetible sin boilerplate viejo. Elimina lo irrelevante y actualiza build, rutas y cuenta. Inglés simple suele ser robusto.
BUILD
- Version / build: [1.0.0 / 42]
- Main change: [one factual sentence]
REVIEW ACCESS
- Demo account: [dedicated review account]
- Path: Launch app > Sign in > [feature]
- Required role or setup: [only if applicable]
NON-OBVIOUS FLOWS
- Purchase appears when: [condition]
- Account deletion: Settings > Account > Delete account
- Permission purpose: [feature and user value]
CONTACT
- Name: [responsible person]
- Email / phone: [monitored during review]Guarda la plantilla en el proceso de release, no como secret hard-coded. Introduce credenciales mediante un flujo controlado y revisa números antiguos.
7. Responder a un rechazo con evidencia
Lee guideline y recorrido, reproduce en el build rechazado y decide si basta metadata o necesitas binario nuevo. Puedes responder y adjuntar evidencia antes del resubmit.
Indica causa, cambio y comprobación con build y ruta. Pide pasos exactos si no reproduces el mensaje.
- Guardar mensaje
- Reproducir
- Terminar fix
- Probar regresión
- Actualizar notes
- Indicar build y ruta
- Adjuntar solo lo relevante
- No garantizar aprobación
8. Revisión final de las Notes
Haz que otra persona siga las Notes palabra por palabra en un dispositivo sin sesión. No debe necesitar información oral, VPN interna ni permisos de administrador. Si se detiene, corrige primero el producto o el acceso y después el texto. Las instrucciones no deben esconder un flujo roto.
Comprueba también vigencia: build number, nombre visible del producto, menús traducidos, credenciales, región y datos de ejemplo. Abre cada attachment y URL desde una red externa. Confirma que el contacto conoce la fecha del envío y puede responder durante la review.
Checklist de entrega:
- Build y versión correctos
- Credenciales probadas justo antes del submit
- Backend y media disponibles
- Ruta principal en menos pasos posibles
- Todos los roles y condiciones explicados
- IAP visibles y restore probado
- Borrado de cuenta localizado
- Permisos ligados a una función
- Sin secrets ni datos reales
- Contacto de review avisado
- Texto antiguo eliminado
- Copia de las Notes guardada con la release
9. Integrar las Notes en el proceso de release
Las Notes pierden valor si se redactan de memoria cinco minutos antes del submit. Crea una tarea de release con propietario, fecha y build. El responsable de producto confirma los flujos; ingeniería valida el artefacto y sus dependencias; soporte sabe cuándo puede llegar una pregunta. Guarda la versión enviada junto al changelog para reproducir exactamente lo que leyó el reviewer.
Después de una aprobación o rechazo, registra qué instrucción funcionó y qué estado faltó. No conviertas esa información en boilerplate permanente: revisa cada frase contra el siguiente build. Si una ruta, rol, producto IAP o cuenta cambia, actualiza la nota y vuelve a ejecutar el recorrido. Así las indicaciones para el equipo de revisión se convierten en evidencia operativa y no en un texto decorativo.
Handoff mínimo:
- Owner y contacto asignados
- Texto ligado a versión y build
- Cuenta demo probada por otra persona
- Adjuntos archivados
- Respuesta del reviewer registrada
- Aprendizaje aplicado a la siguiente release
Preguntas frecuentes
¿Inglés o español?
El inglés simple suele ser robusto; importan más rutas y credenciales exactas.
¿Puedo incluir credenciales?
Sí para una cuenta demo controlada, nunca secrets de infraestructura.
¿Sin login necesito notes?
Solo para funciones, compras o requisitos no evidentes. Evita boilerplate.
¿Una captura evita un build nuevo?
No cuando hace falta corregir código o configuración nativa.