Fonctionnalité native
Les changements web sont livrés instantanément, les changements natifs non. Des guides par outil pour une règle de version dans votre backend, un contrôle qui laisse passer en cas d'erreur et des liens qui ouvrent la bonne app de store.
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.
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.
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.
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.
