Aller au contenu
supastack
Parcourir la documentation
MobileExpo

For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /fr/docs/mobile/publishing.md (or send Accept: text/markdown).

Publication sur les boutiques d’applications

Distinguez un build fonctionnel d’une version que les utilisateurs peuvent installer.

Poser une question sur ce guide
Ouvrir dans

Préparez votre première soumission de magasin étape par étape

Créez et testez d’abord une version de développement native à l’aide des versions mobiles. Une soumission de magasin envoie l'application compilée et sa liste à Google ou Apple pour examen ; ce n'est pas la même chose que d'ouvrir un aperçu Expo Go. Vous avez besoin de votre propre Expo et des comptes de développeur de magasin pertinents, d'un backend HTTPS testé, du nom/icône final de l'application, de captures d'écran, d'un contact d'assistance et d'une politique de confidentialité publique URL.

Ouvrez apps/mobile/app.json dans l'éditeur et définissez le nom de l'application, le slug, ios.bundleIdentifier et android.package pour votre propre produit avant le premier téléchargement. Ouvrez apps/mobile/eas.json et remplacez les identifiants d'application de l'équipe de soumission iOS par les vôtres, si nécessaire. Les identifiants expédiés sont des exemples. Lisez les versions mobiles pour connaître les champs exacts et demandez à votre agent de codage d'examiner les deux fichiers avant de créer.

Si eas n'est pas installé, exécutez npm install --global eas-cli. À partir de la racine du référentiel, utilisez la commande de connexion ci-dessous, terminez l'authentification du navigateur, puis sélectionnez la commande build pour une plate-forme dans Build, puis soumettez. Lire les journaux du tableau de bord de la build ; attendez un .aab ou un .ipa réussi avant de tenter de le soumettre. EAS demande la liaison du projet et la signature des informations d'identification ; ceux-ci appartiennent à vos comptes, pas à ceux du vendeur du kit.

Une fois le binaire téléchargé, ouvrez votre application dans la Play Console ou l'App Store Connect, complétez la liste et les questionnaires requis, ajoutez les instructions de connexion du réviseur fonctionnel, puis soumettez-le pour examen. Le téléchargement d’un brouillon interne n’est pas une version publique. Si l'examen le rejette, ouvrez le lien de politique exact dans le rejet et corrigez ce problème avant de le soumettre à nouveau.

corepack pnpm --filter @supastack/mobile exec eas login

Configurer les comptes une seule fois

La publication nécessite trois comptes : un compte Expo gratuit pour EAS Build et Submit, une inscription développeur Google Play Console et une adhésion au programme Apple Developer pour iOS. Installez l’EAS CLI et lancez eas login avant de compiler ; la vérification des inscriptions aux deux stores peut prendre plusieurs jours, commencez donc tôt.

Renommez les identifiants de l’application avant le premier envoi : android.package et ios.bundleIdentifier valent com.supastack.app dans apps/mobile/app.json. Google Play verrouille le nom du package au premier envoi ; un identifiant incorrect exige donc une nouvelle fiche au lieu d’un renommage.

Laisser EAS gérer les signatures

apps/mobile/eas.json définit les profils de compilation development, preview et production. Le profil production permet à EAS de générer et de conserver l’Android keystore et le certificat de distribution iOS sur son infrastructure ; consultez-les ensuite avec eas credentials et ne versionnez pas de keystores locaux.

Les envois Play automatisés exigent une clé JSON de compte de service Google Play liée dans Play Console → Configuration → Accès à l’API avec la permission de publication. Enregistrez-la sous apps/mobile/secrets/play-store-service-account.json, chemin attendu par eas.json dans un répertoire ignoré par Git. Le premier envoi d’une nouvelle application se fait encore manuellement dans Play Console ; eas submit prend le relais dès la deuxième version.

Compiler, puis envoyer

Les compilations s’exécutent sur l’infrastructure EAS : Android Studio et Xcode ne sont pas nécessaires pour produire le binaire. Le profil production produit un .aab prêt pour le store et un .ipa pour l’App Store avec des numéros de version gérés à distance. Le profil preview produit un APK à distribution interne pour les essais sur appareil physique.

Le profil d’envoi fourni cible la piste interne Play sous forme de brouillon ; aucun testeur ne reçoit la version avant sa promotion dans Play Console après la réussite de la revue.

corepack pnpm --filter @supastack/mobile build:android
corepack pnpm --filter @supastack/mobile submit:android

corepack pnpm --filter @supastack/mobile build:ios
corepack pnpm --filter @supastack/mobile submit:ios

# Internal-testing APK for a physical device:
corepack pnpm --filter @supastack/mobile build:android:preview

Remplir les formulaires Play Console

La revue Play porte autant sur les déclarations que sur le binaire : URL publique de politique de confidentialité, formulaire Data safety, questionnaire de classification du contenu, public cible et catégorie. Répondez au formulaire Data safety selon le comportement réel de l’application : le kit collecte l’e-mail du compte pour l’authentification, conserve les jetons de session dans le stockage sécurisé de la plateforme et communique uniquement avec l’API que vous avez configurée ; ajoutez ce que votre produit collecte en plus.

Pour une application iOS qui nécessite une connexion, fournissez à App Review un compte de démonstration fonctionnel et des instructions dans les notes de révision. Consultez la règle actuelle des services de connexion d'Apple et ses exceptions avant de choisir les options de connexion sociale ; les exigences dépendent du flux de connexion réel de l'application. Les directives officielles sont liées dans la section de première soumission ci-dessus.

Garder les achats derrière RevenueCat

Si votre application propose des achats mobiles, configurez le parcours RevenueCat fourni : définissez MOBILE_PURCHASES_PROVIDER=revenuecat et EXPO_PUBLIC_MOBILE_PURCHASES_PROVIDER=revenuecat, puis ajoutez la clé SDK publique correspondant à iOS ou Android. L’application native prend en charge l’achat et la restauration ; après chaque opération, l’accès est actualisé à partir du droit de l’espace de travail vérifié par le serveur. Stripe Checkout n’est pas utilisé dans le parcours mobile. Gardez le paywall désactivé si les achats sont sur off ou si une configuration requise manque. Validez les produits configurés, l’achat, la restauration et l’actualisation du droit dans un build de développement EAS avec des comptes de test des boutiques. Consultez les consignes actuelles de chaque boutique pour connaître les exigences applicables à votre application et à vos régions.

Liste de contrôle avant envoi

Avant de soumettre, confirmez chaque élément ci-dessous en utilisant votre propre application de test et vos comptes de magasin.

  • android.package et ios.bundleIdentifier ont été remplacés par des identifiants qui vous appartiennent
  • EXPO_PUBLIC_API_URL dans l’environnement de compilation pointe vers l’API de production
  • La politique de confidentialité est hébergée publiquement et liée depuis la fiche du store
  • Le formulaire Data safety correspond aux véritables données collectées : e-mail d’authentification, trafic API et ajouts du produit
  • Des identifiants de compte de démonstration fonctionnels figurent dans les notes de revue App Store
  • Le paywall est masqué ou repose sur un droit RevenueCat vérifié
  • Le retour par lien profond, la restauration de session et la déconnexion ont été vérifiés sur un appareil physique
  • Les captures d’écran et les ressources de fiche sont préparées pour chaque store

Corriger un rejet

Un rejet indique une référence de règle : corrigez la cause déclarée au lieu de deviner le symptôme. Une incohérence Data safety signifie généralement que le formulaire est incorrect, pas l’application. Un rejet exigeant la connexion indique souvent que les notes de revue ne contiennent pas de compte de démonstration. Renvoyez la version avec des notes qui décrivent clairement la correction.

Le guide complet — commandes d’identifiants, ordre des opérations dans les consoles et guide de reprise après rejet — se trouve dans docs/mobile-store-submission.md du dépôt.

Configuration et paramètres

La publication native nécessite des comptes développeur Apple et/ou Google, des identifiants d’application, des certificats de signature et la validation des boutiques. Le profil EAS de production incrémente les numéros de build de boutique ; submit.production envoie une version brouillon sur la piste interne de Google Play. Les identifiants du bundle et le schéma de l’application se trouvent dans apps/mobile/app.config.ts.

Les déploiements Web et les publications en boutique suivent des calendriers différents. Gardez l’API compatible avec la version prise en charge la plus ancienne, ou contrôlez les nouvelles fonctionnalités à partir d’un état défini par le serveur.

corepack pnpm --filter @supastack/mobile build
eas build --profile production --platform ios
eas build --profile production --platform android
eas submit --profile production --platform ios
eas submit --profile production --platform android

Processus d’implémentation

Avant d’activer les achats natifs, configurez le projet RevenueCat, les produits de boutique et le droit d’accès. La clé secrète serveur et la valeur Authorization du webhook doivent rester dans la configuration serveur ; les clés SDK iOS et Android sont des valeurs publiques intégrées au build. Désactivez les accès sandbox en production.

Préparez les éléments de boutique — captures d’écran, description, informations de confidentialité et mentions d’achat — dans les documents de publication du produit. Les achats et restaurations RevenueCat sont comparés à l’état actuel de l’abonné côté serveur avant que l’application n’affiche l’accès.

Vérification et dépannage

Testez précisément l’artefact soumis : callback de connexion, restauration de session, achat et restauration, actualisation du droit serveur, changement d’espace de travail, liens profonds et fonctionnement hors ligne sur un appareil physique. Un export local réussi n’est pas un build prêt pour la boutique.

Consignez le numéro de build, la piste de la boutique, l’état de validation et l’environnement API ciblé par chaque publication. Un refus de validation est un événement de publication : corrigez les informations ou les indicateurs de capacité au lieu de modifier le code à l’aveugle.

Prochaine plateforme : l’onglet Desktop présente le même produit dans l’enveloppe Tauri.

Questions fréquentes

14 questions

Qu'est-ce que supastack ?

supastack est une fondation modulaire pour construire des produits SaaS avec IA. Elle réunit l'infrastructure commune pour que vous puissiez vous concentrer sur les fonctionnalités propres à votre produit.

Prend-il en charge le web et le mobile ?

Oui. supastack inclut des applications Next.js et Expo comme points de départ pour des expériences web et mobile.

Quelle authentification est incluse ?

Better Auth couvre e-mail/mot de passe, OTP et connexion sociale. Les espaces de travail personnels sont provisionnés avec le compte pour que les enregistrements restent délimités dès le premier jour.

Comment l'IA est-elle prise en charge ?

supastack inclut une IA multi-fournisseurs configurable, le suivi d'usage, des budgets, et la prise en charge chiffrée de vos propres clés (BYOK).

Comment les abonnements sont-ils gérés ?

Pour les produits construits sur le kit, la facturation Stripe, les abonnements et les droits d'accès forment la base de l'accès payant. Les secrets fournisseur restent côté serveur.

Où vit le code propre à mon produit ?

Les fonctionnalités propres au produit restent dans un codebase séparé, tandis que le produit configure et intègre les modules de la fondation supastack.

Comment fonctionne la tarification de supastack ?

Le kit est un achat unique avec mises à jour à vie : Un framework à 249 $ (prix de lancement temporaire — 100 $ de réduction par rapport au prix habituel de 349 $) ou Tous les frameworks (Next.js, iOS, Android) à 499 $ (prix de lancement temporaire — 100 $ de réduction par rapport au prix habituel de 599 $), plus 75 $ par siège développeur supplémentaire. Pas d'abonnement au kit. Le paiement sur ce site livre votre clé de licence par e-mail, avec accès au dépôt via invitation GitHub.

Comment les espaces de travail délimitent mes données ?

Les enregistrements appartenant aux utilisateurs sont délimités par workspaceId. Identité, droits d'accès, usage IA, événements de facturation et entrées d'audit restent dans le périmètre de l'espace personnel.

Comment fonctionnent les jobs en arrière-plan ?

Trigger.dev est le runtime de jobs explicite. Le contrat JobRunner ne promet que enqueue, status et cancel — la sémantique de workflow reste propre à Trigger.dev et explicite.

En quoi l'e-mail diffère-t-il de la prospection ?

L'e-mail transactionnel couvre les flux produit comme les avis de fin de tâche. La prospection à froid et les campagnes relèvent du produit, hors du module e-mail de ce kit.

Comment fonctionnent les achats sur mobile ?

Le mobile inclut les achats natifs et leur restauration via RevenueCat, avec un accès vérifié par votre serveur. Configurez les comptes des boutiques et terminez les tests sur appareil avant publication. La facturation web reste séparée.

Où vivent les clés des fournisseurs IA ?

Les identifiants BYOK sont chiffrés et restent côté serveur. Les clés sont masquées dans les journaux ; l'usage et les budgets restent visibles au niveau de l'espace de travail.

Quels moyens de paiement le checkout accepte-t-il ?

Le checkout hébergé par Stripe accepte les cartes et peut aussi proposer Alipay et WeChat Pay une fois ces portefeuilles activés sur le compte Stripe — pratique pour les acheteurs en Chine. Les autorisations de portefeuille se confirment de manière asynchrone : la page de licence se met à jour dès que le paiement est validé.

Puis-je obtenir un remboursement ?

Une fois que vous avez accès au dépôt, supastack vous appartient pour toujours et ne peut donc pas être remboursé. Mais rassurez-vous : vous obtenez le code source complet avec des mises à jour à vie pour créer et déployer un nombre illimité de produits pour vous ou vos clients. Vous ne pouvez simplement pas revendre le code ni redistribuer le dépôt sous forme de kit de démarrage ou de modèle.

FR
Thème