Publier une app React Native sur l'App Store et Google Play en 2026

Read in English →

Publier une app React Native sur l'App Store et Google Play, ça semble simple jusqu'au jour où vous le faites vraiment. Deux onglets ouverts en permanence — App Store Connect et Google Play Console — vous copiez-collez les mêmes métadonnées, vous redimensionnez la même capture six fois, et vous ne savez plus si le titre que vous venez d'écrire tient dans 30 caractères ou pas.

Ce que « publier sur deux stores » veut dire concrètement

Deux boutons « Publier », ce serait pratique. En réalité il y a quatre chantiers séparés : les artefacts de build (.ipa signé pour Apple, .aab signé pour Google), les métadonnées (titre, sous-titre/description courte, description longue, mots-clés, catégorie), les captures d'écran (formats et résolutions propres à chaque store), et l'exploitation courante (avis, mises à jour de version, rollouts progressifs). Vous êtes sur Flutter plutôt ? La version Flutter de ce guide remplace les commandes Xcode et Gradle brutes ci-dessous par flutter build ipa et flutter build appbundle.

Étape 1 — Configurer le projet React Native pour les deux plateformes

iOS : provisioning et clé .p8

Il vous faut un certificat de distribution App Store valide, un provisioning profile lié à votre bundle ID, et une clé API App Store Connect (.p8) pour les uploads automatisés. Stockez ce .p8 dans un endroit sécurisé — un coffre chiffré au repos, pas juste du HTTPS en transit.

cd ios
xcodebuild -workspace YourApp.xcworkspace -scheme YourApp -configuration Release -archivePath build/YourApp.xcarchive archive
xcodebuild -exportArchive -archivePath build/YourApp.xcarchive -exportPath build/ipa -exportOptionsPlist ExportOptions.plist

Android : keystore et JSON du compte de service

Il vous faut un keystore de release et un JSON de compte de service Google Play avec le scope androidpublisher, en accès édition et publication. Build : cd android && ./gradlew bundleRelease, sortie dans android/app/build/outputs/bundle/release/app-release.aab. Gardez le keystore et le JSON hors du contrôle de version.

Étape 2 — Écrire les métadonnées une fois, publier sur les deux stores

Les deux stores n'ont ni les mêmes noms de champs, ni les mêmes limites de caractères, ni la même logique de mots-clés.

• Titre — 30 caractères, sur les deux stores.
• Sous-titre / description courte — 30 sur l'App Store, 80 sur Google Play.
• Description longue — 4000 caractères, sur les deux.
• Mots-clés — champ dédié de 100 caractères sur l'App Store ; Google Play n'a pas ce champ, c'est le texte de la description qui est indexé.

Le titre à 30 caractères reste la contrainte la plus serrée à écrire en premier — mais comme les deux stores partagent exactement cette limite, un seul titre fonctionne en général pour les deux, pas besoin de le raccourcir pour l'un et de l'étendre pour l'autre. Pour la description longue en revanche, Google Play indexe le texte pour la recherche alors que l'App Store non — la description Play doit donc intégrer vos mots-clés naturellement, celle de l'App Store sert surtout à convaincre.

Un doc partagé, ça marche pour une app. Ça casse à partir de deux. L'éditeur d'OneStore affiche les compteurs de caractères des deux stores en simultané pendant que vous tapez.

Étape 3 — Gérer les captures d'écran sans Photoshop

Apple exige au moins un des trois formats iPhone — 6,5" (1242×2688), 6,7" (1290×2796) ou 6,9" (1320×2868) — pas les trois en même temps. Le 6,7" est le format de référence actuel : Apple agrandit automatiquement une capture 6,7" pour remplir les emplacements d'aperçu 6,9", donc une app qui ne fournit que du 6,5" ou du 6,7" passe la review sans problème. L'iPad 12,9" (2048×2732) n'est requis que si l'app déclare le support iPad. Google Play a son propre jeu de formats : téléphone, tablette 7", tablette 10".

Concevez à la résolution la plus haute et laissez un outil gérer le redimensionnement — OneStore prend une image source en HD et génère tous les formats requis automatiquement.

Étape 4 — Uploader les binaires sur les deux stores

iOS via Apple Transporter

xcrun altool --upload-app --type ios --file build/ipa/YourApp.ipa --apiKey YOUR_KEY_ID --apiIssuer YOUR_ISSUER_ID

Transporter.app fait la même chose en interface graphique. Le binaire part ensuite dans la file de traitement d'App Store Connect.

Android via l'API Google Play

Authentification avec le JSON du compte de service, création d'un edit, upload du bundle, assignation à une track (internal/alpha/beta/production), commit.

Étape 5 — Gérer le rollout progressif

Apple et Google ne fonctionnent pas du tout pareil ici, et c'est une confusion fréquente.

Côté Apple, le phased release est entièrement automatique et piloté par Apple : 1 %, 2 %, 5 %, 10 %, 20 %, 50 %, puis 100 % sur 7 jours. Il ne s'active qu'à partir de la version 2 — jamais sur la soumission initiale. OneStore affiche le palier en cours sur la timeline de release et renvoie vers App Store Connect si vous voulez le mettre en pause ou l'ajuster ; OneStore ne pilote pas ce pourcentage lui-même, c'est Apple qui garde la main.

Côté Google Play, le staged rollout est réellement piloté depuis OneStore : vous fixez le pourcentage, vous le surveillez, vous le mettez en pause, vous le reprenez, vous poussez à 100 %, et vous promouvez un build d'une track à l'autre (internal → production) sans le re-uploader — tout depuis le dashboard, sans repasser par Play Console.

Étape 6 — Centraliser la gestion des avis

Les deux stores génèrent des avis indépendamment — les surveiller à la main veut dire deux consoles ouvertes en permanence. Une boîte de réception unifiée qui remonte les deux, avec des réponses IA pré-rédigées dans la langue du client, supprime l'aller-retour.

Étape 7 — Garder les fiches synchronisées après le lancement

Les fiches dérivent après le lancement — quelqu'un édite directement dans une console, et votre source de vérité devient fausse sans que vous le sachiez. La détection de drift compare la fiche live de chaque store avec ce qui est dans votre outil au moment où vous ouvrez l'éditeur, et signale les écarts avant que vous n'écrasiez une vraie modification ou que vous ne publiiez une copie périmée.

Au global

La partie build est bien documentée ; c'est la partie opérationnelle — métadonnées, captures, uploads, avis, rollout — qui bouffe le temps réel. OneStore couvre les métadonnées, les captures d'écran, l'upload des binaires, la gestion des avis et le rollout, au même endroit. Le plan gratuit couvre 3 apps, sans carte bancaire, les deux stores inclus. Les crédits IA ne servent qu'aux fonctions optionnelles (traduction, réponses aux avis) — connecter les stores, éditer les fiches et publier restent illimités et gratuits sur tous les plans.

L'Audit de fiche de store (sans compte, sans email) note une fiche existante sur 100.

FAQ

OneStore fonctionne avec les apps React Native en Expo managed ?

Oui, c'est agnostique du framework — vous buildez le .ipa/.aab normalement, vous uploadez via OneStore.

Quelle est la différence entre la limite de titre App Store et Google Play ?

Aucune : les deux plafonnent à 30 caractères. Un même titre fonctionne généralement pour les deux stores.

Je peux utiliser le rollout progressif pour le lancement initial ?

Pas sur Apple — le phased release ne s'applique qu'aux mises à jour, jamais à la soumission initiale ; la première version part à 100 % dès son approbation, et le phased release ne s'active qu'à partir de la version 2. Sur Google Play en revanche, vous pouvez démarrer le tout premier rollout de production à un pourcentage réduit dès le départ.

Qu'est-ce qui se passe si j'édite ma fiche directement dans une console après avoir connecté OneStore ?

La détection de drift signale l'écart la prochaine fois que vous ouvrez l'éditeur.

J'ai besoin d'un Mac pour builder le .ipa ?

Oui, Xcode nécessite macOS (ou un runner CI macOS) ; l'upload, lui, peut se faire depuis n'importe où une fois le fichier généré.

Mon JSON de compte de service est stocké de façon sécurisée ?

Oui : vos identifiants (clé .p8, JSON de compte de service) sont stockés dans un coffre chiffré au repos avec AES-256-GCM au niveau applicatif. Un accord de traitement des données (DPA) basé sur les clauses contractuelles types de l'UE est disponible sur demande sur onestore.so/dpa.

Quelles tracks Google Play je peux publier via OneStore ?

Internal testing, closed testing (alpha), open testing (bêta), production — avec contrôle du pourcentage de staged rollout sur chacune.