Publier une app React Native sur l'App Store, seul

Foodproof est en ligne sur l’App Store depuis quelques semaines. Voici le déroulé réel qu’on suit pour chaque release, avec les pièges qui nous ont fait perdre du temps au passage. Rien d’inventé ici, c’est littéralement notre checklist.

Avant d’archiver

Trois choses à vérifier avant de toucher à Xcode :

la version dans package.json est à jour
MARKETING_VERSION et CURRENT_PROJECT_VERSION sont montés dans le projet Xcode (ils apparaissent à plusieurs endroits du .pbxproj, un grep évite d’en oublier un)
le flag de mode capture d’écran est bien désactivé

grep -n "MARKETING_VERSION\|CURRENT_PROJECT_VERSION" ios/foodproof.xcodeproj/project.pbxproj

Et on lance les tests et le linter avant de continuer. Pas parce que c’est glamour, mais parce qu’un archive qui échoue à moitié à cause d’un test cassé coûte plus cher à déboguer une fois dans Xcode que dans le terminal.

Archiver

C'est quoi une archive Xcode ? Un paquet complet et signé de ton app, prêt à être envoyé chez Apple. C'est l'étape entre "mon code compile en local" et "mon app est distribuable".

Deux détails qui paraissent anodins et qui font perdre une bonne demi-heure si on les oublie :

xcpretty (l’outil qui formate joliment les logs de build) plante sans un encodage UTF-8 explicite dans le terminal. Donc avant tout :

export LANG=en_US.UTF-8

Et Metro doit tourner avant d’ouvrir Xcode, sinon le build attend une quinzaine de secondes puis retombe sur un bundle JS périmé.

npx react-native start

Ensuite on ouvre le workspace, pas le .xcodeproj (CocoaPods s’en sert pour injecter les pods) :

open ios/foodproof.xcworkspace

Scheme foodproof, destination “Any iOS Device (arm64)”, puis Product → Archive. L’équivalent en ligne de commande, si tu veux l’automatiser dans une CI :

xcodebuild -workspace ios/foodproof.xcworkspace \
  -scheme foodproof \
  -configuration Release \
  -archivePath build/foodproof.xcarchive \
  archive | xcpretty

Uploader et TestFlight

C'est quoi TestFlight ? La plateforme de test d'Apple. Elle permet de donner une version de ton app à des testeurs avant, ou sans, passer par la mise en vente publique.

Depuis l’Organizer, Distribute App → App Store Connect → Upload, en laissant la case “Upload your app’s symbols” cochée (utile le jour où tu dois lire un crash report).

Les testeurs internes voient le build direct, sans review. Les testeurs externes déclenchent une Beta App Review, qui prend en général un jour ou deux la première fois. Une fois qu’un build est passé par TestFlight, tu n’as pas besoin de le ré-archiver pour le soumettre en production : c’est le même binaire.

Passer en prod

Une fois le build attaché dans App Store Connect, il reste à remplir le “What’s New”. Ce champ est obligatoire même en version 1.0, dès qu’une localisation française est active. Apple bloque la soumission si tu le laisses vide.

Le reste, c’est la routine : vérifier les métadonnées, les captures d’écran, le label de confidentialité, puis Submit for Review. Sur le délai de review, sois large dans ta tête : compte entre 24h et 3 jours, ça varie.

Les pièges qui coûtent le plus de temps

Les dimensions de captures d’écran. Un screenshot 1320×2868 uploadé dans le slot 6,5 pouces (qui attend du 1284×2778) fait rejeter tout le binaire, pas juste l’image.

Le nom du vendeur. Impossible à changer depuis l’interface App Store Connect, il vient de l’entité légale enregistrée chez Apple Developer. On a dû passer par le support Apple Developer pour ça, prévois quelques jours d’échange par mail.

Les mots-clés. Ne répète pas dans les keywords ce qui est déjà dans le nom ou le sous-titre de l’app : c’est un budget de 100 caractères partagé, chaque mot répété est un mot perdu.

Xcode 26. Celui-ci n’est toujours pas résolu au moment où j’écris ces lignes : Xcode 26 a introduit une étape de vérification des modules qui n’est pas compatible avec la façon dont React Native 0.73 génère ses module maps. Le build échoue à l’étape “Compile Swift / Verify module”. Le seul contournement fiable pour l’instant, c’est de rester sur Xcode 15.x pour les builds de release (et ne pas essayer de désactiver le vérificateur, ça casse d’autres choses).

Le compte de test. Si ton app demande une connexion, prévois un compte dédié pour les reviewers dans les notes de review, sinon rejet direct pour “impossible de tester la fonctionnalité principale”.

Rien de tout ça n’est sorcier une fois qu’on l’a vu une fois. Mais la première fois, chaque point de cette liste peut coûter une demi-journée.