in_app_review — 3 chances par an, et Apple ne vous dira jamais rien

Votre app demande une note à l'utilisateur. Apple l'affichera 3 fois maximum par an. Et ne vous dira jamais si elle l'a fait.

Le plugin in_app_review côté Flutter, SKStoreReviewController.requestReview côté natif. L'API la plus utilisée du monde pour collecter des notes, et probablement la plus mal comprise.

Ce que requestReview fait vraiment

requestReview() ne montre pas une popup. Il demande à iOS d'en montrer une. La nuance change tout :

• 3 affichages maximum par période de 365 jours, par app et par device. La fenêtre est celle de l'OS, pas celle de vos releases : shipper plus souvent ne remet pas le compteur à zéro. Au-delà, l'appel est ignoré en silence.
• Aucun feedback développeur. Le Future complète que la popup ait été affichée ou non. Pas de callback, pas de booléen, rien. Vous ne saurez jamais si l'utilisateur a vu quelque chose, encore moins s'il a noté.
• La décision finale appartient à l'OS : quota déjà consommé, utilisateur ayant désactivé les demandes dans Réglages, contexte jugé inopportun.

Conséquence directe : chaque appel placé à un mauvais moment (au démarrage, après un crash, pendant un flow d'achat) peut brûler une des 3 cartouches annuelles sur un utilisateur agacé.

final inAppReview = InAppReview.instance;
if (await inAppReview.isAvailable()) {
  // Ceci CONSOMME potentiellement 1 de vos 3 affichages annuels.
  await inAppReview.requestReview();
  // Et vous ne saurez jamais s'il s'est passé quelque chose.
}

À ne pas confondre avec l'autre chemin : openStoreListing() (ou le deep link ?action=write-review) ouvre la page de notation du store, sans quota et sans décision de l'OS. C'est le bon outil pour un bouton « Donner votre avis » dans les réglages : l'utilisateur qui clique est volontaire. requestReview() reste réservé aux sollicitations spontanées, les 3 cartouches.

Le bon réflexe : déclencher uniquement après un moment de valeur avéré (commande livrée, objectif atteint, troisième session réussie), et tracer vos appels côté analytics pour estimer vous-même la consommation du quota.

Le twist : la guideline que tout le monde cite est fausse

En préparant ce post, j'ai demandé à une IA quelle guideline Apple interdisait le review-gating (filtrer les utilisateurs contents avant de leur demander une note). Réponse assurée : « guideline 1.1.7 ».

Vérification dans les App Store Review Guidelines, le document primaire : la 1.1.7 ne parle pas de ça. La règle pertinente est la 5.6.1, dans le Developer Code of Conduct, qui traite de la manipulation des avis.

Deuxième vérification, deuxième surprise : je n'ai trouvé aucun rejet documenté pour du review-gating seul. Des développeurs le pratiquent ouvertement depuis des années. La règle existe, le risque est réel sur le papier, mais la jurisprudence publique est vide.

Deux affirmations d'IA, deux erreurs, attrapées uniquement en ouvrant le document source. Pour un sujet aussi rabâché que les demandes de notation, le taux de bruit des sources secondaires (et des modèles entraînés dessus) est remarquable.

À retenir

• requestReview = 3 affichages max par 365 jours et par device, décision finale à l'OS, zéro feedback.
• Placez vos déclenchements après des moments de valeur, et tracez-les : c'est votre seul moyen d'estimer le quota.
• Le review-gating relève de la guideline 5.6.1 (pas 1.1.7), et aucun rejet public ne le documente.
• Sur les règles des stores, lisez le document primaire. Les résumés, humains ou IA, se trompent avec assurance.

Vous avez déjà vérifié où votre app dépense ses 3 cartouches annuelles ?