Comment une petite équipe publie une app iOS

Le scénario d'échec est toujours le même. Une petite équipe construit quelque chose de bon, estime que c'est presque terminé, puis découvre que la distance entre une application qui fonctionne et une application sur l'App Store se mesure en jours de formalités, pas en heures de code. Voici de quoi cette distance est faite.

Le store est le chemin critique

Avant de soumettre, il vous faut tout ce qui suit, et rien de tout cela ne se génère depuis le code : un nom et un sous-titre encore disponibles, une description, un champ de mots-clés, une URL d'assistance accessible en HTTPS, une politique de confidentialité à une adresse publique, un questionnaire de classification d'âge, une déclaration de conformité à l'export, et un jeu complet de captures d'écran.

Les captures sont l'élément le plus souvent sous-estimé. Apple les exige à des tailles d'écran précises, et la liste change à chaque nouvelle génération d'appareils — vérifiez l'exigence en vigueur dans App Store Connect plutôt que de vous fier à un article vieux de deux ans. Si votre application est localisée, il faut un jeu par langue, donc capturer les mêmes parcours deux fois.

Prévoyez une journée entière pour cela, deux fois : une pour tout produire, une pour refaire la moitié que vous aurez ratée.

Ce que la revue rejette réellement

La plupart des premiers rejets se concentrent sur une poignée de règles, toutes évitables si on les connaît avant de développer :

• Règle 2.1, App Completeness — de loin la plus fréquente. Plantages sur l'appareil du relecteur, contenu de remplissage, liens morts, ou un écran de connexion sans compte de démonstration fourni dans les notes de revue.
• Règle 4.2, Minimum Functionality — l'application en fait trop peu, ou n'est qu'une enveloppe autour d'un site web. Une première version étroite est acceptable ; une page web réempaquetée ne l'est pas.
• Règle 3.1.1, In-App Purchase — les contenus numériques et les abonnements doivent passer par le système d'achat intégré d'Apple. Renvoyer vers une page de paiement externe pour du numérique sera rejeté.
• Règle 5.1.1, Data Collection and Storage — la politique de confidentialité doit exister et correspondre à la réalité, les demandes d'autorisation doivent expliquer leur raison d'être, et si l'utilisateur peut créer un compte dans l'application, il doit pouvoir l'y supprimer.
• Règle 2.3, Accurate Metadata — les captures doivent montrer l'application réelle, et la description ne doit pas promettre des fonctions absentes.

Le point du compte de démonstration mérite d'être souligné, car c'est un retard entièrement auto-infligé. Si une partie de votre application se trouve derrière une connexion, mettez des identifiants fonctionnels dans le champ des notes pour la revue. Les relecteurs ne créent pas de compte.

Le questionnaire de confidentialité est un document de conception

App Store Connect vous demande de déclarer, pour chaque type de donnée, si vous la collectez, si elle est liée à l'identité de l'utilisateur, et si elle sert au suivi publicitaire. Cela devient l'étiquette de confidentialité affichée sur votre fiche.

Y répondre honnêtement est plus difficile qu'il n'y paraît, car cela oblige à savoir exactement ce que chaque SDK de votre projet envoie. Les bibliothèques d'analytique, en particulier, collectent souvent plus que les équipes ne le supposent. Le bon réflexe consiste à remplir le questionnaire tôt — pendant le développement, pas à la soumission — car les réponses changent fréquemment ce qu'on accepte de publier.

TestFlight avant de vous croire prêts

Une version qui tourne sur votre appareil via Xcode n'est pas celle que recevront les utilisateurs. Les builds de distribution sont compilés différemment, et un nombre surprenant de bugs n'apparaît que là : ressources manquantes, textes d'autorisation oubliés à la traduction, code qui fonctionnait grâce à une condition de débogage.

Publiez une version TestFlight tôt et souvent, bien avant le lancement. Installez-la sur un appareil sur lequel vous ne développez pas, idéalement celui de quelqu'un qui n'a jamais vu l'application. Les trente premières secondes d'un inconnu dans votre parcours d'accueil vous apprendront plus qu'une semaine d'auto-tests.

Discipline de périmètre : une boucle qui fonctionne

La version publiée devrait faire une chose complètement plutôt que cinq choses à moitié. Non par culte du minimalisme, mais parce que la revue, le support, les captures et votre propre explication de l'application se compliquent à chaque surface ajoutée.

Le test pratique : pouvez-vous décrire ce que fait l'application en une phrase, sans employer « et » ? Sinon, quelque chose dedans attend la version deux.

Un enchaînement réaliste

1. 01Semaine un : réservez le nom de l'application dans App Store Connect. Les noms sont attribués au premier arrivé, et découvrir que le vôtre est pris au moment de soumettre gâche la journée.
2. 02Pendant le développement : publiez la politique de confidentialité et la page d'assistance à de vraies URL. Elles sont obligatoires et faciles à oublier.
3. 03Deux semaines avant le lancement : remplissez le questionnaire de confidentialité. Corrigez ce qu'il révèle.
4. 04Dix jours avant : première version TestFlight envoyée hors de l'équipe.
5. 05Une semaine avant : produisez les captures pour chaque taille exigée et chaque langue. Puis reproduisez-les.
6. 06Soumettez. La plupart des revues aboutissent en un ou deux jours, mais une première soumission depuis un compte développeur récent peut prendre plus longtemps, et un rejet remet le compteur à zéro.

Le lancement n'est pas la fin

Chaque mise à jour repasse en revue : le coût d'un correctif n'est donc jamais nul. Cela plaide pour un premier cycle un peu plus long et un second un peu plus court : poser correctement les fondations, puis itérer sur une chaîne qui fonctionne. Les studios qui publient régulièrement sont ceux qui ont traité la première soumission comme un processus à construire, non comme un obstacle à franchir.