Replit + Gerätespeicher
Nutzer erwarten, dass sich eine App an sie erinnert. Cookies und localStorage halten deine Replit-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 Express-/Flask-/FastAPI-Backends mit Replit Postgres oder externen Datenbanken und betrachte die UUID nie als Identitätsnachweis.
Füge das in Replit ein, um die Web-App-Seite umzusetzen. Prüfe das Ergebnis, veröffentliche und teste dann in der WebViewGold-App.
Mach diese Replit-App gerätebewusst für den nativen Wrapper WebViewGold. Erstelle im Frontend einen Helper, der nur dann, wenn navigator.userAgent mein WebViewGold-Token enthält, die globale Variable uuid liest (einmal zu get-uuid:// navigieren, falls sie undefined ist) und sie nach dem Replit-Auth-Login zusammen mit der Plattform per POST an /api/devices schickt. Ergänze im Backend eine Tabelle devices in Postgres (user_id, device_uuid, platform, first_seen, last_seen), schreib bei diesem Aufruf per Upsert hinein und füge GET /api/devices und DELETE /api/devices/:id für einen Bildschirm „Geräte verwalten“ hinzu. Setz auf dem Server als weiches Limit eine kostenlose Testphase pro device_uuid durch. Lass das Session-Cookie 30 Tage mit fortlaufender Verlängerung gelten. Füge einen Helper für Einstellungen hinzu, der Theme, Einheiten und Onboarding-Status mit writevalue://theme=dark;units=metric;onboarded=1 speichert und sie beim Start mit readvalue:// wiederherstellt (nach 250 ms window.storedValues auf iOS oder window.appSettings auf Android parsen), mit localStorage als Fallback in Browsern.
Mit einer gut optimierten Version Ihrer Web-App können Sie innerhalb von wenigen Minuten eine beeindruckende mobile App erstellen. Zusätzlich dazu ist der Kundenservice sehr nett und hilfsbereit! Ich kann WebViewGold nur empfehlen :-)
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 Express-/Flask-/FastAPI-Backends mit Replit Postgres oder externen Datenbanken: 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 Express-/Flask-/FastAPI-Backends mit Replit Postgres oder externen Datenbanken 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 Replit-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.