PublicationPublier sur les stores d’applications

Projet natif

Le projet mobile complet, pour les publicités, les achats et un développeur qui s’en occupe.

Native vous donne toute l’application sous forme de projet mobile, dans un seul ZIP ou poussé vers un dépôt GitHub. Donnez-lui d’abord le nom de l’application et un identifiant d’application comme com.yourcompany.yourapp : l’identifiant est la façon dont les stores reconnaissent votre application, et il ne peut plus changer une fois l’application publiée.

La fenêtre affiche ensuite les commandes exactes pour la construire, pour Android et pour l’iPhone :

text
npm install && npm run build
npx cap add android
npm run icons
npx cap sync && npx cap open android

Sur l’iPhone, ios prend la place de android, et la dernière commande ouvre Xcode.

À partir de là, c’est le parcours propre aux stores : signez l’application dans Android Studio ou Xcode, envoyez-la, testez-la, remplissez la fiche du store et publiez. Gardez en lieu sûr la clé de signature Android et ses mots de passe. Chaque mise à jour doit être signée avec la même clé. Sans Android Studio ni Mac, GitHub peut la compiler pour vous : Compiler dans le cloud.

Obtenir le projet : téléchargement ou GitHub

À l’étape 1, Download the project comporte deux champs, App name et App ID. L’identifiant commence par com.setherion. suivi du nom de l’application, et il doit être écrit sous la forme d’un nom de domaine inversé. Download project (.zip) construit un ZIP portant le nom de l’application. Il contient le projet web, les fichiers mobiles, un schema.sql si l’application a des tables, les éventuels graphismes de jeu, ainsi que les images de l’icône et de l’écran de lancement. Il demande un forfait payant.

À la place, or push to GitHub : connectez-vous avec Connect with GitHub, ou collez un jeton, choisissez un Repo name et appuyez sur Export to GitHub. Le dépôt est créé en privé, et Open repo vous y emmène. Cela demande aussi un forfait payant.

Native sur Android, pas à pas
  1. Download the project, comme ci-dessus.
  2. Build it. Demande Node 22 et Android Studio. Lancez les commandes que la fenêtre affiche. Si l’application utilise des publicités ou des achats, npm run native:setup est ajouté après npx cap add android.
  3. Sign it. Dans Android Studio, choisissez Build, puis Generate Signed App Bundle. Créez une clé et conservez-la avec ses mots de passe : chaque mise à jour demande la même clé.
  4. Upload it and test it. Créez l’application dans Play Console, envoyez le .aab dans Internal testing, puis remplissez la fiche du store, la classification du contenu et Data safety. Avec des publicités, vous déclarez aussi l’identifiant publicitaire.
  5. Release. La validation prend de quelques heures à deux jours. Un compte Google Play personnel ouvert après novembre 2023 demande d’abord le test fermé.
Native sur iPhone, pas à pas
  1. Download the project : le même ZIP que pour Android.
  2. Build it. Demande un Mac avec Xcode et le compte développeur Apple à 99 $ par an. Lancez les mêmes commandes avec ios à la place de android.
  3. Sign it and upload it. Dans Xcode, ouvrez Signing & Capabilities et choisissez votre équipe. Avec des publicités ou des achats, ajoutez In-App Purchase. Puis Product, Archive, Distribute, vers App Store Connect.
  4. Try it on your iPhone avec TestFlight.
  5. Fill the store page and send it for review. Avec des publicités, Apple les compte comme du suivi.

Compiler dans le cloud

Ni Android Studio ni Mac : GitHub peut compiler l’application sur ses propres ordinateurs. Envoyez le projet sur GitHub à l’étape 1 et le dépôt reçoit deux workflows de compilation, un pour Android et un pour l’iPhone. L’étape Build it affiche ensuite Build it in the cloud, avec un bouton vers la page du workflow sur GitHub.

Sur GitHub, ouvrez Actions, choisissez Android build ou iPhone build, cliquez sur Run workflow et choisissez quoi compiler :

WorkflowChoixCe que vous obtenez
Android buildTest APKUne application à installer sur votre propre téléphone, dans les Artifacts de l’exécution. Rien à configurer.
Android buildMake a new keyLa clé de signature, créée une fois avant votre premier envoi sur Google Play. Seulement dans un dépôt privé.
Android buildGoogle Play bundle (.aab)Le fichier signé pour la Play Console, avec un numéro de version plus élevé à chaque exécution.
iPhone buildCheck that it buildsLa preuve que l’application se compile pour l’iPhone. Aucun compte Apple nécessaire.
iPhone buildTestFlightL’application signée et envoyée à App Store Connect, à installer avec TestFlight.

Un dépôt privé dispose de 2 000 minutes gratuites par mois sur les ordinateurs de GitHub. Une compilation Android en utilise quelques-unes, et GitHub compte une minute de Mac comme dix. Le README du dépôt explique chaque étape.

Avant le premier Google Play bundle
  1. Lancez Make a new key et téléchargez upload-key depuis l’exécution.
  2. Gardez upload.jks et son mot de passe en lieu sûr, hors du dépôt. Chaque mise à jour doit être signée avec la même clé.
  3. Dans le dépôt, ouvrez Settings, Secrets and variables, Actions et ajoutez trois secrets, chacun avec le texte de son fichier : ANDROID_KEYSTORE_BASE64, ANDROID_KEYSTORE_PASSWORD et ANDROID_KEY_ALIAS.
  4. Lancez Google Play bundle (.aab) et envoyez le fichier dans Internal testing, dans la Play Console.
Avant la première compilation TestFlight
  1. Dans App Store Connect, créez l’application avec le même identifiant qu’à l’étape 1.
  2. Dans Users and Access, Integrations, App Store Connect API, générez une clé avec le rôle Admin et téléchargez son fichier .p8. Apple ne vous laisse le télécharger qu’une seule fois.
  3. Dans le dépôt, ajoutez quatre secrets : APPLE_TEAM_ID (Membership details sur developer.apple.com), ASC_KEY_ID, ASC_ISSUER_ID et ASC_KEY_P8, le texte du fichier .p8.
  4. Lancez TestFlight. Quelques minutes plus tard, la compilation se trouve dans App Store Connect, sous TestFlight. Le workflow indique à Apple que l’application n’utilise qu’un chiffrement standard, donc TestFlight ne pose pas la question.

Une connexion GitHub faite avant la compilation dans le cloud ne peut pas ajouter les workflows : l’étape le signale, et Reconnect à l’étape 1 règle le problème.

Les comptes dans l’application mobile

Dans l’application mobile, les gens se connectent avec un e-mail et un mot de passe. Le bouton Google et le lien de connexion envoyé par e-mail s’y masquent d’eux-mêmes. C’est pourquoi la vérification Delete account button compte : Apple refuse une application où l’on peut créer un compte sans ce bouton.

Publicités et achats

Un jeu qui affiche des publicités ou qui vend quelque chose ne fonctionne pour de vrai que dans le projet Native : publicités de Google AdMob, achats via les stores avec RevenueCat. Dans l’aperçu de l’éditeur, ils sont simulés (« Test ad », « Test purchase », aucun argent n’est prélevé), vous pouvez donc les essayer, et sur le site web publié ils sont masqués. Avec la voie facile, le jeu fonctionne sans eux.

Le projet démarre avec les publicités de test de Google, qui ne rapportent rien. Mettez vos propres identifiants de publicité et vos clés de store dans src/monetize.keys.json, puis lancez npm run native:setup : le README du projet indique d’où vient chacun.

Ce que contient le fichier de clés

Le fichier contient l’identifiant d’application AdMob et les identifiants des blocs d’annonces avec récompense et interstitielles pour Android et l’iPhone, ainsi que les clés RevenueCat de chaque store (commençant par goog_ pour Android et appl_ pour l’iPhone). Sans clés RevenueCat, ou sans produits, rien ne se vend.

Pour de vraies publicités, créez le compte AdMob, les applications et les blocs d’annonces, mettez les identifiants dans le fichier, lancez npm run native:setup sur des dossiers natifs tout neufs, et publiez un fichier app-ads.txt sur le site web. Pour les achats, créez les produits dans Play Console et App Store Connect avec les mêmes identifiants que dans src/monetize.json, et reliez les deux stores dans un projet RevenueCat. Sur l’iPhone, ajoutez la capacité In-App Purchase.

Les deux stores veulent un lien vers une politique de confidentialité, et un bouton Restore purchases est obligatoire : le projet en fournit un. Entre deux publicités, l’application saute une publicité interstitielle dans les 30 premières secondes, dans les 60 secondes qui suivent la dernière, et pour un joueur qui a acheté le produit de suppression des publicités.

Cette page vous a-t-elle été utile ?

Rejoindre la communauté

Questions, idées et ce que construisent les autres.