Publier une app sur l'App Store tient en quatre éléments : un compte Apple Developer à 99 $ par an, un build signé envoyé sur App Store Connect, une fiche complète, et une review qui rend sa décision en moins de 48 heures dans 98 % des cas. Aucun de ces éléments n'est difficile isolément. Ce qui coûte du temps, c'est de les découvrir dans le désordre.
Le vrai risque n'est plus technique : la signature de build, cauchemar historique d'iOS, est aujourd'hui automatisée par les services de build cloud. Le risque, ce sont les refus évitables : un compte de démonstration oublié, un questionnaire de confidentialité bâclé, un paiement qui contourne l'achat intégré. Ce guide suit l'ordre réel des opérations et s'arrête sur chaque point qui fait échouer une première soumission.
Il couvre uniquement iOS. Pour Android, le parcours est différent et fait l'objet d'un guide dédié : publier une app sur Google Play. Pour comparer les deux stores avant de vous lancer, notre checklist App Store et Google Play met les deux parcours côte à côte.
Ce qu'il faut préparer avant de commencer
Tout ce qui suit peut se préparer en parallèle du développement. Le jour de la soumission, il vous faut :
- Un compte Apple Developer actif. 99 $ par an, en tant que particulier ou en tant que société. Le compte société exige un numéro DUNS et permet de publier sous le nom de l'entreprise.
- Une app testée sur un vrai appareil. Le simulateur ne montre ni les performances réelles ni les permissions système.
- Une icône 1024 × 1024 en PNG, sans transparence et sans coins arrondis : Apple les applique lui-même.
- Une politique de confidentialité en ligne. Son URL est obligatoire dans la fiche, même pour une app qui ne collecte presque rien.
- Un compte de démonstration si votre app demande une connexion : identifiant et mot de passe valides, transmis dans les informations de review.
Les six étapes, du build à la mise en ligne
Voici le parcours complet, dans l'ordre où il se passe réellement. Les délais indiqués supposent un dossier complet du premier coup.
- Inscrivez-vous à l'Apple Developer Program. L'inscription se fait sur developer.apple.com avec votre identifiant Apple et une vérification d'identité. C'est ce compte qui ouvre l'accès à App Store Connect, la console où vivent vos apps.
- Générez un build signé. Un binaire iOS doit être signé par un certificat de distribution et un profil de provisionnement liés à votre compte. Un service de build cloud comme EAS crée les deux automatiquement et compile sur des machines macOS distantes ; avec Xcode, vous le faites localement sur Mac.
- Créez la fiche sur App Store Connect. Nom affiché, identifiant de bundle (définitif, choisissez-le bien) et catégorie. La fiche peut rester en brouillon pendant que vous testez.
- Testez avec TestFlight. C'est le binaire exact que recevront vos utilisateurs, pas une preview. Les testeurs internes y accèdent immédiatement ; les testeurs externes après une courte beta review.
- Complétez la fiche. Description, mots-clés, captures d'écran iPhone (et iPad si votre app le supporte), questionnaire « App Privacy », classification d'âge, et les informations de review avec le compte de démonstration.
- Soumettez, puis publiez. Une fois la version approuvée, vous choisissez : publication immédiate, automatique dès l'approbation, ou progressive sur sept jours pour surveiller les premiers retours.
La review Apple : délais réels et motifs de refus
Apple annonce que 90 % des soumissions reçoivent une décision en moins de 24 heures, et 98 % en moins de 48 heures. En pratique, prévoyez un à trois jours ouvrés pour une première soumission. Les catégories réglementées (finance, santé, apps pour enfants) passent devant des reviewers spécialisés et peuvent demander des justificatifs, donc plusieurs jours de plus. La file ralentit aussi en septembre, autour de la sortie d'iOS, et avant le gel des fêtes en décembre.
Les motifs de refus sont très concentrés. Les App Review Guidelines en listent des dizaines, mais cinq familles couvrent l'essentiel des premières soumissions :
| Motif de refus | Guideline | Comment l'éviter |
|---|---|---|
| Crash ou bug au lancement | 2.1 | Tester le binaire TestFlight sur plusieurs appareils, pas seulement la preview. |
| Compte de démonstration absent ou invalide | 2.1 | Fournir un identifiant qui fonctionne, avec des données réalistes déjà en place. |
| Confidentialité : permissions injustifiées | 5.1 | Ne demander que les permissions utilisées, avec un texte d'explication clair pour chacune. |
| Paiement numérique hors achat intégré | 3.1.1 | Vendre du contenu numérique via l'achat intégré Apple ; les biens physiques peuvent utiliser un paiement externe. |
| App jugée trop minimale ou dupliquée | 4.2 / 4.3 | Apporter une vraie valeur applicative : un site reconditionné sans fonctionnalité propre est refusé. |
Un refus n'est pas une sanction : le Resolution Center indique le motif exact, vous corrigez, vous resoumettez. La deuxième review est souvent plus rapide que la première.
Publier sur l'App Store depuis Cadrant
Si votre app est un projet mobile Cadrant, la partie build et soumission est guidée de bout en bout. Deux comptes vous appartiennent et restent les vôtres : le build tourne sur votre compte Expo (le plan gratuit couvre 15 builds iOS par mois), et le binaire arrive sur votre compte App Store Connect.
- Connexion Apple sécurisée : l'authentification utilise le protocole SRP, votre mot de passe Apple n'est jamais stocké.
- Fiche créée pour vous : nom, icône 1024 × 1024 et identifiant de bundle sont posés sur App Store Connect automatiquement.
- Certificat provisionné automatiquement : le certificat de distribution et le profil sont créés sans manipulation, ou importés en .p12 si vous en avez déjà un.
- Build puis soumission : le build iOS se lance sur votre compte Expo, et Expo dépose le binaire sur votre App Store Connect. Vous reprenez la main pour TestFlight, la fiche et la soumission.
En résumé
- Ouvrez le compte Apple Developer dès aujourd'hui : c'est le seul délai incompressible du parcours.
- Testez le binaire TestFlight, pas la preview : c'est lui qui passe en review.
- Soignez les trois points qui concentrent les refus : stabilité, compte de démonstration, confidentialité.