Cursor + safe area
A Cursor app that looked perfect in the browser can lose its header under the Dynamic Island, its tab bar under the home indicator, or its clock to white-on-white in dark mode. WebViewGold keeps your page inside the safe area by default and colors the status bar natively or from JavaScript. Here is when to rely on that and when to go edge-to-edge with CSS.
From $109 one-time per platform, or let our team do it all from $698.
On iOS autoAdjustSafeAreaInsets is on, so the WebView starts below the status bar, notch or Dynamic Island. The bar takes statusBarBackgroundColor and statusBarTextColor (white or black), with darkModeStatusBarBackgroundColor and darkModeStatusBarTextColor for dark mode. On Android the color comes from colorPrimaryDark in style.xml and the text from blackStatusBarText.
For a full-bleed hero image, map or video, set transparentStatusBar to true and autoAdjustSafeAreaInsets to false on iOS, or TRANSPARENT_STATUS_BAR on Android. From then on your CSS owns the insets: viewport-fit=cover plus env(safe-area-inset-*) on every fixed element.
Bottom bars built in CSS often sit under the iPhone home indicator. Pad them with env(safe-area-inset-bottom), or let WebViewGold add a native strip below the page with bottombar and bottombarBackgroundColor (iPadBottombar for iPads, safe area docs).
Google Play now requires new apps and updates to target Android 16 (API level 36), where apps can no longer opt out of edge-to-edge: the window extends behind the status and navigation bars and the app must handle the insets. The WebViewGold template keeps up with these platform changes (updates are free), so build from the current version and test the gesture bar area on a real phone.
Paste this into Cursor to implement the web-app side. Review the result, publish, then test inside the WebViewGold app.
This web app runs inside the WebViewGold native wrapper (its user agent contains "WebViewGold") with a transparent status bar. 1. Search the codebase for position: fixed, sticky top-0, bottom-0, h-screen and 100vh. 2. For every element that touches a screen edge, add the matching padding with a fallback, for example padding-top: max(12px, env(safe-area-inset-top)) and padding-bottom: max(8px, env(safe-area-inset-bottom)); replace 100vh with 100dvh. 3. Add viewport-fit=cover to the viewport meta tag. 4. Scope these rules to an in-app class on the html element that is set when navigator.userAgent contains "WebViewGold". 5. Add setStatusBar(r, g, b) to the WebViewGold bridge module (statusbarcolor://r,g,b, deduplicated, app only) and call it on route changes. 6. List every file and selector you changed and note the edge-to-edge decision in .cursor/rules.
My iOS WebView is finally approved. Thanks!!
| Symptom | iOS (Config.swift) | Android (Config.java, style.xml) | From your web app |
|---|---|---|---|
| Header hidden under the notch or Dynamic Island | Keep autoAdjustSafeAreaInsets on (default) | Keep TRANSPARENT_STATUS_BAR off | Only when edge-to-edge: padding-top: env(safe-area-inset-top) |
| White status bar above a dark header | statusBarBackgroundColor = header color | colorPrimaryDark = header color | statusbarcolor://R,G,B per page |
| Clock and battery unreadable in dark mode | darkModeStatusBarBackgroundColor, darkModeStatusBarTextColor | blackStatusBarText; statusbartextcolor://white at runtime | prefers-color-scheme; on Android also the injected isDarkMode variable |
| Tab bar under the home indicator or gesture bar | bottombar + bottombarBackgroundColor | Navigation bar color via bottombarcolor://, text via navbartextcolor:// | padding-bottom: env(safe-area-inset-bottom) |
| Full-screen video, game or photo viewer | hidebars://on: the status bar background turns transparent, the clock stays | hidebars://on: status and navigation bars hide; a swipe from the top brings them back | hidebars://off when the user leaves the screen |
Screens in a Cursor app often have different header colors (a dark landing hero, a white settings page). Set the bar per route; statusbarcolor:// is the master command that also picks a readable text color and adjusts the iOS bottom bar or the Android navigation bar. iOS handles one bridge call per script run, so send only this one:
const inApp = navigator.userAgent.includes("WebViewGold"); // your custom 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 per screen (convert hex, hsl or oklch theme colors once)
const BAR_COLORS = {
"/": [15, 23, 42], // dark hero
"/settings": [255, 255, 255],
};
// call after the first render and after every client-side route change
function onRouteChange(path) {
const c = BAR_COLORS[path] || [255, 255, 255];
setStatusBar(c[0], c[1], c[2]);
}Only if your design needs content behind the status bar; otherwise keep the defaults.
iOS: transparentStatusBar = true and autoAdjustSafeAreaInsets = false. Android: TRANSPARENT_STATUS_BAR = true. This is a native change and needs a new build.
In the viewport meta tag of your Cursor app (or your framework's viewport setting): width=device-width, initial-scale=1, viewport-fit=cover. Without it the env() values stay at zero on iOS.
Headers get padding-top: max(12px, env(safe-area-inset-top)), bottom bars padding-bottom: max(8px, env(safe-area-inset-bottom)), and elements anchored to the sides the left and right insets for landscape. Toasts, sheets and modals positioned at top: 0 are the ones people forget.
What env(safe-area-inset-*) reports can differ between Android WebView versions, so do not rely on it alone: test the transparent status bar on a recent phone with gesture navigation and keep the max() fallbacks above.
An iPhone with Dynamic Island, the smallest iPhone you can find, an iPad in landscape and an Android phone with gesture navigation, each in light and dark mode. Reviewers use these devices and screenshot any overlap under Guideline 4.0 (fixing a 4.0 design rejection).
Yes, by default. On iOS autoAdjustSafeAreaInsets keeps the page below the status bar area on every device shape, and the bar shows the color you configured. You only handle insets in CSS when you deliberately switch to a transparent status bar.
Yes. Navigate to statusbarcolor://R,G,B from JavaScript (for example statusbarcolor://15,23,42) and WebViewGold recolors the status bar, picks white or black text and adjusts the iOS bottom bar or Android navigation bar. statusbartextcolor://white or statusbartextcolor://black sets the text explicitly.
Either the viewport meta tag lacks viewport-fit=cover, or WebViewGold still places the page inside the safe area (the default), in which case 0 is correct and nothing overlaps. With transparentStatusBar on and autoAdjustSafeAreaInsets off, the values become real.
On iOS set darkModeStatusBarBackgroundColor and darkModeStatusBarTextColor in Config.swift. On Android WebViewGold injects the JavaScript variable isDarkMode, so your page can call statusbarcolor:// with the right color; prefers-color-scheme works in CSS on both platforms.
It can be. Content under the status bar, controls hidden by the home indicator and clipped modals are typical Guideline 4.0 design findings, and they make the app look like a website squeezed into a phone, which feeds a 4.2 discussion as well.
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main page$349 per license, one-time add-on
No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.
How the Cloud Builder works Try the free demo$698 per platform $798
Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.
Full Service details Powered by
Winter Sale prices valid until December 31, 2026.
App Store & Google Play approval guarantee – or your money back within 14 days
Rather hand it over? Full Service: we configure, build and deliver within 72 hours, from $698 per platform. Questions? Chat with us 24/7.
Refunds are granted under the conditions listed in our FAQ: a non-content rejection by Apple and/or Google, claimed within 14 days after purchase.