TIPS 67 · BOCCIATURA

Le refus avant celui d'Apple

Greenlight lit votre app et vous dit ce qui pourrait la faire refuser par Apple ou Google Play, avant que vous ne l'envoyiez. Comment l'installer, comment lire les résultats, comment le faire utiliser par Claude Code et ce qu'il ne peut pas voir.

Ce que c'est et pourquoi ça compte

Vous envoyez l'app en revue, vous attendez, et elle revient refusée. Il manque la connexion avec Apple, ou le compte ne peut pas être supprimé, ou la phrase qui explique pourquoi vous demandez la caméra est trop vague. Chaque aller-retour coûte des jours, et souvent la raison était déjà écrite dans vos fichiers.

Greenlight est un programme en ligne de commande qui fait ce contrôle avant vous. Il lit le code, les fichiers de configuration et, si vous la lui donnez, l'app déjà compilée. Puis il compare tout ça aux règles de revue d'Apple et aux règles de Google Play. Chaque problème a un niveau de gravité et cite la règle dont il vient. Le contrôle de base ne demande aucun compte, n'envoie rien et n'utilise pas le réseau. Il est fait par Revyl, une entreprise de test d'apps, et le code est ouvert sur GitHub sous licence MIT : il est gratuit.

C'est pour ceux qui publient seuls, sans équipe pour relire les règles d'Apple à chaque version. Une chose à dire tout de suite : c'est une liste de points à regarder, pas un tampon d'approbation. Il lit les fichiers, il n'utilise pas l'app. La section 6 explique ce qu'il ne voit pas.

1. Ce qu'il contrôle

La commande principale s'appelle preflight, comme la vérification avant le décollage. Elle lance ensemble cinq contrôles, que la documentation appelle des scanners :

  • metadata : nom, version, format du bundle ID (l'identifiant de l'app), icône, lien vers la politique de confidentialité et les phrases qui expliquent pourquoi vous demandez une autorisation. Il les lit dans Info.plist ou, pour les apps Expo, dans app.json.
  • codescan : 24 règles sur le code Swift, Objective-C, React Native et Expo. Par exemple des clés secrètes écrites dans le code, une connexion Google sans connexion avec Apple, un compte qu'on crée mais qu'on ne peut pas supprimer.
  • privacy : le manifeste de confidentialité exigé par Apple (PrivacyInfo.xcprivacy) est-il là, et complet ? Et si vous utilisez des SDK de suivi, y a-t-il la fenêtre ATT qui demande l'autorisation de suivre ?
  • playscan : uniquement pour les projets Android. Les règles de Google Play : le niveau d'API Android à cibler et ses échéances, les autorisations qui demandent un formulaire de déclaration, les services au premier plan, la version de Play Billing pour les paiements.
  • ipa : l'app iPhone déjà compilée, le fichier .ipa. Il vérifie les clés d'Info.plist, l'écran de lancement, les icônes, le poids de l'app et les manifestes de confidentialité des frameworks inclus. Il ne tourne que si vous lui passez le fichier.

Si le même dossier contient à la fois la partie iOS et la partie Android, comme dans une app Flutter ou React Native, il contrôle les deux en un seul passage.

2. L'installer et lancer le premier contrôle

Il s'installe depuis le terminal. Sur Mac, avec Homebrew, le programme qui installe d'autres programmes en ligne de commande. Si vous avez plutôt Go, le langage dans lequel Greenlight est écrit, utilisez la deuxième ligne.

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

Ensuite, placez-vous dans le dossier principal du projet et lancez le contrôle. Le point veut dire « ce dossier ». Ça prend moins d'une seconde.

La commande
greenlight preflight .

Si vous avez déjà exporté l'app pour l'App Store, ajoutez le fichier .ipa : il contrôle alors aussi l'app compilée, pas seulement les sources. Pour Android, c'est pareil avec --apk ou --aab, le fichier que vous envoyez sur Play. Mettez le chemin de votre fichier à la place de l'exemple.

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

3. Comment lire le résultat

Chaque problème trouvé est accompagné de quatre choses : le niveau de gravité, la règle d'Apple ou de Google dont il vient, le fichier où il a été trouvé et une suggestion pour le corriger. Il y a quatre niveaux :

  • CRITICAL : le refus, ou une installation qui échoue, est presque certain. À corriger avant l'envoi.
  • HIGH : une échéance déjà publiée, une déclaration obligatoire qui manque ou quelque chose qui casse pendant que l'app tourne.
  • WARN : le relecteur le remarquera probablement et vous demandera des explications.
  • INFO : bonne pratique. Ne bloque rien.

En bas, il y a le verdict : NOT READY s'il reste au moins un CRITICAL, NEEDS REVIEW s'il reste des HIGH, GREENLIT quand il n'y a plus ni l'un ni l'autre. GREENLIT veut dire que le contrôle des fichiers est passé, pas qu'Apple va vous approuver.

4. Le faire utiliser par Claude Code

Greenlight existe aussi sous forme de plugin pour Claude Code. Le plugin n'est pas le programme : c'est une skill, une feuille d'instructions qui explique à Claude comment lancer le contrôle, lire les résultats, corriger le code et relancer. Dans Claude Code, tapez :

Les commandes
/plugin marketplace add RevylAI/greenlight
/plugin install greenlight

Le plugin n'installe pas le programme tout seul : faites-le d'abord, comme à l'étape 2. Puis ouvrez Claude Code dans le dossier du projet et collez :

Le message
Lance greenlight preflight et corrige tout jusqu'à ce que ça passe. Commence par les CRITICAL, puis les HIGH. Après chaque série de corrections, relance le contrôle. Si un problème te semble être une fausse alerte, ne touche pas au code : arrête-toi et explique-moi pourquoi.

J'ai mis les HIGH exprès. Les instructions du plugin considèrent le travail terminé quand il ne reste aucun CRITICAL. Mais les HIGH restent, et parmi eux il y a justement la connexion avec Apple qui manque et le compte qu'on ne peut pas supprimer.

Quand un résultat n'est pas clair, faites-le-vous expliquer avant de toucher à quoi que ce soit :

Le message
Explique-moi ce résultat de Greenlight avec des mots simples : [colle la ligne]. Dis-moi quelle règle d'Apple ou de Google il cite, dans quel fichier il l'a trouvé et ce qui y est écrit. Puis dis-moi si, pour toi, c'est un vrai problème ou une fausse alerte, et comment je peux le vérifier moi-même.

Et une fois que vous savez que c'est une fausse alerte :

Le message
Ce résultat de Greenlight est une fausse alerte : [colle la ligne]. S'il vient du contrôle du code (codescan), crée ou mets à jour .greenlight.yml dans le dossier principal : baisse la gravité de cette règle ou exclus seulement le fichier ou le dossier nécessaire, sans désactiver d'autres contrôles. Ajoute à côté un commentaire avec la raison. S'il vient d'un autre contrôle, ne change rien et dis-le-moi.

5. Fausses alertes et contrôle automatique

Le fichier .greenlight.yml

Il se place dans le dossier principal du projet et règle le contrôle du code, y compris quand il tourne dans preflight. Pour chaque règle, vous pouvez changer la gravité (info, warn ou critical) ou la désactiver, et vous pouvez exclure des dossiers, des fichiers ou des chemins.

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

Pour une seule ligne, il y a un commentaire à mettre sur cette ligne ou sur celle du dessus : // greenlight:ignore suivi du nom de la règle. Sans le nom, il désactive toutes les règles sur cette ligne. Mieux vaut l'écrire, pour que les autres contrôles restent actifs.

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

Le contrôle à chaque version

Avec --exit-code, la commande se termine par une erreur si elle trouve un CRITICAL ou un HIGH, ou si l'un des contrôles a planté : ainsi, un contrôle fait à moitié ne passe jamais pour réussi. Mettez-le dans votre CI, les contrôles automatiques lancés à chaque push, par exemple GitHub Actions : une version avec un problème grave s'arrête toute seule.

La commande
greenlight preflight . --exit-code

6. Ce qu'il ne voit pas

Greenlight lit du texte, il n'ouvre jamais l'app. Si le code contient un bouton « Supprimer le compte » relié à rien, il voit le mot, la règle passe, et Apple vous refuse quand même en appuyant dessus.

Ensuite, il y a les fausses alertes. Le cas le plus clair est le ticket numéro 30 sur leur GitHub : dans des apps sans aucune publicité, la règle sur les annonces Google se déclenche parce qu'elle trouve « ads » dans des mots ordinaires comme loadSdk ou downloads. Elle donne un CRITICAL sans indiquer le fichier et suggère d'ajouter la fenêtre ATT, ce qui, dans une app qui ne suit personne, est justement la mauvaise chose à faire. Avant de corriger, regardez toujours ce qu'il y a vraiment dans votre code.

Et le code qu'il lit, c'est seulement Swift, Objective-C, React Native et Expo. Notre app est faite avec Flutter : il ne lit pas le code Dart, donc une connexion Google sans Apple écrite en Dart lui échappe. Il lit en revanche Info.plist, le manifeste de confidentialité, le manifeste Android, les fichiers Gradle et l'app compilée. Sur Flutter, passez-lui toujours les fichiers compilés, et testez à la main la connexion et la suppression du compte.

Deux commandes facultatives ne sont pas hors ligne : verify teste certains parcours sur un téléphone dans le cloud et demande un compte Revyl ; scan --app-id contrôle la fiche sur App Store Connect et demande d'y être connecté. Ce guide ne les utilise pas.

Les erreurs les plus courantes

  • Prendre GREENLIT pour une approbation. Ça veut dire qu'il ne reste rien de grave dans les fichiers, pas que l'app fonctionne.
  • Corriger une fausse alerte. Avant d'ajouter la fenêtre ATT ou de changer du code, regardez ce qu'il a vraiment trouvé, et où.
  • Ne contrôler que les sources. Les autorisations ajoutées par les bibliothèques n'apparaissent que dans le fichier compilé : passez-lui aussi le .ipa, .apk ou .aab.
  • Se fier au feu vert sur une app Flutter. Il ne lit pas le Dart : la connexion et la suppression du compte, c'est vous qui les testez, sur le téléphone.

Check-list

  • Greenlight installé, dans sa dernière version
  • greenlight preflight . lancé dans le dossier principal du projet
  • Contrôle refait avec le fichier compilé : .ipa, .apk ou .aab
  • Zéro CRITICAL et zéro HIGH, ou chacun expliqué
  • Chaque fausse alerte vérifiée à la main et notée dans .greenlight.yml ou avec greenlight:ignore
  • greenlight preflight . --exit-code dans la CI
  • Suppression du compte, restauration des achats et connexion avec Apple testées sur la vraie app

Questions fréquentes

Greenlight envoie-t-il mon code quelque part ?

Non. preflight et les autres contrôles tournent sur votre ordinateur, sans compte et sans réseau. Seuls verify et scan passent par le réseau, et vous ne les lancez que si vous le voulez.

Si ça passe, Apple va-t-il l'approuver ?

Pas forcément. Greenlight contrôle les fichiers, alors qu'Apple teste certains parcours à la main. Il élimine les erreurs visibles dans le texte ; le reste, c'est à vous de le tester sur la vraie app.

Faut-il Claude Code pour l'utiliser ?

Non. C'est un programme en ligne de commande qui fonctionne tout seul. Le plugin sert si vous voulez que ce soit Claude qui lance le contrôle, corrige et relance.

← Tous les guides