Publier une application Flutter sur le Play Store et l'App Store : guide étape par étape

L'applicationId (Android) et le Bundle ID (iOS) constituent l'identité permanente de votre application sur chaque boutique ; aucun des deux ne peut être modifié après le premier téléversement. Finalisez les deux avant de commencer la publication — les changer plus tard signifie ouvrir une toute nouvelle fiche depuis zéro, en perdant vos avis et votre nombre d'installations existants.

Dans Flutter, le numéro de version se trouve dans le champ version: x.y.z+N de pubspec.yaml ; x.y.z est la version visible par l'utilisateur, et N est le numéro de build, qui correspond à la fois au versionCode Android et au build number iOS. Téléverser sans incrémenter N à chaque nouvelle soumission entraîne un rejet.

Les exigences d'icônes diffèrent entre les deux boutiques : Play veut une icône haute résolution de 512x512 pixels avec canal alpha (transparence), tandis que l'App Store attend un PNG de 1024x1024 pixels SANS canal alpha. Avec le package flutter_launcher_icons, vous pouvez générer les deux à partir d'une seule image source en une seule commande.

La commande flutter build appbundle --release produit le paquet prêt pour la boutique à build/app/outputs/bundle/release/app-release.aab. Le Play Store n'accepte désormais que le format .aab pour les nouveaux téléversements ; vous n'avez pas besoin de produire un .apk séparé.

Les comptes Play Console personnels (individuels) ouverts après le 13 novembre 2023 doivent effectuer un test fermé ininterrompu de 14 jours avec au moins 12 testeurs actifs avant d'obtenir l'accès à la production. Cette exigence ne s'applique pas aux comptes d'organisation ni aux comptes personnels ouverts avant cette date ; vérifiez l'exigence actuelle dans Play Console avant de postuler, car la règle change de temps à autre.

Le tout PREMIER .aab téléversé sur Play Console pour une application doit toujours être téléversé manuellement — pas de CLI ni de soumission automatisée pour celui-ci ; les versions suivantes peuvent utiliser un CLI ou votre propre intégration. Lors du passage en production, commencer par un déploiement progressif (par exemple 5-20 % d'abord, en augmentant tout en surveillant Android vitals) plutôt que de tout diffuser d'un coup réduit le risque.

La commande flutter build ipa --release produit un fichier .ipa prêt pour la publication sous build/ios/ipa/. Archiver ce build et l'envoyer à App Store Connect nécessite un Mac (physique ou dans le cloud) ; Xcode ne fonctionne pas sous Windows ou Linux. Si vous ne possédez pas de Mac, des services CI cloud comme Codemagic, les runners macOS de GitHub Actions, ou MacStadium sont des options.

Vous pouvez téléverser le .ipa résultant vers App Store Connect soit via le parcours Xcode Organizer (Window > Organizer > Archives > Distribute App), soit via l'application autonome Transporter ; les deux produisent le même résultat. La version (visible par l'utilisateur) et le numéro de build (doit être unique et croissant à chaque téléversement, non réutilisable au sein d'une même version) sont deux champs distincts.

TestFlight propose deux niveaux de test : le test interne (jusqu'à 100 personnes de votre équipe App Store Connect) ne nécessite PAS de revue Apple et est disponible dès que le build a fini d'être traité. Le test externe cible des testeurs rejoignant via e-mail ou un lien public (jusqu'à 10 000 par groupe) ; le TOUT PREMIER build ajouté à une application doit passer la « beta review » d'Apple (généralement en une journée), tandis que les builds suivants peuvent être dispensés d'une revue complète.

Sur Play, les limites de caractères sont strictes : nom de l'application jusqu'à 30, description courte jusqu'à 80, description complète jusqu'à 4000 caractères. Sur App Store Connect, le nom de l'application doit être unique dans toute la boutique, et il faut aussi remplir un sous-titre et un champ de mots-clés. Les tailles de captures d'écran (1080x1920 pour les captures téléphone Play, correspondance pixel exacte pour la classe iPhone 6,9 pouces de l'App Store) suivent des règles différentes sur chaque boutique.

Les deux boutiques exigent que vous déclariez votre comportement de collecte de données : le formulaire Data safety de Play, et les étiquettes App Privacy de l'App Store (parfois appelées « étiquette nutritionnelle »). Si vous utilisez un SDK publicitaire, de l'analytique ou du reporting de plantages, vous devez le renseigner avec précision sur les deux ; aucun des deux panneaux ne vous laisse publier sans une URL de politique de confidentialité réellement accessible et à jour.

Les deux panneaux exigent également un champ support/contact : sur Play, un e-mail de support au niveau du compte et un champ site web facultatif ; sur App Store Connect, une Support URL obligatoire et une Marketing URL facultative. Si vous n'avez pas de site web pour ces champs, nous couvrons des options pratiques dans un article séparé.

Les rejets Apple les plus fréquents sont : la règle 2.1(a) (plantages, écrans vides, liens cassés, fonctionnalités manquantes non déclarées, ou absence d'un compte de démonstration fonctionnel dans les notes de revue pour une fonctionnalité nécessitant une connexion), la règle 5.1.1 (descriptions d'utilisation des permissions vides ou vagues), et la règle 4.3 (applications modèles resoumises avec des modifications mineures). Tester de bout en bout sur un appareil vierge avant la soumission évite la plupart de ces trois cas.

Sur Play, le problème le plus fréquent est un formulaire Data safety qui ne correspond pas au comportement réel du SDK, ou une URL de politique de confidentialité vide/inaccessible ; les deux risquent un rejet ou une suspension ultérieure. Utiliser AdMob sans vérification app-ads.txt ne provoque pas de rejet direct, mais peut restreindre la diffusion publicitaire et vous coûter des revenus.

Pour les projets utilisant Expo (EAS), le flux est largement automatisé : npx eas-cli build --platform all --profile production construit pour les deux boutiques dans le cloud, et npx eas-cli submit automatise la soumission (à l'exception du premier téléversement sur Play). Les numéros de version se trouvent dans trois champs distincts d'app.json — expo.version, expo.ios.buildNumber et expo.android.versionCode — au lieu du champ unique pubspec.yaml de Flutter, et doivent être synchronisés manuellement.