Comment publier une web app sur l'App Store en 11 étapes

Pour publier une web app sur l'App Store et Google Play, encapsulez votre web app compilée dans un projet natif avec Capacitor, ajoutez quelques fonctionnalités natives, créez des comptes développeurs Apple et Google, signez et compilez les binaires iOS et Android, testez-les avec de vrais utilisateurs, préparez les fiches des stores et soumettez l'app pour revue. Votre HTML, CSS et JavaScript existants continuent de s'exécuter dans une WebView native : pas besoin de réécrire l'app.

Voici les 11 étapes dans l'ordre qui évite les temps d'attente, avec les commandes pour Capacitor 8 et les règles des stores applicables en octobre 2026.

Ce dont vous avez besoin

• Une application web qui se compile en fichiers statiques (React, Vue, Angular, Svelte, export statique Next.js, Nuxt generate, HTML simple, ou une application créée avec un outil de création IA comme Lovable ou Bolt).
• Node.js 22 ou ultérieur (exigence Capacitor 8) et Bun ou un autre gestionnaire de paquets.
• Android Studio pour les builds Android.
• Xcode 26 sur macOS pour les builds iOS, ou un service de build cloud si vous n’avez pas de Mac.
• 99 $ par an pour Apple et 25 $ une seule fois pour Google.

Calendrier réaliste

Étape 1 : Commencez l’inscription du compte développeur aujourd’hui

La vérification du compte est l’étape que vous ne pouvez pas accélérer : faites-la donc avant de coder.

• Programme Apple Developer: 99 $ par an. Les particuliers doivent disposer d’un Apple Account avec l’authentification à deux facteurs et de leur nom légal. Les organisations doivent également fournir un numéro D-U-N-S, un site web d’entreprise et un e-mail professionnel sur ce domaine.
• la Google Play Console: 25 USD once. Organizations need a D-U-N-S number. Expect ID verification.

Si vous vous inscrivez sur Google Play en tant que particulier, votre compte est soumis à la règle des tests fermés (étape 9). Tutoriel complet : comment créer des comptes développeurs Apple et Google Play.

Étape 2 : Préparez votre web app pour mobile

Capacitor exécute votre application dans une WebView. Ce qui passe bien dans un onglet de navigateur paraît étrange dans une application :

• Sortie de build statique. Capacitor charge les fichiers depuis le bundle de l’application. Le rendu côté serveur ne s’exécute pas sur le téléphone. Utilisez la sortie statique de votre framework (next build par output: 'export', nuxt generate, Vite build). Les appels API passent par HTTPS vers votre backend, comme avant.
• Routage côté client qui fonctionne depuis une origine fichier. Utilisez le routage history (Capacitor sert l’application depuis https://localhost sur Android et capacitor://localhost sur iOS, pour que cela fonctionne) et assurez-vous que les deep URLs basculent sur index.html.
• CORS. Ajoutez les origines Capacitor aux origines autorisées de votre API : capacitor://localhost (iOS) et https://localhost (Android).
• Le tactile, pas le survol. Supprimez les menus au survol. Prévoyez des zones tactiles d'au moins 44 x 44 points.
• Zones de sécurité. Ajoutez viewport-fit=cover à la balise meta viewport et ajoutez du padding aux headers et aux barres inférieures avec env(safe-area-inset-top) et env(safe-area-inset-bottom).
• Mode hors ligne et réseaux lents. Affichez un état correct plutôt qu'un écran vide. Les reviewers testent sur un Wi-Fi instable.
• Pas de bannières « téléchargez notre app » et aucun lien renvoyant les utilisateurs vers votre site web pour les tâches essentielles.

<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />

Étape 3 : Ajouter Capacitor

Depuis la racine de votre projet web :

bun add @capacitor/core
bun add -d @capacitor/cli
bunx cap init "My App" com.example.myapp --web-dir dist
bun add @capacitor/ios @capacitor/android
bun run build
bunx cap add ios
bunx cap add android

Utilisez le dossier de sortie réel pour --web-dir: dist pour Vite, out pour l'export statique Next.js, .output/public pour Nuxt generate, build pour Create React App, dist/<project>/browser pour Angular.

Le bundle ID (com.example.myapp) est permanent une fois l'app sur les stores. Utilisez un domaine inversé que vous contrôlez.

Votre capacitor.config.ts ressemble maintenant à :

import type { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  appId: 'com.example.myapp',
  appName: 'My App',
  webDir: 'dist',
};

export default config;

Capacitor 8 crée le projet iOS avec Swift Package Manager par défaut, donc pas besoin de CocoaPods. À chaque fois que vous modifiez le code web :

bun run build
bunx cap sync

Exécutez-le :

bunx cap run ios
bunx cap run android

Commitez les ios/ et android/ dossiers. Ce sont des code sources que vous modifierez (permissions, icônes, signature). Pour en savoir plus, consultez comme il est simple de transformer une web app en application mobile avec Capacitor, et si vous avez buildé avec un outil IA, notre guide « De Lovable au mobile ».

Étape 4 : Ajouter des fonctionnalités natives pour justifier une app

La directive 4.2 d'Apple (Fonctionnalité minimale) rejette les apps qui ne sont qu'un site web dans une coquille. Vous n'avez pas besoin de dizaines de fonctionnalités natives, mais l'app doit se comporter comme une app. Ajouts courants et utiles :

Exemple : afficher la feuille de partage native au lieu d'un bouton « Copier le lien ».

import { Share } from '@capacitor/share';
import { Capacitor } from '@capacitor/core';

export async function shareLink(url: string, title: string) {
  if (Capacitor.isNativePlatform()) {
    await Share.share({ title, url });
  } else {
    await navigator.clipboard.writeText(url);
  }
}

Si vous vendez du contenu numérique ou des abonnements, prévoyez les paiements dès maintenant. Apple et Google exigent leurs systèmes d'achat in-app pour les biens numériques dans la plupart des cas. Sur l'App Store aux États-Unis, les apps peuvent aussi renvoyer vers un paiement web externe depuis la décision de justice de 2025 ; d'autres régions ont leurs propres règles. Les biens et services physiques (livraisons, trajets) peuvent passer par Stripe ou n'importe quel prestataire de paiement. Voir achats in-app avec Capacitor.

Le catalogue complet des plugins Capgo se trouve sur la page des plugins.

Étape 5 : icônes, splash screen et chaînes de permission

Générez toutes les tailles d’icônes et de splash à partir de deux images sources :

bun add -d @capacitor/assets
# assets/icon.png 1024x1024, assets/splash.png 2732x2732
bunx capacitor-assets generate

Sur iOS, chaque permission utilisée nécessite une description d'usage dans ios/App/App/Info.plist, sinon l'app plante au moment de la demande et Apple la rejette :

<key>NSCameraUsageDescription</key>
<string>Take a photo of your receipt to attach it to an expense.</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>Choose receipt photos from your library.</string>

Rédigez des raisons précises. « Cette app a besoin de la caméra » sera rejetée.

Sur Android, les plugins ajoutent eux-mêmes la plupart des permissions au manifest. Supprimez celles que vous n'utilisez pas ; Google vous demande de justifier les plus sensibles.

Ajoutez aussi un manifeste de confidentialité (PrivacyInfo.xcprivacy) si votre code utilise des API nécessitant une justification. Voir le guide sur les privacy manifests pour les apps iOS.

Étape 6 : Configurer la signature

iOS. Vous avez besoin d'un certificat Apple Distribution (avec sa clé privée, généralement exportée au format .p12) et d'un profil de provisionnement App Store Connect pour votre bundle ID. Xcode peut les créer automatiquement, ou vous pouvez les créer vous-même, même sans Mac. Lisez les certificats iOS et les profils de provisionnement expliqués; le Générateur de certificats iOS gère l'étape CSR dans le navigateur.

Android. Créez un keystore d'upload et gardez-en une sauvegarde. Google Play utilise Play App Signing : Google détient la clé de signature finale de l'app et vous signez vos uploads avec la vôtre.

keytool -genkeypair -v -keystore upload-keystore.jks -alias upload \
  -keyalg RSA -keysize 2048 -validity 10000

Ou utilisez le générateur de keystore Android en ligne.

Étape 7 : Compiler les binaires de la release

En local

iOS (sur un Mac avec Xcode 26, requis pour les uploads sur l'App Store depuis avril 2026) :

1. bunx cap open ios
2. Sélectionnez l’ cible comme cible, réglez la version et le numéro de build, puis choisissez votre équipe dans Signing & Capabilities.
3. Choisissez Tout appareil iOS (arm64), puis Product > Archive.
4. Dans l’Organizer, Distribuer l'app > App Store Connect > Envoyer.

Android :

bun run build
bunx cap sync android
cd android
./gradlew bundleRelease

L’AAB se trouve dans android/app/build/outputs/bundle/release/. Configurez signingConfigs dans android/app/build.gradle avec votre keystore, en chargeant les mots de passe depuis des variables d’environnement.

Assurez-vous que targetSdkVersion est 36. À partir du 31 août 2026, Google Play exige que les nouvelles applications et les mises à jour ciblent Android 16 (API 36), qui est la valeur par défaut de Capacitor 8.

Dans le cloud

Si vous n’avez pas de Mac, ou si vous souhaitez des builds reproductibles depuis la CI, Build Capgo compile pour les deux plateformes sur des machines hébergées et peut envoyer directement sur TestFlight et Google Play :

bunx @capgo/cli@latest build credentials save --appId com.example.myapp --platform ios
bunx @capgo/cli@latest build credentials save --appId com.example.myapp --platform android
bunx @capgo/cli@latest build request com.example.myapp --platform ios --path .
bunx @capgo/cli@latest build request com.example.myapp --platform android --path .

Les identifiants ne sont utilisés que pour le build et ne sont pas stockés sur les serveurs Capgo. Voir Capgo Docs de build.

Étape 8 : Distribuer aux testeurs

Testez le build sur de vrais appareils avant que quiconque chez Apple ou Google ne le voie.

• iOS: envoyez-le sur TestFlight. Les testeurs internes (jusqu’à 100 membres de l’équipe) le reçoivent juste après le traitement ; les testeurs externes (jusqu’à 10 000) après un bref examen Beta App Review.
• Android: créez une release de test interne dans Play Console et partagez le lien d’inscription.

Testez l’inscription et la connexion, les paiements en sandbox, les notifications push, le comportement hors ligne, le clavier qui masque les champs de saisie et le bouton retour sur Android. Détails pour chaque option : comment distribuer des apps iOS et Android aux testeurs.

Étape 9 : Lancer le test fermé de Google Play (nouveaux comptes personnels)

Si votre compte Play est un compte personnel créé après le 13 novembre 2023, vous ne pourrez pas publier en production tant que vous n'aurez pas effectué un test fermé avec au moins 12 testeurs inscrits pendant 14 jours consécutifs. Demandez ensuite l'accès à la production dans le dashboard de la Play Console ; Google l'examine généralement en une semaine.

Commencez dès que vous avez un build Android utilisable. Utilisez un groupe Google comme liste de testeurs pour que les gens puissent s'inscrire eux-mêmes. Déployez des mises à jour pendant ces 14 jours et recueillez des retours, car Google vous demandera ce que vous avez appris. Les comptes d'organisation sont exemptés.

Étape 10 : Préparer les fiches des stores et soumettre

Pour les deux stores, vous aurez besoin de : nom de l'app, descriptions, captures d'écran aux tailles acceptées, icône, URL de la politique de confidentialité, déclarations de confidentialité (Apple App Privacy et Google Data safety), questionnaire de classification d'âge, contact du support, et un compte de démo si l'app a une connexion. Google demande aussi un graphique de présentation de 1024 x 500. Spécifications et limites : comment préparer vos fiches App Store et Google Play.

Publication sur iOS : dans App Store Connect, créez la version, sélectionnez le build TestFlight, renseignez App Review Information (compte de démo, notes), puis cliquez sur Ajouter pour examen, puis Envoyer.

Publication sur Android : créez une release de production avec l’AAB (ou promouvez celle testée depuis une piste de test), complétez chaque Contenu de l’app déclaration, définissez les pays et envoyez pour validation.

Les rejets les plus fréquents pour les web apps :

1. 4.2 Fonctionnalité minimale: l’app n’est que votre site web. Ajoutez de la valeur native et supprimez l’interface de navigateur.
2. Connexion requise, mais aucun compte de démo, ou le compte ne fonctionne pas.
3. Aucune option de connexion respectant la vie privée lorsque vous proposez une connexion Google ou Facebook sur iOS. La directive 4.8 exige une option équivalente limitant la collecte de données ; Sign in with Apple est le choix habituel.
4. Aucune suppression de compte dans l'application lorsque les utilisateurs créent des comptes.
5. Achats numériques via Stripe lorsque l’achat in-app est requis.
6. Mise en page iPad cassée car le projet prend en charge l’iPad par défaut.
7. Textes de permission manquants ou trop vagues.

Notre guide du premier examen de l'app et guide de publication d'app iOS examinons chacune en détail.

Étape 11 : Déployer des mises à jour sans attendre la validation

Après le lancement, la plupart de vos changements resteront dans le code web. Au lieu de créer un nouveau build pour le store à chaque correction, ajoutez des live updates. L'updater Capgo télécharge les nouveaux bundles web depuis Capgo et les applique au prochain lancement, avec un rollback automatique si le nouveau bundle ne démarre pas.

bun add @capgo/capacitor-updater
bunx cap sync
bunx @capgo/cli@latest init

Appelez notifyAppReady() lorsque votre application a démarré, pour que l'updater sache que le bundle fonctionne :

import { CapacitorUpdater } from '@capgo/capacitor-updater';

CapacitorUpdater.notifyAppReady();

Ensuite, chaque release du code web se fait en une commande :

bun run build
bunx @capgo/cli@latest bundle upload --channel production

Les deux stores autorisent cela pour le code interprété, tant que la mise à jour ne modifie pas la fonction principale de l'app ou ne contourne pas leurs règles de paiement. Les changements natifs (nouveaux plugins, nouvelles permissions, mises à niveau Capacitor) passent toujours par les stores. En savoir plus sur les live updates Capgo et le la doc de l'updater.

Ajoutez le plugin avant votre première publication sur les stores. Il doit être présent dans le binaire installé par les utilisateurs, sinon votre premier live update ne pourra atteindre les utilisateurs qu'après une deuxième release sur les stores.

Enfin, automatisez : build et upload à chaque tag via GitHub Actions ou GitLab CI, et publiez des live updates à chaque merge sur main, et réservez les releases natives pour les changements natifs.

Checklist pré-lancement

• Comptes Apple et Google approuvés, accords acceptés
• L'app fonctionne hors ligne ou affiche un état hors ligne clair
• Safe areas, clavier et bouton retour Android gérés
• Au moins quelques fonctionnalités natives qu'un site web ne peut offrir
• Icônes, splash, textes de permission, manifeste de confidentialité
• Certificat de distribution, profil App Store, keystore d'upload sauvegardé
• Cible SDK 36 sur Android, compilé avec Xcode 26 sur iOS
• TestFlight et tests internes Play effectués sur de vrais appareils
• Test fermé Google Play terminé (comptes personnels)
• Fiches complètes sur les deux stores, compte démo ajouté
• In-app account deletion if users can sign up
• Plugin Live Updates inclus dans le premier binaire

Troubleshooting

Écran blanc au lancement. webDir pointe vers le mauvais dossier ou vous avez oublié bunx cap sync après le build. Vérifiez ios/App/App/public et android/app/src/main/assets/public contiennent index.html.

les appels API échouent uniquement dans l'app. CORS : autorisez capacitor://localhost et https://localhost. Vérifiez également que vous n'appelez pas http:// d'URL qu'iOS bloque par défaut.

Routes 404 après un refresh ou un deep link. Utilisez un routeur avec un repli vers index.html, or hash routing for older setups.

Erreurs de signature Xcode. Consultez la liste des erreurs dans les certificats iOS et les profils de provisionnement expliqués.

Échec du build Gradle après la mise à jour. Capacitor 8 nécessite Android Studio Otter (2025.2.1) ou une version ultérieure ainsi que JDK 21, comme indiqué dans la Capacitor guide de mise à niveau. Pour les autres erreurs Gradle, consultez comment résoudre les erreurs de build Android dans Capacitor.

L'upload Google Play a été rejeté pour la cible SDK. Définissez targetSdkVersion = 36 dans android/variables.gradle.