LaunchLint Academy
La respuesta breve
- React Native y Expo no son categorías de rechazo. El riesgo aparece entre JavaScript, configuración nativa, backend, metadata y el recorrido que el reviewer puede probar.
- Los grupos más comprobables son app incompleta (2.1), metadata inexacta (2.3), pagos (3.1), valor insuficiente (4.2) y privacidad o eliminación de cuenta (5.1).
- Reproduce el recorrido en el build enviado, corrige la causa y responde con evidencia verificable, no con una garantía genérica.
1. Por qué React Native casi nunca es la causa
Apple revisa el producto entregado, su metadata y el comportamiento observable. SwiftUI, React Native o Expo no cambian los requisitos. El framework importa cuando una abstracción oculta detalles nativos: un config plugin añade permisos, un SDK transmite datos, app.config resuelve valores distintos o una actualización OTA deja de corresponder al binario.
Asigna primero el problema a una capa. Un crash de login pertenece al build o backend; una compra invisible puede ser configuración de producto o acceso; una respuesta de privacidad vive en la consola aunque el origen sea un SDK. Separar capas evita arreglos precipitados.
| Capa | Evidencia | Pregunta |
|---|---|---|
| archivos del proyecto/build | Plugins, permisos, SDKs, IDs | ¿Está en el artefacto enviado? |
| App | Crash, login, compra, borrado | ¿Lo reproduce un usuario nuevo? |
| Store | Capturas, privacidad, notas | ¿Describe este build? |
2. Guideline 2.1: build incompleto o acceso bloqueado
La 2.1 cubre más que crashes. Apple espera binario final, metadata completa, URLs funcionales y acceso a funciones esenciales. Apps estables fallan por cuentas demo caducadas, backend dormido, códigos de un solo uso o feature flags desactivados para review.
Prueba en otro dispositivo:
- Primer inicio sin sesión
- Credenciales exactas de review
- Backend y medios accesibles
- Función principal sin invitación interna
- Compras visibles y actuales
- Rechazar permisos no bloquea la app
- URLs públicas de soporte y privacidad
3. Guideline 2.3: la promesa de la ficha contradice la app
Descripción, capturas, previews y privacidad deben representar la experiencia principal. El conflicto típico aparece cuando las capturas vienen de una rama más nueva o anuncian un flujo premium inaccesible para la cuenta de review.
Relaciona cada afirmación fuerte con un recorrido. Anónimo, offline, sin tracking o con IA exige cuidado porque SDKs y llamadas de red pueden contradecirlo. Elimina menús debug, placeholders, precios de prueba y logos de otras plataformas.
- Capturas de UI alcanzable
- Nombre sin funciones ausentes
- Compras adicionales explicadas
- What’s New específico
- Edad coherente con contenido y UGC
- política de privacidad y etiqueta describen la misma versión
4. Guideline 3.1: compras digitales y restauración
Para desbloquear funciones, contenido o suscripciones digitales importa la vía de pago. Tener Stripe en el archivos del proyecto no es automáticamente infracción; el riesgo es usarlo para desbloqueo digital dentro de iOS o dirigir a una compra externa no permitida en ese storefront. Las excepciones regionales requieren análisis concreto.
Incluso StoreKit correcto falla si los productos no se enviaron, no son visibles o no pueden probarse. Verifica carga, cancelación, éxito, restore, suscripción activa y reinstalación. Explica en indicaciones para el equipo de revisión cuándo aparece cada producto.
- Estado y contratos de productos
- Paywall accesible para review
- Restore visible
- Precio y periodo claros
- Sin secretos en código o notas
- Disponibilidad regional documentada
5. Guideline 4.2: valor insuficiente
La 4.2 afecta a wrappers de web, colecciones de enlaces, material promocional y apps sin utilidad duradera. Es común en WebViews y plantillas. Añadir botones nativos no basta: se valora la función real y el beneficio específico.
Define el trabajo recurrente que resuelve la app y por qué el móvil aporta valor. Offline, cámara, ubicación, notificaciones o captura del dispositivo ayudan solo si funcionan. No inventes funciones decorativas o incompletas para la review.
6. Guideline 5.1: privacidad, permisos y borrado
Los problemas nacen de diferencias: SDKs no mencionados, purpose strings vagos o respuestas que dicen sin recogida cuando hay transmisión. El proveedor responde también por código de terceros.
Si se crean cuentas, Apple espera iniciar su eliminación dentro de la app. Cerrar sesión o desactivar no basta. Explica retención, contempla suscripciones y prueba confirmación, reautenticación y errores.
- Purpose strings concretos
- Inventario de SDK y datos
- política de privacidad pública con retención
- Ruta in-app de borrado
- Respuestas contrastadas con transmisión
- Nuevo binario tras cambios nativos
7. Del rechazo a un resubmit verificable
Lee la guideline, el recorrido y los adjuntos. Reproduce el problema con el build rechazado antes de cambiar código. Decide después si necesitas binario nuevo o si basta corregir metadata; Apple permite reenviar el mismo build tras ciertos problemas de metadata.
La respuesta debe nombrar causa, cambio y lugar de comprobación: build, menú y cuenta. Evita discutir sobre React Native o decir todo funciona sin evidencia.
- Anotar pasos del reviewer
- Reproducir en el build rechazado
- Asignar una capa
- Documentar fix y regresión
- Indicar build y ruta
- Responder de forma breve
- Apelar solo una interpretación realmente discutida
Preguntas frecuentes
¿Rechazan más las apps React Native?
Apple no publica una tasa fiable por framework. Importan estabilidad, configuración nativa, metadata, pagos, privacidad y acceso completo.
¿Siempre necesito un build nuevo?
No para algunos problemas de metadata. Sí cuando cambias código, SDKs, permisos o configuración nativa.
¿LaunchLint garantiza la aprobación?
No. Detecta señales reproducibles y crea tareas con evidencia, pero no sustituye backend ni decisión humana.
¿Cómo respondo a un rechazo ambiguo?
Pide el recorrido exacto, reprodúcelo y responde con build, navegación y evidencia. Apela si la interpretación sigue siendo discutible.