Lovable + Safe Area
Eine Lovable-App, die im Browser perfekt aussah, kann ihren Header unter der Dynamic Island verlieren, ihre Tab-Leiste unter dem Home-Indikator oder ihre Uhrzeit an Weiß auf Weiß im Dunkelmodus. WebViewGold hält deine Seite standardmäßig innerhalb der Safe Area und färbt die Statusleiste nativ oder per JavaScript. Hier erfährst du, wann du dich darauf verlässt und wann du per CSS auf Edge-to-Edge gehst.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Auf iOS ist autoAdjustSafeAreaInsets eingeschaltet, also beginnt die WebView unterhalb von Statusleiste, Notch oder Dynamic Island. Die Leiste übernimmt statusBarBackgroundColor und statusBarTextColor (weiß oder schwarz), mit darkModeStatusBarBackgroundColor und darkModeStatusBarTextColor für den Dunkelmodus. Auf Android kommt die Farbe aus colorPrimaryDark in style.xml und die Textfarbe aus blackStatusBarText.
Für ein randloses Hero-Bild, eine Karte oder ein Video setzt du auf iOS transparentStatusBar auf true und autoAdjustSafeAreaInsets auf false, auf Android TRANSPARENT_STATUS_BAR. Ab dann kümmert sich dein CSS um die Insets: viewport-fit=cover plus env(safe-area-inset-*) an jedem fixierten Element.
In CSS gebaute Leisten am unteren Rand sitzen oft unter dem Home-Indikator des iPhones. Gib ihnen Padding mit env(safe-area-inset-bottom) oder lass WebViewGold mit bottombar und bottombarBackgroundColor einen nativen Streifen unter der Seite ergänzen (iPadBottombar für iPads, Safe-Area-Doku).
Google Play verlangt inzwischen, dass neue Apps und Updates auf Android 16 (API-Level 36) zielen, wo Apps Edge-to-Edge nicht mehr abwählen können: Das Fenster reicht hinter Status- und Navigationsleiste, und die App muss die Insets selbst behandeln. Das WebViewGold-Template hält mit diesen Plattformänderungen Schritt (Updates sind kostenlos), also bau aus der aktuellen Version und teste den Bereich der Gestenleiste auf einem echten Smartphone.
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.
Diese App läuft in einem nativen Wrapper (WebViewGold), dessen User Agent "WebViewGold" enthält. 1. Füge viewport-fit=cover zum Viewport-Meta-Tag in index.html hinzu. 2. Gib fixierten Leisten, Sheets und Drawern am unteren Rand ein unteres Safe-Area-Padding (pb-[env(safe-area-inset-bottom)]) und oben fixierten Elementen, auch Toasts, ein oberes Padding (pt-[env(safe-area-inset-top)]). 3. Erstelle eine Hilfsfunktion setStatusBar(r, g, b), die nur dann, wenn navigator.userAgent "WebViewGold" enthält, zu statusbarcolor://r,g,b navigiert und den Aufruf überspringt, wenn sich die Farbe nicht geändert hat. 4. Ruf sie nach dem ersten Rendern und bei jedem Wechsel zwischen hellem und dunklem Theme mit der Hintergrundfarbe des Headers auf. 5. Stell sicher, dass auf einem 320 px breiten Bildschirm nichts horizontal scrollt. 6. Nenn mir die Hintergrundfarben des Headers für Hell- und Dunkelmodus als Hex-Werte für die nativen Statusleisten-Einstellungen.
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 :-)
| Symptom | iOS (Config.swift) | Android (Config.java, style.xml) | Aus deiner Web-App |
|---|---|---|---|
| Header unter Notch oder Dynamic Island verborgen | autoAdjustSafeAreaInsets eingeschaltet lassen (Standard) | TRANSPARENT_STATUS_BAR ausgeschaltet lassen | Nur bei Edge-to-Edge: padding-top: env(safe-area-inset-top) |
| Weiße Statusleiste über einem dunklen Header | statusBarBackgroundColor = Header-Farbe | colorPrimaryDark = Header-Farbe | statusbarcolor://R,G,B pro Seite |
| Uhrzeit und Akku im Dunkelmodus unlesbar | darkModeStatusBarBackgroundColor, darkModeStatusBarTextColor | blackStatusBarText; statusbartextcolor://white zur Laufzeit | prefers-color-scheme; auf Android zusätzlich die injizierte Variable isDarkMode |
| Tab-Leiste unter Home-Indikator oder Gestenleiste | bottombar + bottombarBackgroundColor | Farbe der Navigationsleiste über bottombarcolor://, Text über navbartextcolor:// | padding-bottom: env(safe-area-inset-bottom) |
| Vollbild-Video, Spiel oder Fotobetrachter | hidebars://on: Der Hintergrund der Statusleiste wird transparent, die Uhrzeit bleibt | hidebars://on: Status- und Navigationsleiste verschwinden; ein Wischen von oben holt sie zurück | hidebars://off, wenn der Nutzer den Bildschirm verlässt |
Bildschirme einer Lovable-App haben oft unterschiedliche Header-Farben (ein dunkles Hero auf der Startseite, eine weiße Einstellungsseite). Setz die Leiste pro Route; statusbarcolor:// ist der Master-Befehl, der zusätzlich eine lesbare Textfarbe wählt und die iOS-Bottom-Bar oder die Android-Navigationsleiste anpasst. iOS verarbeitet pro Skriptdurchlauf einen Bridge-Aufruf, also schick nur diesen einen:
const inApp = navigator.userAgent.includes("WebViewGold"); // dein eigenes User-Agent-Token
let lastColor = "";
function setStatusBar(r, g, b) {
const color = r + "," + g + "," + b;
if (!inApp || color === lastColor) return;
lastColor = color;
window.location.href = "statusbarcolor://" + color;
}
// RGB pro Bildschirm (Hex-, HSL- oder OKLCH-Farben des Themes einmal umrechnen)
const BAR_COLORS = {
"/": [15, 23, 42], // dunkles Hero
"/settings": [255, 255, 255],
};
// nach dem ersten Rendern und nach jedem clientseitigen Routenwechsel aufrufen
function onRouteChange(path) {
const c = BAR_COLORS[path] || [255, 255, 255];
setStatusBar(c[0], c[1], c[2]);
}Nur wenn dein Design Inhalt hinter der Statusleiste braucht; sonst bleib bei den Standardwerten.
iOS: transparentStatusBar = true und autoAdjustSafeAreaInsets = false. Android: TRANSPARENT_STATUS_BAR = true. Das ist eine native Änderung und braucht einen neuen Build.
Im Viewport-Meta-Tag deiner Lovable-App (oder in der Viewport-Einstellung deines Frameworks): width=device-width, initial-scale=1, viewport-fit=cover. Ohne das bleiben die env()-Werte auf iOS bei null.
Header bekommen padding-top: max(12px, env(safe-area-inset-top)), Leisten unten padding-bottom: max(8px, env(safe-area-inset-bottom)), und seitlich verankerte Elemente die Insets links und rechts für das Querformat. Toasts, Sheets und Modals mit top: 0 sind die, die man gern vergisst.
Was env(safe-area-inset-*) liefert, kann sich zwischen Versionen der Android-WebView unterscheiden, also verlass dich nicht allein darauf: Teste die transparente Statusleiste auf einem aktuellen Smartphone mit Gestennavigation und behalte die max()-Fallbacks von oben.
Ein iPhone mit Dynamic Island, das kleinste iPhone, das du finden kannst, ein iPad im Querformat und ein Android-Smartphone mit Gestennavigation, jeweils im Hell- und Dunkelmodus. Reviewer nutzen genau diese Geräte und dokumentieren jede Überlappung per Screenshot unter Guideline 4.0 (eine Design-Ablehnung nach 4.0 beheben).
Ja, standardmäßig. Auf iOS hält autoAdjustSafeAreaInsets die Seite auf jeder Geräteform unterhalb der Statusleiste, und die Leiste zeigt die Farbe, die du konfiguriert hast. Um Insets in CSS kümmerst du dich nur, wenn du bewusst auf eine transparente Statusleiste umstellst.
Ja. Navigiere per JavaScript zu statusbarcolor://R,G,B (zum Beispiel statusbarcolor://15,23,42), und WebViewGold färbt die Statusleiste neu, wählt weißen oder schwarzen Text und passt die iOS-Bottom-Bar oder die Android-Navigationsleiste an. statusbartextcolor://white oder statusbartextcolor://black legt die Textfarbe explizit fest.
Entweder fehlt im Viewport-Meta-Tag viewport-fit=cover, oder WebViewGold platziert die Seite noch innerhalb der Safe Area (der Standard); dann ist 0 korrekt, und nichts überlappt. Mit eingeschaltetem transparentStatusBar und ausgeschaltetem autoAdjustSafeAreaInsets werden die Werte real.
Auf iOS setzt du darkModeStatusBarBackgroundColor und darkModeStatusBarTextColor in Config.swift. Auf Android injiziert WebViewGold die JavaScript-Variable isDarkMode, sodass deine Seite statusbarcolor:// mit der richtigen Farbe aufrufen kann; prefers-color-scheme funktioniert im CSS auf beiden Plattformen.
Das kann sie sein. Inhalt unter der Statusleiste, vom Home-Indikator verdeckte Bedienelemente und abgeschnittene Modals sind typische Design-Befunde nach Guideline 4.0, und sie lassen die App wie eine in ein Smartphone gequetschte Website wirken, was auch eine Diskussion um 4.2 befeuert.
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.