Après le lancement
Le grand avantage d'une app web encapsulée, c'est que la plupart des mises à jour sont un déploiement, pas une soumission. Ce que l'on oublie, c'est le reste : icônes, autorisations, fonctionnalités natives et exigences annuelles des plateformes nécessitent toujours un build. Voici la répartition, les règles de versionnage et une routine de publication qui prend environ une heure.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
| Changement | Mode de publication | Remarques |
|---|---|---|
| Nouvelles pages, fonctionnalités, corrections de bugs, changements de design dans la web app | Instantané : déploiement dans Lovable, Bolt, Vercel ou chez votre hébergeur | Chaque app installée l'affiche au chargement suivant ; aucune validation |
| Textes, prix affichés sur le web, pages légales | Instantané | Gardez les prix des achats intégrés dans les stores synchronisés avec ce que l'app affiche |
| Icône, nom de l'app, splash screen | Mise à jour en store | Ressources natives intégrées au build |
| Activation d'une fonctionnalité native (fournisseur de push, biométrie, scanner QR, AdMob, RevenueCat) | Mise à jour en store | Un réglage Config plus un nouveau build ; les nouvelles autorisations sont validées |
| Nouveaux textes d'autorisation (appareil photo, localisation, photos) | Mise à jour en store | Mettez aussi à jour les réponses sur la confidentialité de l'app et le formulaire Sécurité des données si l'usage des données change |
| Changement d'URL de départ ou de domaine | Mise à jour en store | À éviter en choisissant le domaine personnalisé avant le lancement |
| Mise à jour du template WebViewGold (nouveau SDK iOS, niveau d'API cible Play, privacy manifests) | Mise à jour en store | Mises à jour gratuites ; nécessaires environ une fois par an pour rester publiable |
| Texte de la fiche et captures d'écran | Pas de build, mais une validation | App Store : captures, description et mots-clés ne changent qu'avec une nouvelle version ; texte promotionnel et URL à tout moment. Play : modifications de la fiche à tout moment, validées |
iOS a deux numéros : la version (CFBundleShortVersionString, par exemple 1.2.0) que voient les utilisateurs, et le numéro de build (CFBundleVersion), qui doit augmenter à chaque envoi, même pour une version identique. Android a versionName (texte libre, affiché aux utilisateurs) et versionCode, un entier qui doit augmenter à chaque envoi vers la Play Console. Définissez-les dans l'onglet General de Xcode et dans build.gradle, ou dans les champs correspondants du Cloud Builder. Gardez une version visible identique sur les deux plateformes et utilisez le format majeure.mineure.correctif ; cela simplifie les échanges avec le support (« quelle version utilisez-vous ? »).
Votre web app a son propre rythme de publication, et les deux peuvent diverger sur un point important : une fonctionnalité web qui a besoin d'une capacité native (par exemple un nouveau parcours QR) ne fonctionnera pas dans les versions de l'app compilées avant l'activation de cette capacité. L'API App Version Check de WebViewGold résout ce problème : naviguez vers getappversion:// et l'app définit window.versionNumber et window.bundleNumber (ou passez autoInjectVariable / AUTO_INJECT_VARIABLES à true pour les faire injecter sur chaque page). Votre web app peut alors masquer la fonctionnalité ou afficher une bannière de mise à jour pour les anciennes installations. Documentation : App Version Check (iOS) et Android.
S'exécute à chaque chargement de page dans l'app. Comparez avec la version la plus ancienne qui prend en charge la web app actuelle.
const inApp = /WebViewGoldApp/.test(navigator.userAgent);
const MIN_APP_VERSION = "1.3.0";
function olderThan(a, b) { // "1.2.9" < "1.3.0"
const pa = a.split(".").map(Number), pb = b.split(".").map(Number);
for (let i = 0; i < 3; i++) { if ((pa[i] || 0) !== (pb[i] || 0)) return (pa[i] || 0) < (pb[i] || 0); }
return false;
}
if (inApp) {
window.location.href = "getappversion://"; // WebViewGold définit window.versionNumber
setTimeout(() => {
if (window.versionNumber && olderThan(String(window.versionNumber), MIN_APP_VERSION)) {
document.getElementById("update-banner").hidden = false; // « Une nouvelle version est disponible » + lien vers le store
}
}, 800);
}
Je suis très content d'avoir acheté cette application ! Extrêmement facile et excellente documentation. J'ai été en contact avec le service client, ils ont répondu très rapidement et très amicalement. Ils ont résolu ma question en un jour. 10/10 recommanderaient.
Environ une heure de travail, plus le temps de validation. À faire chaque fois qu'une ligne du tableau ci-dessus indique « mise à jour en store ».
Téléchargez la version actuelle (les mises à jour sont gratuites), puis reportez vos valeurs de Config.swift et Config.java, l'icône, le splash, GoogleService-Info.plist ou google-services.json et vos éventuels textes d'autorisation personnalisés. Votre keystore Android et votre clé d'importation restent les mêmes. Les utilisateurs du Cloud Builder sautent cette étape : le service compile avec le template maintenu à jour.
Version 1.2.0 → 1.3.0, numéro de build +1, versionCode +1.
Xcode → Product → Archive → Distribute vers App Store Connect ; Android Studio → Build → Generate Signed Bundle → envoi vers la Play Console. Ou un clic dans le Cloud Builder pour les deux.
Test interne TestFlight et canal interne Play : connexion, demande d'autorisation push, écran hors ligne, un deep link depuis un e-mail, un achat en sandbox si vous vendez quelque chose. Quinze minutes sur un vrai téléphone ; voir le guide des tests.
Apple : choisissez la publication progressive (sept jours, pourcentage croissant automatiquement, possibilité de pause) ou la publication manuelle après approbation. Google : déploiement par étapes, commencez à 10 à 20 pour cent et augmentez sur quelques jours ; arrêtez si Android Vitals montre un pic de plantages.
Plantages et avis dans App Store Connect, Android Vitals et e-mails sur les règles dans la Play Console. Les corrections côté web restent instantanées pendant le déploiement du build natif.
splashTimeout ou activez remainSplashOption.Les nouvelles apps et les mises à jour doivent cibler une version récente d'Android avant l'échéance annuelle de Google. Un ancien template ne peut plus être envoyé après cette date ; le guide du niveau d'API cible explique le calendrier.
Les envois doivent être compilés avec un Xcode et un SDK iOS récents, et les apps iOS embarquent désormais des privacy manifests. Les mises à jour du template apportent les deux.
Les mises à jour ajoutent des API (scanner de documents, données de santé, widgets) que vous pouvez exposer à votre web app avec un simple lien chacune.
Même sans changement, recompiler une fois par an sur le template actuel garde l'app publiable et la date de mise à jour récente pour l'ASO.
Non. La validation n'a lieu que lorsque vous soumettez un nouveau build ou modifiez les métadonnées de la fiche. Le contenu de la web app vous appartient et vous pouvez le modifier, tant que l'app reste conforme à sa fiche et aux guidelines.
Au moins une fois par an pour les exigences des plateformes, plus chaque fois que vous changez une icône, une fonctionnalité native ou une autorisation. Beaucoup d'équipes s'en tiennent à une mise à jour en store tous les un à deux mois.
Pas de force, mais la vérification de version vous permet de bloquer les anciennes versions de l'app derrière un message avec un lien vers le store quand un changement côté backend l'exige.
Non. Les cookies et le localStorage survivent aux mises à jour, sauf si les options de vidage du cache sont activées dans les fichiers Config.
Même résultat, charge de travail différente de votre côté. Les trois formules incluent la garantie d'approbation et le support humain 24/7.
$109 par plateforme, paiement unique
La licence WebViewGold : un projet Xcode ou Android Studio prêt à l'emploi. Collez votre URL, définissez le nom et l'icône, activez les fonctionnalités, compilez et soumettez. Mises à jour gratuites à vie.
Voir les offres sur la page principale$349 par licence, extension en paiement unique
Ni Mac, ni Xcode, ni Android Studio : configurez dans le navigateur, nous compilons les deux apps dans le cloud et les transmettons à App Store Connect et à la Play Console.
Comment fonctionne le Cloud Builder Essayer la démo gratuite$698 par plateforme $798
Envoyez-nous votre URL et votre icône. Notre équipe configure, compile et livre votre app sous 72 heures, en marque blanche, projets sources inclus. Les deux plateformes pour $1,158.
Détails du Full Service Propulsé par
Prix Soldes d'hiver valables jusqu'au 31 décembre 2026.
Garantie d'approbation App Store & Google Play – ou remboursement sous 14 jours
Vous préférez déléguer ? Full Service : nous configurons, compilons et livrons sous 72 heures, dès $698 par plateforme. Des questions ? Chattez avec nous 24/7.
Les remboursements sont accordés aux conditions indiquées dans notre FAQ : un refus non lié au contenu par Apple et/ou Google, demandé dans les 14 jours suivant l'achat.