Publier votre app sur l’App Store et Google Play

Ce qui est à vous et ce qui est à nous

L’app sort sous votre compte développeur, jamais sous le nôtre. Ce n’est pas un détail administratif : la fiche du store, les avis, les téléchargements et l’argent des achats sont à vous, et le restent si un jour vous quittez la plateforme.

Ce que nous faisons : nous emballons l’app publiée dans une coque native, nous générons l’icône et l’écran de démarrage, nous compilons dans le cloud (pas besoin de Mac) et nous envoyons au store avec l’identifiant que vous avez connecté. Ce qui est à vous : le compte développeur, créer l’app dans la console du store et répondre à la revue.

L’app native exécute la version publiée de votre projet. Si vous n’avez pas encore publié sur le web, l’onglet le demande d’abord, car il n’y a rien à emballer.

Avant de commencer

• le projet publié sur le web (le bouton Publier) ;
• le forfait Builder ou supérieur ;
• un compte développeur sur le store visé : Google Play (25 US$ une seule fois) et/ou l’Apple Developer Program (99 US$ par an), payés directement au store ;
• une heure de patience avec la console du store la première fois.

Vous pouvez faire Android maintenant et iOS plus tard. Les deux plateformes avancent séparément du début à la fin.

Où ça se trouve

L’onglet Application, dans la colonne d’icônes de l’éditeur. C’est le dernier, avec l’icône de téléphone.

Les cinq étapes de la configuration

L’assistant enregistre tout seul à chaque étape, vous pouvez donc partir au milieu et revenir plus tard.

Marque

L’icône doit être un PNG carré de 1024×1024. Sans elle, nous en générons une avec l’initiale de l’app sur la couleur de votre marque. Apple refuse les icônes à fond transparent : envoyez-la avec le fond rempli et sans coins arrondis, le système les arrondit lui-même.

L’écran de démarrage marche mieux en PNG avec le logo centré et un fond transparent, puisque la couleur choisie remplit le reste de l’écran. Une photo plein écran est recadrée différemment sur chaque appareil.

L’identifiant de l’app

C’est l’adresse unique de l’app dans les stores, au format com.votreentreprise.votreapp. Nous en suggérons un à partir du nom du projet, et vous pouvez le remplacer par votre domaine à l’envers.

Il ne change pas après la première publication. Le changer ensuite ne renomme pas l’app : cela crée une nouvelle app dans le store, et votre base d’utilisateurs, vos avis et vos téléchargements restent sur l’ancienne. Vérifiez-le avant de publier.

Sur Google Play il y a un piège de plus : l’app doit exister dans la console avec exactement cet identifiant avant l’envoi. L’API de Google ne crée pas l’app, donc si le package n’y est pas, l’envoi échoue avec Package not found. L’écran affiche l’identifiant avec un bouton copier, justement pour que vous le colliez dans la Play Console sans rater un caractère.

Fonctions

Activez ce que l’app utilise vraiment. Les stores attendent d’une app native qu’elle utilise de vraies fonctions natives : une app qui n’est que le site dans une coque est souvent refusée, plus souvent par Apple.

Activer le push ici, c’est ce qui fait demander la permission de notification. Sur Android, livrer la notification exige en plus les deux fichiers Firebase, à l’étape Comptes.

Build de test : installez-la avant d’envoyer

Avant d’envoyer quoi que ce soit à un store, utilisez le Build de test. Il produit une app qui s’installe directement sur l’appareil, sans passer par le store, en 10 à 30 minutes.

Les deux côtés se comportent différemment quand le build se termine :

• Android : vous obtenez un APK et le bouton Installer vous remet le fichier. Il s’installe tout de suite ;
• iOS : le paquet est envoyé à App Store Connect et apparaît dans TestFlight une fois qu’Apple l’a traité. Il n’y a pas de fichier à télécharger et installer directement sur l’iPhone.

Dans les deux cas : une app que vous n’avez jamais ouverte sur un appareil ne devrait pas partir en revue.

Publier

À l’étape Vérifier, le bouton est Publier sur les stores. Ensuite l’écran montre trois états, par plateforme :

La différence entre les deux derniers est celle qui trompe le plus, et elle est réelle : un paquet peut être prêt et tout de même refusé à l’envoi (mauvais identifiant, permission manquante). C’est pourquoi « Envoyé au store » n’apparaît que quand le store confirme la réception, pas quand le build se termine.

Ensuite, c’est la console du store qui informe. La revue se passe chez Apple et Google, et nous n’avons aucun moyen de la suivre. Elle prend de quelques heures à 2 jours, davantage pour la première version d’une app.

Nouveau compte Google Play personnel : les 12 testeurs

Si votre compte Google Play est personnel et a été créé après le 13 novembre 2023, Google exige, avant d’ouvrir la production, un test fermé avec au moins 12 testeurs inscrits en continu pendant 14 jours. C’est par app, pas par compte.

Ce n’est pas une exigence de Fabapp et rien ici ne permet de la contourner : l’envoi fonctionne, l’app devient disponible sur le canal de test, et la production ne s’ouvre qu’après votre demande d’accès et l’accord de Google (jusqu’à 7 jours). Les comptes organisation et les comptes personnels créés avant cette date en sont exemptés.

Prévoyez-le dès le début si votre compte est récent : ce sont 14 jours calendaires qu’on ne peut pas accélérer.

Les échéances des stores qui sont les nôtres, pas les vôtres

Les stores exigent que l’app soit compilée avec des outils récents, et ces échéances sont notre responsabilité : nous gardons la coque native à jour et vous n’avez rien à faire.

Pour que vous sachiez qu’elles existent : Google Play exige que les nouvelles apps et les mises à jour visent Android 16 (API 36) à partir du 31 août 2026, et Apple exige que les envois à App Store Connect soient compilés avec le SDK iOS 26 ou supérieur à partir du 28 avril 2026.

Quand quelque chose échoue

Le journal complet de chaque build est dans l’onglet lui-même, via Voir le journal complet. C’est la première chose à regarder, et son message d’erreur est en général littéral.