Lovable + stockage sur l'appareil
Les utilisateurs attendent d'une app qu'elle se souvienne d'eux. Les cookies et le localStorage gardent généralement votre app Lovable connectée, mais ce sont des stockages web qui disparaissent avec le cache. WebViewGold ajoute deux petits outils natifs : un stockage de valeurs persistant (writevalue:// et readvalue://) pour les réglages et la restauration de session, et un UUID d'appareil (get-uuid://) pour les licences liées à un appareil, les appareils de confiance et les réglages par appareil sur votre serveur.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
writevalue:// enregistre tout ce qui suit le schéma comme une seule chaîne dans le stockage privé de l'app ; readvalue:// la réinjecte dans la page, sous la forme window.storedValues sur iOS et window.appSettings sur Android. Les valeurs survivent aux redémarrages et aux vidages du cache, et disparaissent quand l'app est désinstallée (sur Android, aussi quand ses données sont effacées).
get-uuid:// définit la variable JavaScript uuid, un identifiant d'appareil unique et non personnel. Vous pouvez aussi l'ajouter une fois à la première requête sous la forme ?uuid=XYZ (enhanceUrlUUID / UUID_ENHANCE_WEBVIEW_URL) ou l'injecter sur chaque page (autoInjectVariable / AUTO_INJECT_VARIABLES).
Pas une synchronisation entre appareils, pas une base de données, pas un coffre-fort de mots de passe. Gardez des valeurs légères (réglages, indicateurs, un token révocable), conservez les données utilisateur dans Supabase ou Lovable Cloud (Postgres, stockage, edge functions) et ne considérez jamais l'UUID comme une preuve d'identité.
Collez ceci dans Lovable pour implémenter la partie app web. Vérifiez le résultat, publiez, puis testez dans l'app WebViewGold.
Ajoutez une persistance native pour le wrapper d'app WebViewGold. 1) Créez src/lib/nativeStore.ts avec inApp() (navigator.userAgent contient mon token WebViewGold), writeValues(obj), qui navigue vers writevalue:// suivi de paires key=value séparées par des points-virgules (valeurs limitées aux lettres, chiffres, point, tiret et tiret bas), et readValues(), qui navigue vers readvalue:// et, après 250 ms, analyse window.storedValues (iOS) ou window.appSettings (Android) ; en dehors de l'app, utilisez localStorage à la place. 2) Abonnez-vous à supabase.auth.onAuthStateChange et, sur SIGNED_IN et TOKEN_REFRESHED, écrivez rt=REFRESH_TOKEN avec theme et lang. 3) Au démarrage de l'app, si supabase.auth.getSession() ne renvoie aucune session, lisez les valeurs et, si rt existe, appelez supabase.auth.refreshSession({ refresh_token: rt }). 4) Après la connexion, lisez la variable globale uuid (naviguez une fois vers get-uuid:// si elle est undefined) et faites un upsert dans une table devices (user_id, uuid, platform, last_seen) avec RLS. 5) Ajoutez une liste Appareils connectés dans les réglages, avec Retirer. 6) À la déconnexion, réécrivez les valeurs sans rt. Ne déclenchez jamais deux schémas natifs dans le même tick.
Excellent travail! Je n'ai jamais codé quoi que ce soit, mais j'ai réussi à travailler avec cela. Facile et rapide! Avec une grande aide des créateurs!
Enregistrez un refresh token révocable après la connexion. Si la session web a disparu après un vidage du cache, relisez-le au lancement et restaurez la session en silence au lieu d'afficher l'écran de connexion.
Thème, langue, unités, « onboarding terminé », le dernier espace de travail ouvert : lus localement au lancement, avant même que votre backend ne réponde, et même hors ligne.
« Pro fonctionne sur deux appareils » : enregistrez l'UUID à l'activation, comptez les appareils actifs sur le serveur et proposez un écran Gérer les appareils pour libérer une place.
Passez le second facteur ou le code par e-mail sur un appareil que l'utilisateur a déjà confirmé, et affichez « Connecté sur : iPhone, Pixel » avec une déconnexion par appareil.
Un iPad d'accueil ou un téléphone scanner d'entrepôt qui doit toujours ouvrir le même site ou le même poste : enregistrez l'ID du poste par appareil.
Environ une heure, plus une table des appareils dans votre backend.
Définissez un user agent personnalisé dans Config.swift (useragent_iphone, useragent_ipad) et Config.java (USER_AGENT) et n'appelez les schémas que s'il correspond. Dans le navigateur, rabattez-vous sur localStorage.
Tout ce qui suit writevalue:// est enregistré tel quel comme une seule chaîne : utilisez donc un format simple key=value;key=value avec des valeurs compatibles avec les URL (lettres, chiffres, point, tiret, tiret bas). Chaque écriture remplace toute la chaîne : écrivez donc toujours toutes les clés.
Naviguez vers readvalue://, attendez un instant (la documentation utilise 200 ms) et analysez window.storedValues (iOS) ou window.appSettings (Android). Appliquez d'abord le thème et la langue, puis restaurez la session de connexion si nécessaire.
Après la connexion, lisez uuid (après get-uuid://, ou automatiquement avec l'option d'injection automatique) et enregistrez-le avec l'utilisateur dans Supabase ou Lovable Cloud (Postgres, stockage, edge functions) : ID utilisateur, UUID, plateforme, dernière activité. Appliquez les limites d'appareils sur le serveur, jamais dans le client.
À la déconnexion, réécrivez la valeur sans le token et révoquez-le sur le serveur. À la suppression du compte, supprimez aussi les lignes d'appareils (voir le guide de la suppression de compte).
iOS ne traite qu'une seule navigation vers un schéma par exécution de script : enchaînez les appels avec de courts délais (ou utilisez multiapicall://, qui prend en charge get-uuid) au lieu de les déclencher dans le même tick.
La même API dans l'app et dans le navigateur. Remplacez YourAppToken par votre user agent personnalisé.
var inApp = navigator.userAgent.indexOf("YourAppToken") !== -1;
function nativeWrite(values) { // { rt: "abc123", theme: "dark", lang: "fr" }
var str = Object.keys(values).map(function (k) { return k + "=" + (values[k] || ""); }).join(";");
if (!inApp) { try { localStorage.setItem("appValues", str); } catch (e) {} return; }
window.location.href = "writevalue://" + str;
}
function parseValues(str) {
var out = {};
String(str || "").split(";").forEach(function (pair) {
var i = pair.indexOf("=");
if (i > 0) out[pair.slice(0, i)] = pair.slice(i + 1);
});
return out;
}
function nativeRead(callback) {
if (!inApp) { callback(parseValues(localStorage.getItem("appValues"))); return; }
window.location.href = "readvalue://";
setTimeout(function () {
callback(parseValues(window.storedValues || window.appSettings)); // iOS || Android
}, 250);
}
function nativeDeviceId(callback) {
if (!inApp) { callback(null); return; }
if (typeof uuid !== "undefined") { callback(uuid); return; } // injecté automatiquement
window.location.href = "get-uuid://";
setTimeout(function () { callback(typeof uuid !== "undefined" ? uuid : null); }, 250);
}Utilisez-les d'abord ; dans l'app, ils persistent comme dans un navigateur. Le stockage de valeurs natif est la sauvegarde de ce qui doit survivre à un vidage du cache, comme un token d'appareil révocable, l'état de l'onboarding ou le choix de la langue, et il est disponible dès le lancement, même hors ligne.
Non. C'est un identifiant d'appareil non personnel destiné à la logique de votre propre app, pas l'IDFA ni l'identifiant publicitaire Android, et le lire n'affiche pas la demande App Tracking Transparency. Si vous l'utilisiez pour suivre les utilisateurs dans les apps d'autres entreprises ou le partagiez avec des régies publicitaires, cela deviendrait du suivi et les règles ATT s'appliqueraient.
Non. Les valeurs sont propres à chaque installation et à chaque appareil. Tout ce qui doit suivre l'utilisateur (profil, préférences, achats) a sa place dans votre backend ; le stockage de l'appareil accélère seulement le lancement et garde un appareil connecté.
Les valeurs enregistrées disparaissent avec la désinstallation, et ne partez pas non plus du principe que l'UUID reste le même. Laissez les utilisateurs se reconnecter, enregistrez à nouveau l'appareil et libérez les anciens appareils dans Supabase ou Lovable Cloud (Postgres, stockage, edge functions) après une période d'inactivité ou depuis un écran Gérer les appareils.
Seulement la solution de repli. Les schémas fonctionnent dans l'app WebViewGold, pas dans un navigateur de bureau ni dans un aperçu Lovable. Détectez le user agent personnalisé, utilisez le repli localStorage dans le navigateur et testez le vrai parcours sur un téléphone avec un build de l'app.
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.