El rechazo antes que el de Apple

Qué es y por qué importa

Mandas la app a revisión, esperas, y vuelve rechazada. Falta el inicio de sesión con Apple, o la cuenta no se puede borrar, o la frase que explica por qué pides la cámara es demasiado vaga. Cada vuelta son días perdidos, y muchas veces el motivo ya estaba escrito en tus archivos.

Greenlight es un programa de terminal que hace esa revisión antes que tú. Lee el código, los archivos de configuración y, si se la das, la app ya compilada. Luego lo compara todo con las reglas de revisión de Apple y con las políticas de Google Play. Cada problema tiene un nivel de gravedad y cita la regla de la que sale. La revisión básica no pide cuenta, no sube nada y no usa la red. Lo hace Revyl, una empresa de pruebas de apps, y el código está abierto en GitHub con licencia MIT: se usa gratis.

Es para quien publica solo, sin un equipo que relea las reglas de Apple en cada versión. Una cosa hay que decirla ya: es una lista de cosas que mirar, no un sello de aprobación. Lee los archivos, no usa la app. En la sección 6 tienes lo que no ve.

1. Qué revisa

El comando principal se llama preflight, como la revisión antes del despegue. Lanza a la vez cinco revisiones, que en la documentación se llaman scanners:

• metadata: nombre, versión, formato del bundle ID (el identificador de la app), icono, enlace a la política de privacidad y las frases que explican por qué pides un permiso. Los lee en Info.plist o, en las apps Expo, en app.json.
• codescan: 24 reglas sobre código Swift, Objective-C, React Native y Expo. Por ejemplo claves secretas escritas en el código, login con Google sin el inicio de sesión con Apple, cuentas que se crean pero no se borran.
• privacy: ¿está el manifiesto de privacidad que pide Apple (PrivacyInfo.xcprivacy) y está completo? Y si usas SDK de seguimiento, ¿está el pop-up ATT que pide permiso para rastrear?
• playscan: solo para proyectos Android. Las reglas de Google Play: el nivel de API de Android que hay que usar como objetivo y sus plazos, los permisos que exigen un formulario de declaración, los servicios en primer plano, la versión de Play Billing para los pagos.
• ipa: la app para iPhone ya compilada, el archivo .ipa. Revisa las claves de Info.plist, la pantalla de inicio, los iconos, el peso de la app y los manifiestos de privacidad de los frameworks incluidos. Solo se ejecuta si le pasas el archivo.

Si en la misma carpeta están tanto la parte iOS como la Android, como en una app Flutter o React Native, revisa las dos en una sola pasada.

2. Instálalo y lanza la primera revisión

Se instala desde la terminal. En Mac, con Homebrew, el programa que instala otros programas desde la terminal. Si en cambio tienes Go, el lenguaje en el que está escrito Greenlight, usa la segunda línea.

brew install revylai/tap/greenlight
go install github.com/RevylAI/greenlight/cmd/greenlight@latest

Luego entra en la carpeta principal del proyecto y lanza la revisión. El punto quiere decir «esta carpeta». Tarda menos de un segundo.

greenlight preflight .

Si ya has exportado la app para el App Store, añade el archivo .ipa: así revisa también la app compilada, no solo el código fuente. Para Android es lo mismo con --apk o --aab, el archivo que subes a Play. Pon la ruta de tu archivo en lugar del ejemplo.

greenlight preflight . --ipa build.ipa
greenlight preflight . --aab app-release.aab

3. Cómo leer el resultado

Cada problema encontrado trae cuatro cosas: el nivel de gravedad, la regla de Apple o de Google de la que sale, el archivo donde lo ha encontrado y una sugerencia para arreglarlo. Los niveles son cuatro:

• CRITICAL: el rechazo, o una instalación que falla, es casi seguro. Se arregla antes de enviar.
• HIGH: un plazo ya publicado, una declaración obligatoria que falta o algo que se rompe mientras la app funciona.
• WARN: es probable que el revisor lo note y te pida explicaciones.
• INFO: buena práctica. No bloquea nada.

Al final está el veredicto: NOT READY si queda al menos un CRITICAL, NEEDS REVIEW si quedan HIGH, GREENLIT cuando ya no queda ninguno de los dos. GREENLIT quiere decir que la revisión de los archivos ha pasado, no que Apple te vaya a aprobar.

4. Haz que lo use Claude Code

Greenlight también existe como plugin de Claude Code. El plugin no es el programa: es una skill, es decir, una hoja de instrucciones que le dice a Claude cómo lanzar la revisión, leer los resultados, corregir el código y volver a lanzarla. Dentro de Claude Code escribe:

/plugin marketplace add RevylAI/greenlight
/plugin install greenlight

El plugin no instala el programa por sí solo: hazlo tú antes, como en el paso 2. Luego abre Claude Code en la carpeta del proyecto y pega:

Lanza greenlight preflight y corrige todo hasta que pase. Empieza por los CRITICAL, luego los HIGH. Después de cada ronda de correcciones vuelve a lanzar la revisión. Si un problema te parece una falsa alarma, no toques el código: para y explícame por qué.

Los HIGH los he puesto a propósito. Las instrucciones del plugin dan el trabajo por terminado cuando no queda ningún CRITICAL. Pero los HIGH se quedan, y entre ellos están justo el inicio de sesión con Apple que falta y la cuenta que no se puede borrar.

Cuando un resultado no te queda claro, haz que te lo explique antes de tocar nada:

Explícame este resultado de Greenlight con palabras sencillas: [pega la línea]. Dime qué regla de Apple o de Google cita, en qué archivo lo ha encontrado y qué pone ahí. Luego dime si crees que es un problema real o una falsa alarma, y cómo lo compruebo yo.

Y cuando ya sabes que es una falsa alarma:

Este resultado de Greenlight es una falsa alarma: [pega la línea]. Si viene de la revisión del código (codescan), crea o actualiza .greenlight.yml en la carpeta principal: baja la gravedad de esa regla o excluye solo el archivo o la carpeta necesarios, sin apagar otras revisiones. Escribe al lado un comentario con el motivo. Si viene de otra revisión, no cambies nada y dímelo.

5. Falsas alarmas y revisión automática

El archivo .greenlight.yml

Va en la carpeta principal del proyecto y ajusta la revisión del código, también cuando se ejecuta dentro de preflight. Para cada regla puedes cambiar la gravedad (info, warn o critical) o apagarla, y puedes excluir carpetas, archivos o rutas.

rules:
  hardcoded-ipv4:
    severity: info
  platform-reference:
    enabled: false
ignore:
  - vendor
  - "*.generated.ts"

Para una sola línea hay un comentario que se pone en esa línea o en la de arriba: // greenlight:ignore seguido del nombre de la regla. Sin el nombre apaga todas las reglas de esa línea. Mejor escribirlo, así las demás revisiones siguen encendidas.

let host = "10.1.2.3" // greenlight:ignore hardcoded-ipv4

La revisión en cada versión

Con --exit-code el comando termina con un error si encuentra un CRITICAL o un HIGH, o si una de las revisiones se ha bloqueado: así una revisión a medias nunca pasa por buena. Ponlo en la CI, es decir, las revisiones automáticas que se lanzan en cada push, por ejemplo GitHub Actions: una versión con un problema grave se para sola.

greenlight preflight . --exit-code

6. Lo que no ve

Greenlight lee texto, nunca abre la app. Si en el código hay un botón «Eliminar cuenta» que no está conectado a nada, ve la palabra, la regla pasa, y Apple te rechaza igual cuando lo pulsa.

Luego están las falsas alarmas. El caso más claro es la incidencia número 30 de su GitHub: en apps sin ninguna publicidad, la regla de anuncios de Google salta porque encuentra «ads» dentro de palabras normales como loadSdk o downloads. Da un CRITICAL sin indicar el archivo y sugiere añadir el pop-up ATT, que en una app que no rastrea es justo lo que no hay que hacer. Antes de corregir, mira siempre qué hay de verdad en tu código.

Y el código que lee es solo Swift, Objective-C, React Native y Expo. Nuestra app está hecha con Flutter: el código Dart no lo lee, así que un login con Google sin Apple escrito en Dart no lo encuentra. Sí lee Info.plist, el manifiesto de privacidad, el manifiesto de Android, los archivos Gradle y la app compilada. En Flutter pásale siempre los archivos compilados, y prueba a mano el login y el borrado de la cuenta.

Dos comandos opcionales no son offline: verify prueba algunos flujos en un teléfono en la nube y pide una cuenta de Revyl; scan --app-id revisa la ficha en App Store Connect y pide iniciar sesión allí. Esta guía no los usa.

Errores comunes

• Tomar GREENLIT por una aprobación. Quiere decir que en los archivos no queda nada grave, no que la app funcione.
• Corregir una falsa alarma. Antes de añadir el pop-up ATT o cambiar código, mira qué ha encontrado de verdad y dónde.
• Revisar solo el código fuente. Los permisos que añaden las librerías solo se ven en el archivo compilado: pásale también el .ipa, .apk o .aab.
• Fiarse del verde en una app Flutter. El Dart no lo lee: el login y el borrado de la cuenta los pruebas tú, en el teléfono.

Lista de comprobación

• Greenlight instalado, en la última versión
• greenlight preflight . lanzado en la carpeta principal del proyecto
• Revisión repetida con el archivo compilado: .ipa, .apk o .aab
• Cero CRITICAL y cero HIGH, o cada uno explicado
• Cada falsa alarma comprobada a mano y anotada en .greenlight.yml o con greenlight:ignore
• greenlight preflight . --exit-code en la CI
• Borrado de cuenta, restaurar compras e inicio de sesión con Apple probados en la app real

Preguntas frecuentes