Publication
Du build de debug à un binaire signé, prêt à être soumis
Publication sur les stores
Une application qui fonctionne sur votre émulateur est à mi-chemin de la publication, pas à 95 %. La distance restante ne se mesure pas en lignes de code : elle est faite d'identifiants uniques qu'on ne peut plus changer après le premier envoi, de clés de signature dont la perte est irréversible, d'un mode release qui révèle des bugs invisibles en debug, et d'exigences de magasin qui évoluent plusieurs fois par an.
C'est une leçon d'un genre différent des précédentes. Le code y est minoritaire ; l'essentiel tient à des décisions et à des vérifications. Nous allons suivre l'ordre dans lequel elles se posent réellement : d'abord ce qui est irréversible et doit donc être décidé avant tout — identifiant de paquet, nom, clé de signature —, ensuite la production du binaire, enfin ce qui reste à préparer côté magasin.
Un avertissement d'honnêteté avant de commencer. Les procédures des deux magasins, les formats d'illustration demandés, les niveaux d'API Android minimaux, les déclarations de confidentialité et le coût des comptes développeur changent régulièrement. Ce tutoriel décrit les étapes techniques du côté Flutter, qui sont stables. Pour tout ce qui relève des règles de publication, la seule source fiable est la console du magasin concerné au moment où vous soumettez ; ne vous fiez à aucun montant ni délai lu dans un tutoriel, y compris celui-ci.
Commentaires
Les commentaires sont alimentés par GitHub Discussions
Connectez-vous avec GitHub pour participer à la discussion