Claude Code + 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 Claude Code 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 Vos propres routes API, des fonctions serverless ou Supabase et ne considérez jamais l'UUID comme une preuve d'identité.
Collez ceci dans Claude Code pour implémenter la partie app web. Vérifiez le résultat, publiez, puis testez dans l'app WebViewGold.
Prompt pour Claude Code : Lisez les sections UUID et Read/Write Value de https://www.webviewgold.com/llms-full.txt ainsi que https://www.webviewgold.com/docs/iOS/read-write-value/, puis : 1) Créez un module de stockage natif avec write(values), read() et deviceId(), qui ne fonctionne que lorsque navigator.userAgent contient mon token WebViewGold personnalisé et se rabat sur localStorage dans les navigateurs ; read() doit vérifier window.storedValues (iOS) et window.appSettings (Android). 2) Utilisez un format key=value;key=value avec uniquement des valeurs compatibles avec les URL, et écrivez toujours toutes les clés. 3) Conservez le thème, la langue et l'état de l'onboarding, et restaurez-les au démarrage. 4) Après la connexion, enregistrez deviceId avec l'utilisateur dans notre backend et ajoutez un écran Appareils connectés avec Retirer. 5) Effacez les tokens enregistrés à la déconnexion et supprimez les lignes d'appareils quand un compte est supprimé. 6) Écrivez des tests. 7) Produisez un court rapport de confidentialité : où l'ID d'appareil est stocké et envoyé, et les réponses correspondantes dans App Privacy (Device ID) et dans le formulaire Sécurité des données de Google Play (Device or other IDs).
Mon WebView iOS est enfin approuvé. Merci !!
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 Vos propres routes API, des fonctions serverless ou Supabase : 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 Vos propres routes API, des fonctions serverless ou Supabase 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 Claude Code. 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.