Publication sur l'App Store : toutes vos questions à notre AMA Reddit

Les captures d'écran ont deux rôles à la fois : convaincre quelqu'un de télécharger votre application, et aider Apple à comprendre ce qu'elle fait pendant la revue. Mettez en avant vos fonctionnalités principales et la valeur qu'elles apportent plutôt que de montrer des écrans au hasard — si votre application a quelque chose de différenciant, un workflow unique, une fonctionnalité communautaire, un cas d'usage particulier, assurez-vous qu'il soit visible.

Un détail qui piège plus de monde qu'on ne le pense : vos captures d'écran doivent correspondre à la version de l'application que vous soumettez réellement. Il est étonnamment fréquent de refondre une partie de l'application, de soumettre un nouveau build, et d'oublier de mettre à jour les captures d'écran de l'App Store — un décalage important entre ce qui est montré et ce qui est réellement revu peut soulever des questions pendant l'App Review. Apple propose aussi des gabarits produits officiels pour présenter vos captures d'écran de façon propre et cohérente, à utiliser si ce n'est pas déjà fait. Une dernière chose signalée par nos ingénieurs iOS : des captures d'écran montrant le produit ou le service d'un concurrent ont déjà posé problème en revue, mieux vaut donc les éviter complètement.

Vous n'avez besoin d'un numéro D-U-N-S que si vous voulez vous inscrire au Apple Developer Program en tant qu'Organisation. Si vous publiez en tant qu'individu, vous n'en avez pas besoin du tout.

Pour obtenir un compte Organisation, vous devez d'abord enregistrer votre structure auprès de Dun & Bradstreet (ou d'un partenaire local) — l'obtention du numéro D-U-N-S prend généralement autour de deux semaines, et Apple peut demander des informations complémentaires pendant l'inscription. En contrepartie, un compte Organisation apporte de vrais avantages : votre organisation apparaît comme développeur sur l'App Store plutôt que votre nom personnel, c'est généralement plus adapté aux entreprises et aux équipes (notamment si la propriété change au fil du temps), cela facilite la démonstration de la propriété de votre marque et de votre contenu pendant la revue, et dans certains pays, cela peut vous rendre éligible à une exonération des frais du Apple Developer Program. Si vous êtes un développeur indépendant qui publie ses propres applications, en revanche, un compte Individuel est parfaitement valable et vous dispense entièrement du numéro D-U-N-S.

Une source de confusion récurrente : les erreurs cryptiques de Transporter au moment d'envoyer un build. Voici les trois plus courantes, décryptées :

• « No suitable application records were found » → la fiche de l'application n'existe probablement pas encore dans App Store Connect.
• « Potential loss of keychain » → généralement un simple avertissement, déclenché quand l'application a été transférée entre comptes développeur Apple.
• « Redundant binary upload » → vous êtes probablement en train d'envoyer un build avec le même numéro de version ou de build qu'un build déjà présent.

C'est l'une des questions qu'on nous pose le plus souvent. D'après ce qu'on observe en accompagnant nos clients dans la publication, la plupart des revues sont bouclées en 24 à 48 heures, même si cela peut prendre plus de temps selon l'application et la charge de travail d'Apple.

Si vous avez une échéance — un événement de lancement, une date de sortie — soumettez le plus tôt possible plutôt que d'attendre la dernière minute. Ainsi, si Apple demande des modifications avant d'approuver, vous aurez encore le temps de les traiter. Et si votre calendrier devient vraiment serré, Apple propose une demande de revue accélérée pour les situations urgentes. Ce n'est pas garanti, mais cela vaut la peine d'essayer dès que vous avez une date fixe à respecter.

Le bon moment pour quitter la bêta n'est pas quand votre application est parfaite — c'est quand elle est prête pour de vrais utilisateurs. En pratique : l'expérience principale est solide, l'application contient déjà du contenu pertinent, et vos utilisateurs bêta reviennent parce qu'elle résout réellement un problème pour eux.

Le deuxième point compte tout autant : ne publiez pas sans plan de lancement. Une erreur fréquente consiste à concentrer toute son énergie sur l'obtention de l'approbation, pour se rendre compte ensuite que personne ne sait que l'application existe. Une cible claire et une réponse claire à la question « pourquoi quelqu'un choisirait cette application plutôt qu'une autre » a un impact bien plus important sur la traction que de sortir quelques jours plus tôt. Cette réponse ne sert pas seulement au marketing, d'ailleurs : elle tend aussi à correspondre à ce qu'Apple recherche pendant l'App Review. Les applications qui apportent quelque chose de réellement utile ou distinctif ont généralement un parcours plus fluide que celles qui ressemblent à une énième variante de quelque chose qui existe déjà.

Les deux plateformes peuvent être délicates, mais chacune à sa manière. D'après ce que nous observons, les premières soumissions sont plus souvent rejetées du côté d'Apple que de Google Play — mais cela ne veut pas dire que Google Play est plus simple. Il a ses propres contraintes, qui peuvent créer tout autant de friction selon le type de compte développeur et la configuration de l'application. Pour les mises à jour, le taux de rejet est généralement bien plus proche entre les deux.

Un utilisateur GoodBarber de longue date a bien résumé ce compromis dans le fil de discussion : publier sur Apple est tout un processus, et il y a toujours une raison pour laquelle une application se fait signaler — mais disposer de la documentation et du support de GoodBarber pour s'y retrouver enlève l'essentiel du stress, et garantit que l'application reste conforme aux règles des stores dans la durée. Il a aussi souligné que Google Play, autrefois la plateforme la plus simple, est également devenu plus strict : les applications doivent désormais être mises à jour régulièrement, sous peine de voir le compte développeur signalé. Un support fiable sur les deux fronts, selon lui, n'a pas de prix.

Il y a vraiment beaucoup à dire sur Google Play en particulier — assez pour qu'on prévoie un AMA dédié à ce sujet plutôt que de tout mélanger ici.

Tout ce qui précède, c'est exactement ce que notre équipe support gère au quotidien — c'est d'ailleurs pour ça que ce service existe en tant qu'offre dédiée : GoodBarber Takes Care (GBTC). Plutôt que de gérer l'App Review vous-même, l'équipe GBTC soumet l'application à l'App Store et à Google Play pour vous, de bout en bout. Apple rejette en moyenne environ 42 % des premières soumissions — souvent pour des raisons difficiles à anticiper — mais sur les 12 derniers mois, l'équipe GBTC a obtenu l'acceptation finale de 91 % de ces premières soumissions rejetées. Sur les mises à jour, un travail de prévention en amont fait descendre le taux de rejet à seulement 5 %. Si vous préférez laisser l'App Review à une équipe qui vit dedans au quotidien, c'est exactement à ça que sert GBTC.

Voilà pour le récapitulatif, mais le fil de discussion original mérite toujours d'être lu pour le détail complet de chaque réponse — et il reste ouvert, donc si vous avez une question qu'on n'a pas couverte, vous pouvez toujours la poster là-bas : AMA sur la publication App Store, sur r/GoodBarber.

C'était notre deuxième AMA en direct. Dites-nous en commentaire quel sujet vous aimeriez qu'on aborde la prochaine fois.