Note, août 2026 : cet article date d’une version antérieure et décrit la structure des formules de l’époque. AlcoLog a fusionné la formule Pro dans Premium en v1.2.0, il n’y a donc plus qu’une seule formule payante. Rien n’a été perdu dans la fusion, et les personnes qui avaient Pro sont passées à Premium sans surcoût.

Si tu t’apprêtes à publier une app iOS en v1.0 avec des abonnements, des achats intégrés, un compagnon Watch, des widgets ou un positionnement de près ou de loin lié à la santé, le processus d’App Review va être plus dur que ne le laisse penser la documentation. Cet article est le compte rendu d’un cycle de lancement (quatre refus en cinq jours, cinq relecteurs, un seul binaire) et des schémas qui ont rendu ce cycle supportable. Je le partage parce que cette expérience est l’une des parties les moins documentées de la publication d’une app indépendante sérieuse, et que la version documentée (les sessions WWDC, la page des Review Guidelines, les forums développeurs) ne correspond pas à la réalité du terrain.

Si tu es en plein cycle et que tu cherches des correctifs concrets, saute directement à « Ce qu’il faut corriger avant de soumettre » et « Les motifs qu’il vaut la peine de comprendre ». La chronologie personnelle est dans la seconde moitié si tu veux du contexte.

# Ce qu’il faut corriger avant de soumettre

Voici les points qui sont revenus au fil de quatre refus. Si tu les corriges en amont, tu élimines l’essentiel de la surface de refus d’une v1.0 avec abonnements dans une catégorie sensible.

# La hiérarchie d’affichage des prix sur les écrans d’abonnement

Les Human Interface Guidelines d’Apple sur les abonnements sont sans ambiguïté sur la présentation des prix. Le montant facturé doit être l’élément tarifaire le plus visible. L’instinct marketing (donner à la réduction l’air d’être le gain) est le mauvais instinct ici. L’instinct de conformité (faire du montant facturé le héros typographique) est le bon.

Ce que cela veut dire en pratique : le prix normal doit être l’élément le plus grand et le plus gras. Le prix d’introduction ou remisé doit être plus petit, avec une mention explicite « Première période : ». Évite les pastilles de pourcentage en petits caractères (utilise « OFFRE DE LANCEMENT » plutôt que « -25 % »). L’application de la règle 3.1.2© Payments and Subscriptions sur ce point est cohérente d’un relecteur à l’autre.

# Un chemin de suppression des données explicite

Même quand ton « compte » n’est qu’un identifiant anonyme optionnel, la règle 5.1.1(v) d’Apple exige un chemin de suppression étiqueté, visible et immédiat. Désactiver une option en guise de suppression implicite passe pour conforme côté développeur, mais ne satisfait pas l’application actuelle de la règle.

Intègre un bouton explicite « Supprimer mes données » dans l’écran de confidentialité ou de réglages dès la première version. Ajoute une alerte de confirmation. Assure-toi que le texte qui l’entoure décrit le comportement réel de suppression, et non un délai fictif que tu comptes réviser plus tard.

# Auditer l’Info.plist pour les déclarations vestigiales

Les modes d’arrière-plan, le background fetch, les droits de localisation, les déclarations HealthKit et les entrées d’Info.plist du même genre peuvent rester inutilisés pendant des mois pendant que le code évolue. Ils se font épingler dès qu’ils ne correspondent pas à une vraie fonctionnalité. L’application de la règle 2.5.4 Software Requirements est ici mécanique et sans ambiguïté.

Concrètement : toute entrée UIBackgroundModes doit correspondre à une fonctionnalité qui s’en sert réellement. Si ton app déclare « location » comme mode d’arrière-plan mais que tu n’utilises jamais la localisation continue en arrière-plan et que allowsBackgroundLocationUpdates = false, retire la déclaration. La surveillance de région ne l’exige pas. L’audit prend dix minutes et évite un cycle de refus.

# Un lien fonctionnel vers les conditions d’utilisation dans les métadonnées App Store

Le champ Politique de confidentialité dans App Store Connect est bien connu. L’exigence sur les conditions d’utilisation l’est moins. Si tu utilises le CLUF standard d’Apple, inclus un lien vers les conditions d’utilisation dans la description de l’app. Si tu utilises un CLUF personnalisé, ajoute-le dans le champ CLUF personnalisé d’App Store Connect.

La page de conditions elle-même doit indiquer tous les produits payants avec la durée de l’abonnement, le prix et le mécanisme de renouvellement. La plupart des équipes ont ces éléments éparpillés sur des pages distinctes ou enfouis dans la politique de confidentialité. Regroupe-les sur une seule page de conditions que le relecteur peut lire en deux minutes.

# Les vidéos App Preview : utilise des captures d’écran brutes

Les maquettes de téléphone en 3D, les cadres d’appareil et les compositions marketing stylisées relèvent de l’appréciation du relecteur au titre de la règle 2.3.4 Accurate Metadata. La page d’orientation publique n’interdit pas explicitement les cadres d’appareil, mais le matériel de formation interne dont se servent les relecteurs semble le faire. Les captures d’écran simples, à la résolution native, sont sans ambiguïté sûres.

Garde les habillages marketing pour ton propre site, les réseaux sociaux et Reddit. Mets des captures d’écran dans l’emplacement App Preview. L’écart de conversion entre « aperçu en maquette soignée » et « aperçu en enregistrement d’écran brut » est faible. La réduction du risque, elle, est grande.

# Une navigation explicite vers les achats intégrés dans les notes d’App Review

Les relecteurs travaillent avec un budget de 5 à 15 minutes par app. Ils ne trouveront pas toujours chaque achat intégré rattaché à la version. Si tes achats intégrés sont accessibles par des chemins différents dans l’app (écrans de vente séparés, cartes séparées, navigation plus profonde), inclus un fil d’Ariane de navigation, clic par clic, pour chaque achat intégré dans tes notes d’App Review.

Un format qui fonctionne :

Abonnements Premium et achat Lifetime : onglet Réglages > carte Premium > bouton Passer à Premium > fiche de mise à niveau Premium Abonnements Pro et achat Lifetime : onglet Réglages > carte Pro > bouton Passer à Pro Articles consommables du Tip Jar : onglet Réglages > faire défiler sous les cartes de formule > carte Tip Jar > Afficher les options de pourboire

Cela paraît excessif. Cela évite un cycle de refus bien précis (règle 2.1(b) Information Needed) qui te coûte sinon une journée.

# Une marge de calendrier entre la soumission et la date de lancement annoncée

Pour une soumission v1.0 avec abonnements dans une catégorie sensible, prévois au moins sept jours calendaires entre la première soumission et la date de lancement que tu as annoncée à l’extérieur. Chaque cycle de refus dure environ 24 heures si tu réponds rapidement. Quatre cycles de refus est un pire cas réaliste pour une v1.0 en catégorie sensible.

Si ta date de lancement est engagée à l’extérieur (précommande configurée, événements in-app programmés, campagne marketing réservée, journalistes démarchés), sept jours de marge sont le minimum. Dix jours sont plus confortables. En dessous de sept, tu risques de rater la date pour un seul refus de procédure.

# Les motifs qu’il vaut la peine de comprendre

Quelques observations de l’intérieur du cycle, qui ne sautent pas aux yeux à la lecture de la documentation.

# Chaque refus trouve des choses différentes

Les quatre refus sont revenus en épinglant des points qui ne se recoupaient pas. Chaque relecteur avait accès à chaque écran que le précédent avait validé. Le premier a épinglé un lien CLUF dans les métadonnées. Le deuxième a épinglé trois points différents dans le même binaire (mode d’arrière-plan, affichage des prix, bouton de suppression). Le troisième a épinglé un actif marketing. Le quatrième a posé une question de navigation.

Ce n’est pas un bug. C’est une propriété de la façon dont App Review est structuré. Les revues semblent se faire par problème, pas par app. Les relecteurs s’arrêtent au premier problème majeur qu’ils attrapent dans leur budget de temps. Ils ne sont pas tenus de faire un audit exhaustif, et le système n’accorde pas de statut « déjà validé » aux surfaces qu’un relecteur précédent a acceptées. La structure privilégie le débit institutionnel sur l’expérience du développeur.

Ce que cela implique : tu ne peux pas obtenir d’audit complet d’une seule passe de revue. Tu n’obtiens que ce que le relecteur du moment fait remonter dans sa fenêtre de temps, et tu dois accepter que le suivant puisse faire remonter indépendamment n’importe quoi d’autre à la passe suivante.

# Chaque refus a tendance à être de moindre portée que le précédent

Un motif souple, pas une garantie. Le premier refus est souvent de fond (une exigence manquante, un problème d’architecture). Le deuxième est encore de fond mais prend davantage la forme d’une liste à cocher. Le troisième dérive vers des métadonnées périphériques. Le quatrième est parfois une question de procédure plutôt qu’un refus.

La raison n’est pas que l’app « s’améliore » à chaque passe. La raison est que la surface examinable dans le binaire et les métadonnées rétrécit à chaque passe, à mesure que les points déjà épinglés sont corrigés et que les points déjà validés sortent du champ. Les relecteurs épuisent indépendamment la surface de la liste à cocher disponible, ce qui fait que les revues tardives ont moins à trouver.

Ce motif est rassurant quand tu es dans le cycle, mais ne mise pas dessus. Un relecteur de fin de cycle peut encore faire remonter un point de fond que les précédents ont manqué.

# La rigueur des relecteurs varie énormément

Sur quatre revues du même binaire, la variance de ce que chaque relecteur a trouvé était considérable. L’un en a trouvé trois. Un autre un seul point périphérique. Un troisième a posé une question à laquelle on répondait en touchant une carte dans le deuxième onglet de l’app.

Tu n’as aucune influence sur le relecteur qui recevra ta soumission à une passe donnée. Prévois la variance. Ne pars pas du principe que la passe suivante sera plus rigoureuse ou plus clémente que la précédente. Ce sont des tirages indépendants dans une distribution large.

# Une validation en Beta App Review ne prédit pas une validation en App Review complète

Les deux chaînes ont des équipes et des critères différents. Une version qui passe la Beta avec les mêmes fonctionnalités que celles épinglées en revue de production n’est pas une contradiction. Ce sont deux processus de revue distincts.

Si tu utilises TestFlight pour confirmer que tu es prêt pour la revue de production, tu l’utilises pour le mauvais signal. TestFlight attrape les problèmes de validité de la version et de conformité de base. L’App Review de production attrape toute la surface d’application des règles. Les deux ne sont pas interchangeables.

# Les vecteurs de contrôle des catégories sensibles s’additionnent

Les abonnements, surtout avec un prix d’introduction ou une offre d’essai, déclenchent automatiquement l’application de la règle 3.1.2. Les catégories proches de la santé (alcool, forme physique, santé mentale, sommeil) attirent l’attention du relecteur sur les préoccupations de la règle 1.4.1 relatives aux allégations médicales. Les fonctionnalités sensibles pour la vie privée (localisation, HealthKit, identifiants anonymes) déclenchent l’examen au titre de la règle 5.1.1. Les soumissions de première version v1.0 déclenchent des revues complètes. Les événements in-app liés à une date de lancement déclenchent un examen des métadonnées.

Chaque vecteur pris isolément est gérable. Ils s’additionnent de façon multiplicative. Un lancement sérieux dans une catégorie sensible, avec des abonnements, plusieurs plateformes et un événement in-app, a tous les vecteurs actifs en même temps. Un utilitaire gratuit à écran unique sans achat intégré passe en deux minutes. La difficulté de ton expérience de revue est corrélée au sérieux et à l’ampleur de ton lancement, pas à la qualité de ton app.

# La documentation et son application ne coïncident pas toujours parfaitement

Un refus peut citer une consigne qui n’apparaît pas explicitement sur la page publique liée. Les relecteurs travaillent à partir d’un matériel de formation interne qui recoupe les Review Guidelines publiques sans y être identique. Si tu tombes sur un refus qui ne correspond pas à la documentation publique, tu peux contester poliment. Parfois ça se retourne, parfois non.

Quand tu contestes, fais-le par écrit dans le Resolution Center, dans un paragraphe structuré qui cite la consigne publique et demande quelle clause précise est appliquée. Évite la frustration dans le ton. Le relecteur lit ta réponse avec un budget de temps ; celle qui sera lue attentivement est celle qui respecte ce budget.

# Comment répondre aux refus de façon constructive

Quelques notes pratiques sur les allers-retours dans le Resolution Center.

# Réponds le jour même si tu peux

Le moyen le plus rapide de sortir du cycle est de faire avancer le cycle. Le chronomètre de chaque refus repart quand tu réponds. Des réponses le jour même produisent une résolution dans la semaine ; des réponses en plusieurs jours étirent le cycle d’autant.

Cela suppose que ton équipe soit organisée pour livrer des correctifs vite. Pour un développeur indépendant, cela veut souvent dire vider son agenda pour les jours qui suivent la soumission. La fenêtre de soumission ne peut pas être traitée comme une tâche de fond.

# Regroupe tes correctifs en une seule resoumission

Si un refus épingle trois points, corrige les trois avant de resoumettre. N’envoie pas une réponse « deux sur trois corrigés, le troisième est en cours ». Le relecteur suivant fera remonter des points entièrement différents ; la réponse partielle ne fait qu’ajouter un cycle à la file.

# Joins des enregistrements d’écran qui vérifient les correctifs

Pour tout correctif non trivial, joins un enregistrement d’écran de 30 secondes qui montre le correctif en action. Le parcours de suppression, l’affichage des prix corrigé, le nouveau chemin de navigation. Le relecteur a plus de chances de clore le point à la passe suivante s’il peut voir le correctif sans avoir à y naviguer lui-même.

# Demande une revue complète dans ta réponse

Une demande polie pour que les éventuelles réserves restantes soient soulevées ensemble dans la passe en cours, plutôt qu’étalées sur des cycles supplémentaires, est raisonnable. Cela ne marche pas toujours, mais parfois oui. La formulation compte : « Nous avons traité chaque point soulevé jusqu’ici rapidement et de bonne foi. Nous apprécierions une revue complète au regard de toutes les règles applicables dans cette passe, afin de limiter les cycles supplémentaires. »

Cela place le relecteur dans une position où sa réponse suivante, soit valide l’app, soit fait remonter toutes les réserves restantes. Les deux issues valent mieux qu’un nouveau refus sur un point unique.

# Traite chaque passe comme indépendante

La tentation est de supposer que le relecteur suivant a lu les notes du précédent. Il ne les a probablement pas lues. Chaque réponse dans le Resolution Center doit se suffire à elle-même et résumer l’état de la soumission pour quelqu’un qui n’a pas vu la conversation précédente.

Cela implique qu’un peu de répétition d’un cycle à l’autre est nécessaire. Les notes d’App Review détaillées qui ont fonctionné pour le premier relecteur doivent être rejointes ou reformulées pour le troisième. Ne compte pas sur une mémoire institutionnelle.

# La chronologie personnelle

Pour le contexte, voici à quoi ont ressemblé ces cinq jours.

J’ai soumis la version 22 un samedi après-midi. La soumission comprenait 4 abonnements à renouvellement automatique, 2 achats Lifetime non consommables, 5 articles consommables du Tip Jar, la description de l’app, les captures d’écran, les vidéos App Preview, un événement in-app lié à la semaine de lancement, et la précommande configurée pour la date de lancement dans 175 pays.

J’avais passé les six semaines précédentes à éliminer méthodiquement tout ce que je pouvais anticiper. Les notes d’App Review étaient rédigées avec des explications pensées pour le relecteur sur les parties de l’app les plus susceptibles d’attirer l’examen. Les informations de professionnel DSA étaient validées une semaine plus tôt. Les étiquettes de confidentialité App Privacy étaient en ligne. La Beta App Review avait validé plusieurs versions. Je me sentais prêt.

Jour 2, 5h15 : premier refus. Règle 3.1.2©. Lien fonctionnel vers les conditions d’utilisation manquant dans les métadonnées App Store. Correctif livré le jour même (ajout du lien Conditions dans la fiche de mise à niveau de l’app, page de conditions étendue pour indiquer tous les produits payants, description de l’app mise à jour). Cycle d’une journée.

Jour 4, 16h03 : deuxième refus. Trois points dans un seul message. Règle 2.5.4 (entrée UIBackgroundModes « location » vestigiale qui n’aurait pas dû être là). Règle 3.1.2© (prix d’introduction affiché plus en évidence que le montant facturé). Règle 5.1.1(v) (la désactivation de l’identifiant anonyme avait besoin d’un bouton de suppression explicite et étiqueté). Correctif livré le jour même (entrée d’Info.plist retirée, hiérarchie des prix inversée, ajout d’un bouton explicite « Supprimer les données anonymes » avec alerte de confirmation). Cycle d’une journée.

Jour 5, 17h05 : troisième refus. Règle 2.3.4 Accurate Metadata. Les vidéos App Preview mettaient en scène des maquettes de téléphone en 3D montrant les écrans de l’app. La note du relecteur invoquait un contenu qui ne « montre pas suffisamment l’app en usage » et pointait spécifiquement les cadres d’appareil.

La difficulté : la page d’orientation publique sur developer.apple.com/app-store/app-previews/ n’interdit pas explicitement les cadres d’appareil. La règle documentée la plus proche est « Reste dans l’app », avec des exemples sur les plans par-dessus l’épaule et l’interaction physique avec les appareils. Ni l’une ni l’autre ne s’appliquait.

Le lancement étant à quatre jours et le retard cumulé déjà de quatre jours, j’ai fait l’arbitrage. J’ai retiré les vidéos App Preview pour débloquer la resoumission. J’ai demandé poliment un réexamen s’il existait une clause précise que j’avais manquée. J’ai envoyé un paragraphe poli et structuré demandant que toutes les réserves restantes soient soulevées ensemble dans cette passe. Le retrait des App Preview a tenu. La demande de réexamen n’a reçu aucune réponse directe.

Jour 6, 19h23 : quatrième message. Règle 2.1(b) Information Needed. Techniquement pas un refus. Une mise en pause de la revue pour poser une question. Le relecteur ne parvenait pas à localiser deux des achats intégrés rattachés à la version et demandait où les trouver.

La capture d’écran qu’il a jointe montrait correctement le premier écran de vente. Le second était sur le même écran Réglages, accessible en touchant une carte juste sous celle où le relecteur avait navigué avec succès. J’ai répondu avec une navigation pas à pas explicite pour les 11 achats intégrés, envoyée dans l’heure.

Jour 7, 20h30 : validation. Version validée. Précommande activée. La semaine de lancement est calée au 11 mai.

Ces cinq jours ont été intenses. Aucun n’était existentiel, avec le recul, même si ce n’était pas l’impression du moment. Le retard cumulé a failli coûter la date de lancement, mais ne l’a pas coûtée. Le produit finalement lancé est exactement celui qui avait été construit avant la soumission. Rien n’a été coupé, modifié ou reporté pour passer la revue.

# Ce que le cycle n’épingle pas est instructif

Sur quatre revues, les surfaces qui m’avaient le plus inquiété n’ont jamais été épinglées.

Le score d’habitude (un score de 0 à 100 avec ce qui aide et ce qui nuit, réparti sur six piliers pondérés). La surface de suivi des médicaments (enregistrement seul, sans aucune recommandation en sortie). Le modèle de confidentialité (pas de compte, données sur l’appareil, partage anonyme optionnel avec suppression explicite). Les écritures HealthKit. Aucune de ces surfaces, pourtant les plus susceptibles de déclencher une inquiétude sur les allégations de santé ou la vie privée, n’a été épinglée dans l’une des quatre revues. Quatre relecteurs indépendants ont tous regardé, et tous choisi de ne pas les épingler.

Ce que cela implique pour ceux qui construisent en catégorie sensible : le travail de divulgation proactive compte. Les notes d’App Review qui expliquent la méthode, les avertissements dans l’app, les choix de nommage prudents, le cadrage conservateur dans la description de l’app. Rien de tout cela n’est glamour. Tout cela a contribué à ce que quatre relecteurs d’affilée choisissent de ne pas épingler les surfaces les plus discutables. La classification 18+, la fiche d’avertissement au premier lancement, le texte explicite « nous ne fournissons pas de conseil médical » dans les zones concernées. Tout cela a fonctionné.

Ce qui a été épinglé à la place, c’est la surface procédurale et mécanique. La hiérarchie d’affichage des prix. Les déclarations de mode d’arrière-plan. La présence d’un lien dans les métadonnées. La composition des actifs marketing. La découvrabilité des achats intégrés. Les parties de fond de l’app ont passé toutes les passes.

# Notes finales pour les développeurs indépendants

Quelques observations qui n’entraient pas proprement plus haut.

Les apps bâclées que tu vois sur l’App Store ne bénéficient pas d’un traitement plus clément. Elles ont été validées il y a des années, quand les critères étaient plus bas, ou bien elles ne déclenchent pas les vecteurs d’examen que déclenche ton lancement sérieux. Le système récompense les apps à faible effort et faible risque par un faible examen. Ton effort et ton soin font partie des raisons pour lesquelles ta revue est plus dure. Ce n’est pas un commentaire sur la qualité de ton app.

Le système n’est pas dimensionné pour te donner l’expérience que tu voudrais. App Review est un vivier de prestataires. Les relecteurs traitent des dizaines d’apps par jour, à quelques minutes par app. Ils sont formés aux Review Guidelines comme à une liste à cocher, pas à l’expérience utilisateur particulière d’une app donnée. Le déficit d’empathie est structurel, pas personnel.

Documenter les expériences indépendantes finit par faire bouger les choses. Apple a nettement amélioré App Review au cours de la dernière décennie. Une partie de cette amélioration vient de développeurs indépendants qui ont documenté leurs expériences avec constance, et d’une pression agrégée qui s’est construite. Ton refus individuel ne fera pas reformer un relecteur en particulier. L’agrégat structuré des expériences indépendantes finit, lui, par déplacer la surface institutionnelle.

Tu publieras probablement le produit que tu as construit. Chaque fonctionnalité dont je craignais qu’elle soit coupée est sortie intacte. Le cycle de quatre refus semblait existentiel pendant qu’il se déroulait. Le résultat réel a convergé vers la validation, tant que j’ai continué à répondre clairement et gardé la marge sur la date de lancement dans ma poche arrière.

Si tu es en plein cycle en ce moment, à faire des nuits blanches dans le Resolution Center : le lancement a lieu. Continue de répondre. Le système n’a rien de personnel. Le produit est le tien.

Cet article documente le lancement d’AlcoLog, une app iOS de suivi des boissons. AlcoLog sort sur l’App Store le 11 mai 2026, après le cycle décrit ci-dessus. L’app est gratuite avec des formules Premium optionnelles et est disponible en précommande dès maintenant dans 175 pays.

Si tu es développeur iOS et que tu veux comparer tes notes sur des expériences d’App Review, la communauté iOS indépendante sur r/iOSProgramming et Indie Hackers sont de bons points de départ. Plus chacun de nous documente précisément ce qu’il a rencontré, plus l’agrégat devient utile pour le suivant.