1. Réunir les prérequis avant le premier build

La publication nécessite un compte Apple Developer actif, une application créée dans App Store Connect et un identifiant de bundle unique, par exemple com.entreprise.produit. Cet identifiant relie la configuration du projet, la signature et la fiche App Store : le changer tardivement crée une nouvelle identité plutôt qu’une simple correction cosmétique.

Définis également le nom public, la catégorie, l’âge minimum, l’URL de support et la politique de confidentialité. Même si toutes les captures ne sont pas prêtes, ces informations révèlent tôt les dépendances administratives et juridiques.

2. Produire un vrai build de production

Avec React Native en local, Xcode fournit l’environnement nécessaire pour compiler iOS, gérer la signature et créer une archive. Avec Expo, EAS Build peut produire le fichier IPA signé dans le cloud à partir d’un profil production défini dans eas.json.

Avant ce build, contrôle le numéro de version visible, le build number, les icônes, les permissions et les variables d’environnement. Une configuration de développement ne doit jamais se retrouver par accident dans le binaire destiné aux testeurs ou à Apple.

  • Utiliser un profil explicitement nommé production.
  • Ne placer aucun secret dans une variable publique ou dans le bundle JavaScript.
  • Conserver une trace du commit et de la configuration associés au build.

3. Envoyer le binaire vers App Store Connect

Une archive Xcode peut être envoyée depuis Organizer. EAS Submit peut également uploader un IPA existant ou le dernier build EAS avec la commande eas submit --platform ios. Expo précise que cet upload rend le build disponible dans App Store Connect et TestFlight après son traitement ; il ne publie pas automatiquement l’application.

Le traitement peut révéler des questions de chiffrement, une incompatibilité de signature ou une valeur manquante. Lis le message exact avant de relancer un nouveau build : certaines corrections se font dans App Store Connect, d’autres nécessitent réellement de reconstruire.

4. Valider la version de production avec TestFlight

Installe le build depuis TestFlight sur au moins un appareil qui n’a pas le contexte de développement. Vérifie le démarrage à froid, les autorisations, les liens, les achats éventuels, les erreurs réseau et le chemin de support.

Commence par un petit groupe interne. Ajoute ensuite quelques testeurs externes lorsque le parcours est stable. Leur première incompréhension est souvent plus utile qu’une nouvelle passe de finition visuelle réalisée seul.

5. Préparer une fiche App Store cohérente

Le titre, le sous-titre, la description, les captures et les informations de confidentialité doivent décrire la même application que le binaire. Évite les fonctionnalités futures, les promesses invérifiables et les visuels qui montrent un écran absent de la version envoyée.

Ouvre chaque URL publique dans une fenêtre privée et dans chaque localisation configurée. C’est précisément ce contrôle qui aurait évité le refus rencontré sur BeSafe : une URL de support ou de confidentialité ne fonctionnait pas correctement dans une ou plusieurs localisations.

6. Soumettre, répondre et conserver une trace

Sélectionne le build testé, complète les informations de review et fournis un compte de démonstration lorsque l’app exige une authentification. Les notes destinées au reviewer doivent expliquer les éléments difficiles à trouver, pas défendre le produit comme un texte marketing.

En cas de refus, réponds dans App Store Connect, reproduis le problème et corrige sa cause précise. Conserve le message, la modification et la décision finale : cette trace améliore la prochaine soumission et évite de traiter chaque review comme un événement imprévisible.