Publier une application Flutter sur l App Store et le Play Store

Ecrire l application est la moitie du travail. La mettre dans les deux stores est l autre moitie, et c est celle qui surprend. Apple et Google ont chacun leur propre signature, leurs propres metadonnees et leurs propres humeurs de revue. J ai publie sur les deux plus de fois que je ne peux compter, et la difference entre une publication fluide et une stressante est la preparation. Voici le chemin que je suis.

Reglez les bases avant de builder

Avant de generer le moindre binaire de release, reglez bien les champs ennuyeux. Un identifiant d application unique que vous ne changerez jamais, un numero de version et de build sense, le nom de l application, et les versions d OS minimales supportees. Changer l identifiant d application apres le lancement equivaut a une nouvelle application, alors decidez le avec soin. Ils vivent dans la config Gradle sur Android et le projet Xcode sur iOS.

# pubspec.yaml controle la version et le numero de build
version: 1.0.0+1
# 1.0.0 est la version vue par les utilisateurs, +1 est le numero de build

Signature Android et app bundle

Google Play veut un app bundle plutot qu un APK maintenant, et il le veut signe avec une cle d upload que vous creez une fois et gardez precieusement. Perdez cette cle et vous etes parti pour un processus de recuperation penible. Je stocke le keystore en dehors du depot et je le reference via un fichier de proprietes jamais commit. Builder le bundle de release est une seule commande une fois la signature branchee.

flutter build appbundle --release
# produit build/app/outputs/bundle/release/app-release.aab

Uploadez ce fichier vers la Play Console, remplissez la fiche du store, configurez le questionnaire de classification de contenu, et choisissez une piste de release. Je pousse toujours vers les tests internes d abord pour pouvoir installer l artefact exact que les utilisateurs auront avant qu il devienne public.

Signature iOS et archivage

La signature Apple est plus impliquee. Il vous faut un compte Apple Developer, des certificats, un identifiant d application et des profils de provisionnement. Xcode peut gerer la plupart de cela automatiquement si vous vous connectez, ce que je recommande plutot que de lutter avec les profils a la main. Vous buildez la release iOS via Flutter puis archivez et uploadez via Xcode ou l outil transporter.

flutter build ipa --release
# puis ouvrez Xcode, archivez et uploadez vers App Store Connect

• Enregistrez l identifiant d application dans le portail developpeur
• Laissez Xcode gerer les certificats et profils quand c est possible
• Uploadez vers TestFlight avant de soumettre pour revue
• Preparez des captures d ecran pour chaque taille d appareil requise

Les fiches de store prennent plus de temps qu on ne le croit

Les deux stores ont besoin de captures d ecran a des tailles precises, d une icone, d une description, de mots cles, d une URL de politique de confidentialite et d une declaration de collecte de donnees. Apple est stricte sur le questionnaire de confidentialite et rejettera les reponses vagues. Reservez du vrai temps pour cela, car une fiche a moitie faite bloque toute la publication. Je garde une checklist pour que rien ne soit oublie a la derniere minute.

Survivre a la revue

La revue Apple peut rejeter pour des raisons qui paraissent arbitraires jusqu a ce que vous lisiez les directives de pres. Les plus courantes sont l absence d identifiants de compte de demonstration, des liens casses, des plantages sur leur appareil de test, et un usage flou des permissions. Donnez leur un identifiant fonctionnel si votre application en a besoin, testez sur un vrai appareil, et expliquez pourquoi vous demandez chaque permission. La revue Google est generalement plus rapide et plus automatisee mais se soucie toujours des permissions et du respect des politiques.

Planifiez aussi les mises a jour

Livrer la version un est le debut. Incrementez le numero de build a chaque upload, gardez un changelog, et utilisez les deploiements progressifs sur Android pour qu une mauvaise release atteigne d abord une petite tranche d utilisateurs. Les habitudes de performance de l optimisation des performances Flutter comptent ici car les metriques de plantage et de saccade affectent votre classement dans le store. Et si votre application s appuie sur des fonctionnalites natives, testez les avec soin sur les versions d OS comme je le decris dans les canaux de plateforme Flutter. Une publication calme est une publication preparee. Faites le travail ennuyeux tot et le jour du lancement cesse d etre effrayant.