Nach dem Launch
Das Beste an einer gewrappten Web-App: Die meisten Updates sind ein Deploy, keine Einreichung. Was gern vergessen wird, ist der Rest: Icons, Berechtigungen, native Features und die jährlichen Plattformvorgaben brauchen weiterhin einen Build. Hier sind die Aufteilung, die Versionsregeln und eine Release-Routine, die etwa eine Stunde dauert.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
| Änderung | Wie sie ausgeliefert wird | Hinweise |
|---|---|---|
| Neue Seiten, Features, Bugfixes, Designänderungen in der Web-App | Sofort: Deploy in Lovable, Bolt, Vercel oder bei deinem Hoster | Jede installierte App zeigt es beim nächsten Laden; kein Review |
| Texte, im Web angezeigte Preise, rechtliche Seiten | Sofort | Halte die Preise der In-App-Käufe in den Stores synchron mit dem, was die App anzeigt |
| App-Icon, App-Name, Splash Screen | Store-Update | Native Assets im Build |
| Ein natives Feature aktivieren (Push-Anbieter, Biometrie, QR-Scanner, AdMob, RevenueCat) | Store-Update | Ein Config-Schalter plus neuer Build; neue Berechtigungen werden geprüft |
| Neue Berechtigungstexte (Kamera, Standort, Fotos) | Store-Update | Aktualisiere auch die App-Datenschutz-Angaben und das Datensicherheitsformular, wenn sich die Datennutzung ändert |
| Start-URL oder Domain ändern | Store-Update | Vermeidbar, indem du die eigene Domain vor dem Launch festlegst |
| Update der WebViewGold-Vorlage (neues iOS SDK, Target API Level für Play, Privacy Manifests) | Store-Update | Kostenlose Updates; etwa einmal im Jahr nötig, damit die App veröffentlichbar bleibt |
| Text und Screenshots des Store-Eintrags | Kein Build, aber Review | App Store: Screenshots, Beschreibung und Keywords ändern sich nur mit einer neuen Version, Werbetext und URLs jederzeit. Play: Änderungen am Store-Eintrag jederzeit, mit Review |
iOS hat zwei Nummern: die Version (CFBundleShortVersionString, zum Beispiel 1.2.0), die Nutzer sehen, und die Build-Nummer (CFBundleVersion), die mit jedem Upload steigen muss, selbst bei derselben Version. Android hat versionName (freier Text, für Nutzer sichtbar) und versionCode, eine Ganzzahl, die mit jedem Upload in die Play Console steigen muss. Setze sie im General-Tab von Xcode und in build.gradle oder in den entsprechenden Feldern im Cloud Builder. Halte die sichtbare Version auf beiden Plattformen identisch und nutze major.minor.patch; das macht Support-Gespräche („Welche Version hast du?“) schmerzlos.
Deine Web-App hat ihren eigenen Release-Rhythmus, und die beiden können an einer wichtigen Stelle auseinanderlaufen: Ein Web-Feature, das eine native Fähigkeit braucht (etwa ein neuer QR-Ablauf), funktioniert nicht in App-Versionen, die gebaut wurden, bevor die Fähigkeit aktiviert war. Die App Version Check API von WebViewGold löst das: Navigiere zu getappversion://, und die App setzt window.versionNumber und window.bundleNumber (oder setze autoInjectVariable / AUTO_INJECT_VARIABLES auf true, damit sie auf jeder Seite injiziert werden). Deine Web-App kann das Feature dann ausblenden oder älteren Installationen ein Update-Banner zeigen. Doku: App Version Check (iOS) und Android.
Läuft bei jedem Seitenaufruf in der App. Vergleiche mit der niedrigsten Version, die die aktuelle Web-App unterstützt.
const inApp = /WebViewGoldApp/.test(navigator.userAgent);
const MIN_APP_VERSION = "1.3.0";
function olderThan(a, b) { // "1.2.9" < "1.3.0"
const pa = a.split(".").map(Number), pb = b.split(".").map(Number);
for (let i = 0; i < 3; i++) { if ((pa[i] || 0) !== (pb[i] || 0)) return (pa[i] || 0) < (pb[i] || 0); }
return false;
}
if (inApp) {
window.location.href = "getappversion://"; // WebViewGold setzt window.versionNumber
setTimeout(() => {
if (window.versionNumber && olderThan(String(window.versionNumber), MIN_APP_VERSION)) {
document.getElementById("update-banner").hidden = false; // "Eine neue Version ist verfügbar" + Store-Link
}
}, 800);
}
Ich bin sehr glücklich, dass ich diese App gekauft habe! Extrem einfach und großartige Dokumentation. Ich stand in Kontakt mit dem Kundenservice, sie antworteten sehr schnell und sehr freundlich. Sie lösten meine Frage innerhalb eines Tages. 10/10 würde ich empfehlen.
Etwa eine Stunde Arbeit plus Review-Zeit. Führe sie immer dann durch, wenn in der Tabelle oben „Store-Update“ steht.
Lade die aktuelle Version herunter (Updates sind kostenlos) und übernimm dann deine Werte aus Config.swift und Config.java, Icon, Splash, GoogleService-Info.plist oder google-services.json und alle eigenen Berechtigungstexte. Dein Android-Keystore und der Upload-Key bleiben gleich. Wer den Cloud Builder nutzt, überspringt diesen Schritt: Der Dienst baut mit der gepflegten Vorlage.
Version 1.2.0 → 1.3.0, Build-Nummer +1, versionCode +1.
Xcode → Product → Archive → Distribute an App Store Connect; Android Studio → Build → Generate Signed Bundle → in die Play Console hochladen. Oder ein Klick im Cloud Builder für beide.
Interner TestFlight-Test und interner Play-Track: Login, Push-Berechtigung, Offline-Bildschirm, ein Deep Link aus einer E-Mail, ein Kauf in der Sandbox, falls du etwas verkaufst. Fünfzehn Minuten auf einem echten Smartphone; siehe den Test-Guide.
Apple: Wähle die phasenweise Veröffentlichung (sieben Tage, automatisch steigender Anteil, pausierbar) oder die manuelle Veröffentlichung nach der Freigabe. Google: gestaffelter Rollout; starte mit 10 bis 20 Prozent und erhöhe über ein paar Tage, und stoppe, wenn die Vitals in der Play Console einen Anstieg bei Abstürzen zeigen.
Abstürze und Rezensionen in App Store Connect, Vitals und Richtlinien-E-Mails in der Play Console. Fixes auf der Web-Seite gehen weiterhin sofort live, während der native Build ausgerollt wird.
splashTimeout oder aktiviere remainSplashOption.Neue Apps und Updates müssen bis zu Googles jährlicher Frist eine aktuelle Android-Version als Ziel haben. Eine alte Vorlage lässt sich nach diesem Datum nicht mehr hochladen; der Guide zum Target API Level erklärt den Zeitplan.
Uploads müssen mit einem aktuellen Xcode und iOS SDK gebaut sein, und iOS-Apps enthalten inzwischen Privacy Manifests. Vorlagen-Updates bringen beides mit.
Updates ergänzen APIs (Dokumentenscanner, Gesundheitsdaten, Widgets), die du deiner Web-App mit jeweils einem Link zugänglich machen kannst.
Auch ohne Änderungen hält ein Rebuild mit der aktuellen Vorlage einmal im Jahr die App veröffentlichbar und das Datum „Aktualisiert“ frisch für ASO.
Nein. Ein Review gibt es nur, wenn du einen neuen Build einreichst oder Metadaten des Store-Eintrags änderst. Inhalte in der Web-App darfst du selbst ändern, solange die App weiterhin zu ihrem Store-Eintrag und den Richtlinien passt.
Mindestens einmal im Jahr wegen der Plattformvorgaben, dazu immer dann, wenn du ein Icon, ein natives Feature oder eine Berechtigung änderst. Viele Teams pendeln sich auf ein Store-Update alle ein bis zwei Monate ein.
Nicht technisch erzwingen, aber mit dem Versions-Check kannst du alte App-Versionen hinter einer Meldung mit Store-Link sperren, wenn eine Backend-Änderung das erfordert.
Nein. Cookies und localStorage überstehen Updates, solange die Optionen zum Leeren des Caches in den Config-Dateien nicht aktiviert sind.
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.