Lovable + Gerätespeicher
Nutzer erwarten, dass sich eine App an sie erinnert. Cookies und localStorage halten deine Lovable-App meist eingeloggt, sind aber Web-Speicher und verschwinden mit dem Cache. WebViewGold ergänzt zwei kleine native Helfer: einen dauerhaften Wertespeicher (writevalue:// und readvalue://) für Einstellungen und das Wiederherstellen der Session sowie eine Geräte-UUID (get-uuid://) für gerätegebundene Lizenzen, vertrauenswürdige Geräte und Einstellungen pro Gerät auf deinem Server.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
writevalue:// speichert alles nach dem Schema als einen einzigen String im privaten Speicher der App; readvalue:// injiziert ihn wieder in die Seite, als window.storedValues auf iOS und window.appSettings auf Android. Die Werte überstehen Neustarts und das Leeren des Caches und verschwinden, wenn die App deinstalliert wird (auf Android auch, wenn ihre App-Daten gelöscht werden).
get-uuid:// setzt die JavaScript-Variable uuid, eine nicht personenbezogene, eindeutige Geräte-ID. Alternativ hängst du sie einmal als ?uuid=XYZ an die erste Anfrage an (enhanceUrlUUID / UUID_ENHANCE_WEBVIEW_URL) oder injizierst sie auf jeder Seite (autoInjectVariable / AUTO_INJECT_VARIABLES).
Nicht über Geräte synchronisiert, keine Datenbank, kein Passwort-Tresor. Halte die Werte klein (Einstellungen, Flags, ein widerrufbares Token), lass Nutzerdaten in Supabase oder Lovable Cloud (Postgres, Storage, Edge Functions) und betrachte die UUID nie als Identitätsnachweis.
Füge das in Lovable ein, um die Web-App-Seite umzusetzen. Prüfe das Ergebnis, veröffentliche und teste dann in der WebViewGold-App.
Füge native Persistenz für den App-Wrapper WebViewGold hinzu. 1) Erstelle src/lib/nativeStore.ts mit inApp() (navigator.userAgent enthält mein WebViewGold-Token), writeValues(obj), das zu writevalue:// navigiert, gefolgt von key=value-Paaren, die mit Semikolons verbunden sind (Werte nur aus Buchstaben, Ziffern, Punkt, Bindestrich und Unterstrich), und readValues(), das zu readvalue:// navigiert und nach 250 ms window.storedValues (iOS) oder window.appSettings (Android) parst; außerhalb der App nutzt du stattdessen localStorage. 2) Abonniere supabase.auth.onAuthStateChange und schreib bei SIGNED_IN und TOKEN_REFRESHED rt=REFRESH_TOKEN zusammen mit theme und lang. 3) Wenn supabase.auth.getSession() beim App-Start keine Session liefert, lies die Werte und ruf, falls rt existiert, supabase.auth.refreshSession({ refresh_token: rt }) auf. 4) Lies nach dem Login die globale Variable uuid (navigiere einmal zu get-uuid://, falls sie undefined ist) und füge sie per Upsert in eine Tabelle devices (user_id, uuid, platform, last_seen) mit RLS ein. 5) Füge in den Einstellungen eine Liste „Angemeldete Geräte“ mit Entfernen hinzu. 6) Schreib die Werte beim Logout ohne rt neu. Löse nie zwei native Schemes im selben Tick aus.
Großartige Arbeit! Ich habe noch nie etwas programmiert, aber ich konnte damit arbeiten. Einfach und schnell! Auch mit großartiger Hilfe von den Erstellern!
Schreib nach dem Login ein widerrufbares Refresh-Token. Ist die Web-Session nach dem Leeren des Caches weg, liest du es beim Start zurück und stellst die Session unbemerkt wieder her, statt den Login-Bildschirm zu zeigen.
Theme, Sprache, Einheiten, „Onboarding erledigt“, der zuletzt geöffnete Workspace: beim Start lokal gelesen, bevor dein Backend antwortet, und sogar offline.
„Pro läuft auf zwei Geräten“: Registriere die UUID bei der Aktivierung, zähle die aktiven Geräte auf dem Server und biete einen Bildschirm „Geräte verwalten“ an, um einen Platz freizugeben.
Überspring den zweiten Faktor oder den E-Mail-Code auf einem Gerät, das der Nutzer bereits bestätigt hat, und zeig „Angemeldet auf: iPhone, Pixel“ mit einer Abmeldung pro Gerät.
Ein iPad am Empfang oder ein Scanner-Smartphone im Lager, das immer denselben Standort oder dieselbe Station öffnen soll: Speichere die Stations-ID pro Gerät.
Rund eine Stunde, plus eine Geräte-Tabelle in deinem Backend.
Leg einen eigenen User Agent in Config.swift (useragent_iphone, useragent_ipad) und Config.java (USER_AGENT) fest und ruf die Schemes nur auf, wenn er passt. Im Browser greifst du auf localStorage zurück.
Alles nach writevalue:// wird unverändert als ein String gespeichert, nutze also ein einfaches Format key=value;key=value mit URL-sicheren Werten (Buchstaben, Ziffern, Punkt, Bindestrich, Unterstrich). Jeder Schreibvorgang ersetzt den ganzen String, schreib also immer alle Keys.
Navigiere zu readvalue://, warte einen Moment (die Doku nutzt 200 ms) und parse window.storedValues (iOS) oder window.appSettings (Android). Wende zuerst Theme und Sprache an und stell dann bei Bedarf die Login-Session wieder her.
Lies nach dem Login uuid aus (nach get-uuid:// oder automatisch mit der Auto-Inject-Option) und speichere sie beim Nutzer in Supabase oder Lovable Cloud (Postgres, Storage, Edge Functions): User-ID, UUID, Plattform, zuletzt gesehen. Setz Gerätelimits auf dem Server durch, nie im Client.
Schreib den Wert beim Logout ohne das Token neu und widerrufe es auf dem Server. Bei der Kontolöschung löschst du auch die Gerätezeilen (Guide zur Kontolöschung).
iOS verarbeitet pro Skriptdurchlauf nur eine Schema-Navigation, verkette Aufrufe also mit kurzen Verzögerungen (oder nutze multiapicall://, das get-uuid unterstützt), statt sie im selben Tick abzufeuern.
Dieselbe API in der App und im Browser. Ersetze YourAppToken durch deinen eigenen User Agent.
var inApp = navigator.userAgent.indexOf("YourAppToken") !== -1;
function nativeWrite(values) { // { rt: "abc123", theme: "dark", lang: "de" }
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; } // automatisch injiziert
window.location.href = "get-uuid://";
setTimeout(function () { callback(typeof uuid !== "undefined" ? uuid : null); }, 250);
}Nutze sie zuerst; in der App bleiben sie so erhalten wie in einem Browser. Der native Wertespeicher ist das Backup für alles, was das Leeren des Caches überstehen muss, etwa ein widerrufbares Geräte-Token, der Onboarding-Status oder die Sprachwahl, und er steht beim Start zur Verfügung, sogar offline.
Nein. Sie ist eine nicht personenbezogene Gerätekennung für deine eigene App-Logik, nicht die IDFA oder die Android-Werbe-ID, und das Auslesen löst keine ATT-Abfrage aus. Würdest du sie nutzen, um Nutzer über Apps anderer Unternehmen hinweg zu verfolgen, oder sie an Werbenetzwerke weitergeben, wäre das Tracking, und die ATT-Regeln würden gelten.
Nein. Die Werte gelten pro Installation und pro Gerät. Alles, was dem Nutzer folgen soll (Profil, Einstellungen, Käufe), gehört in dein Backend; der Gerätespeicher beschleunigt nur den Start und hält ein Gerät eingeloggt.
Gespeicherte Werte sind nach einer Deinstallation weg, und du solltest auch nicht davon ausgehen, dass die UUID gleich bleibt. Lass Nutzer sich neu anmelden, registriere das Gerät neu und gib alte Geräte in Supabase oder Lovable Cloud (Postgres, Storage, Edge Functions) nach einer Zeit der Inaktivität oder über einen Bildschirm „Geräte verwalten“ frei.
Nur den Fallback. Die Schemes funktionieren in der WebViewGold-App, nicht in einem Desktop-Browser oder einer Lovable-Vorschau. Erkenne den eigenen User Agent, nutze im Browser den localStorage-Fallback und teste den echten Ablauf auf einem Smartphone mit einem Build der App.
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
$109 pro Plattform, einmalig
Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.
Pakete auf der Hauptseite ansehen$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobieren$698 pro Plattform $798
Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.
Full-Service-Details Powered by
Winter-Sale-Preise gültig bis 31. Dezember 2026.
App Store & Google Play Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
Lieber abgeben? Full Service: Wir konfigurieren, bauen und liefern innerhalb von 72 Stunden, ab $698 pro Plattform. Fragen? Chatte mit uns – 24/7.
Erstattungen erfolgen zu den in unseren FAQ genannten Bedingungen: eine nicht inhaltsbedingte Ablehnung durch Apple und/oder Google, geltend gemacht innerhalb von 14 Tagen nach dem Kauf.