Claude Code + mises à jour de l'app
Votre app web Claude Code se met à jour à chaque publication, mais la coque native qui l'entoure ne change que lorsque les utilisateurs installent une nouvelle version depuis le store. Quand une nouvelle fonctionnalité dépend d'une coque plus récente, ou que d'anciens builds pointent vers une URL que vous abandonnez, vous devez savoir qui est en retard. WebViewGold transmet à votre app web la version installée ; quelques lignes de code en font une bannière discrète ou un écran de mise à jour obligatoire.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Les déploiements web atteignent toutes les versions installées au prochain chargement de page. Seuls les changements de la coque native laissent des utilisateurs à la traîne, et voici les trois qui comptent :
Vous activez les achats intégrés, la connexion biométrique ou un nouveau fournisseur de push dans la version 1.3. Les utilisateurs en 1.2 voient le bouton, mais le schéma d'URL qui se cache derrière ne fait rien dans leur build. Masquez ou remplacez la fonctionnalité pour les anciennes versions.
L'URL de départ est compilée dans l'app. Passer d'un sous-domaine du builder à votre propre domaine, ou à un nouvel hébergeur, laisse les anciennes installations sur l'ancienne adresse. Maintenez une redirection et utilisez le contrôle de version pour amener les utilisateurs vers le nouveau build.
Vous changez de fournisseur d'authentification, de domaines de redirection OAuth ou de gestion des liens, et seul le nouveau build possède les réglages natifs correspondants (assistant de connexion, Universal Links, listes d'URL). Un écran de mise à jour est plus aimable qu'une connexion qui échoue en silence.
Collez ceci dans Claude Code pour implémenter la partie app web. Vérifiez le résultat, publiez, puis testez dans l'app WebViewGold.
Lisez https://www.webviewgold.com/llms-full.txt (sections App Version Check API). L'app web tourne dans WebViewGold ; son user agent contient "WebViewGold-iOS" ou "WebViewGold-Android", et versionNumber contient la version installée. Les projets natifs se trouvent dans ./ios-app et ./android-app. 1. Définissez autoInjectVariable = true dans Config.swift et AUTO_INJECT_VARIABLES = true dans Config.java. 2. Ajoutez un contrôle de version à l'app web : attendez versionNumber jusqu'à 3 secondes, récupérez minimum, latest et storeUrl par plateforme depuis un endpoint backend, comparez numériquement, affichez une page de mise à jour plein écran sous le minimum et une bannière sous la dernière version, et laissez passer en cas d'erreur. 3. Ajoutez des tests Playwright qui injectent des valeurs de versionNumber sous les seuils, entre les deux et au-dessus, plus une exécution sans la variable. 4. Incrémentez la version et le numéro de build iOS ainsi que versionName et versionCode Android pour la prochaine publication. 5. Ajoutez à CLAUDE.md une checklist de publication : ne relever le minimum qu'une fois les deux publications en ligne sur les stores et tout déploiement progressif à 100 pour cent.
Avec une bonne version optimisée de votre application Web, vous pouvez avoir une superbe application mobile en quelques minutes. De plus, le service client est très agréable et très utile! Je ne peux que recommander WebViewGold :-)
Le côté natif se contente de signaler la version ; la règle vit dans votre backend.
Passez autoInjectVariable à true dans Config.swift et AUTO_INJECT_VARIABLES à true dans Config.java. WebViewGold fournit alors versionNumber (la version visible par les utilisateurs, par exemple 1.4.0) et bundleNumber (le numéro de build) sous forme de variables JavaScript. Sans injection automatique, naviguez une fois vers getappversion:// et lisez les mêmes variables.
Stockez la version minimale prise en charge et la dernière version par plateforme dans votre backend : une petite table, un fichier JSON ou une entrée de remote config. Changer la règle ne nécessite alors aucune publication sur le store, et idéalement même pas de déploiement.
En tant que chaînes, « 1.10.0 » se classe avant « 1.9.0 ». Découpez sur les points et comparez chaque partie comme un nombre, ou comparez les numéros de build si ce sont de simples entiers croissants.
En dessous de la dernière version : une bannière que l'on peut fermer. En dessous du minimum : une page plein écran « Mise à jour requise » avec un seul bouton vers la fiche du store. Dans un navigateur classique, ou quand la version est inconnue, n'affichez rien.
Faites pointer le lien vers https://apps.apple.com/app/idYOUR_APPLE_ID et https://play.google.com/store/apps/details?id=your.package.name, et ajoutez apps.apple.com et play.google.com aux hôtes qui quittent toujours l'app (safariwhitelist sur iOS, BROWSER_WHITELIST sur Android) : le système ouvre ainsi l'App Store ou le Play Store au lieu d'une page web dans la WebView.
Appelez-le une fois après le premier rendu de votre app Claude Code. Il attend brièvement la variable injectée, laisse passer l'utilisateur à la moindre erreur (fail open) et ne bloque que si votre backend le demande. Utilisez des tokens de user agent différents par plateforme, par exemple « WebViewGold-iOS » dans useragent_iphone / useragent_ipad et « WebViewGold-Android » dans USER_AGENT :
const ua = navigator.userAgent;
const inApp = ua.includes("WebViewGold");
const platform = ua.includes("WebViewGold-Android") ? "android" : "ios";
function compareVersions(a, b) {
const pa = String(a).split(".").map(Number);
const pb = String(b).split(".").map(Number);
for (let i = 0; i < Math.max(pa.length, pb.length); i++) {
const d = (pa[i] || 0) - (pb[i] || 0);
if (d !== 0) return d < 0 ? -1 : 1;
}
return 0;
}
// autoInjectVariable / AUTO_INJECT_VARIABLES = true fournit versionNumber ;
// sinon, faites une fois window.location.href = "getappversion://" avant de sonder
function waitForVersion(ms = 3000) {
return new Promise((resolve) => {
const start = Date.now();
(function poll() {
if (typeof versionNumber !== "undefined") return resolve(String(versionNumber));
if (Date.now() - start > ms) return resolve(null);
setTimeout(poll, 100);
})();
});
}
async function checkAppVersion() {
if (!inApp) return; // navigateur : rien à faire
const installed = await waitForVersion();
if (!installed) return; // inconnue : laisser passer
const rule = await fetch("/api/app-version?platform=" + platform)
.then((r) => (r.ok ? r.json() : null)).catch(() => null);
if (!rule) return; // backend injoignable : laisser passer
if (compareVersions(installed, rule.minimum) < 0) showUpdateRequired(rule.storeUrl);
else if (compareVersions(installed, rule.latest) < 0) showUpdateBanner(rule.storeUrl);
}| Version installée | Résultat | Ce que voit l'utilisateur |
|---|---|---|
| 1.4.0 ou plus récente | À jour | Rien |
| 1.3.0 à 1.3.x | Sous la dernière version | Une bannière que l'on peut fermer : « Une nouvelle version est disponible » |
| 1.2.x ou plus ancienne | Sous le minimum | Une page plein écran qui explique pourquoi, avec un seul bouton vers le store et un contact support |
| Navigateur, preview ou version inconnue | Aucune donnée | Rien : on laisse passer (fail open) |
Non. WebViewGold indique à votre app web quelle version est installée (getappversion:// ou les variables versionNumber et bundleNumber injectées automatiquement). La décision et l'écran de mise à jour se trouvent dans votre app web : vous pouvez donc changer la règle à tout moment, sans publication sur le store.
Généralement pas. La plupart des changements atteignent tous les utilisateurs au prochain chargement de page. Un contrôle de version compte pour les changements natifs : nouvelles fonctionnalités natives, nouvelle URL de départ ou nouveau domaine, gestion des liens ou réglages de connexion modifiés. Beaucoup d'apps n'ont jamais besoin que de la bannière discrète.
Aucun des deux stores n'interdit de demander aux utilisateurs de mettre à jour, et beaucoup de grandes apps le font. Veillez à ne jamais bloquer le build en cours d'examen, expliquez honnêtement pourquoi la mise à jour est nécessaire et ne faites pointer le lien que vers votre propre fiche sur le store.
Google propose une API native de mise à jour in-app pour les apps Android, mais elle ne fait pas partie du pont JavaScript documenté de WebViewGold. Le contrôle de version accompagné d'un lien vers le Play Store fonctionne de la même façon sur les deux plateformes et garde un seul chemin de code.
Dans votre backend, placez temporairement la version minimale au-dessus de votre build TestFlight ou de test interne, ouvrez l'app, vérifiez l'écran et le bouton du store, puis remettez la valeur d'origine. Ouvrez aussi le site dans un navigateur classique : l'écran ne doit jamais s'y afficher.
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.