Pull-to-Refresh, Status Bar & Safe Areas: Native Touches That Sell a WebView App

Nobody opens an app and thinks "nice safe-area handling." They think "this feels cheap" — and then they leave. The gap between a WebView app that feels native and one that feels like a bookmark is four or five small details, none of which require touching your website's code.

Pull down and nothing happens. A grey status bar clashing with your brand. Your logo half-hidden under the notch. A bottom tab bar sitting under the home indicator. Each is a two-minute fix, and together they are the whole difference.

Why Does My WebView App Feel Like a Website?

A WebView app feels like a website when it skips the native shell conventions users expect — pull-to-refresh, a themed status bar, and content that respects the notch and home indicator. These are shell-level settings, not website changes.

Two of those five live in the native shell and three live in CSS. That split matters: if you are having an app built for you, the shell items are the builder's job, and the CSS items are yours. AppOfWeb includes pull-to-refresh and status bar customisation in every paid tier, so the shell half is handled — but the safe-area CSS is on your site, and this guide covers both. If you are new to how the wrapper works at all, start with what a WebView app actually is.

How Do You Add Pull-to-Refresh to a WebView App?

Pull-to-refresh is added in the native shell, not in your website — Android wraps the WebView in a SwipeRefreshLayout, and iOS attaches a UIRefreshControl to the WKWebView's scroll view. Neither requires a line of JavaScript on your site.

The implementation is short on both platforms, but there is one condition that catches almost everyone:

The condition is the whole trick. If pull-to-refresh is always enabled, then every time a user swipes down mid-article to scroll up, the page reloads instead. That is worse than having no pull-to-refresh at all, because it destroys their scroll position without being asked. Gate the gesture on the WebView's vertical scroll position being zero, and the problem disappears.

One more decision worth making deliberately: what "refresh" should actually do. Reloading the current URL is the obvious choice and is almost always right. Sending the user back to the home page is not — it looks like a crash. And if your site is a single-page app that manages its own history, a full reload may throw away in-page state, so test the gesture against your real routes rather than just the landing page.

How Do You Change the Status Bar Colour in a WebView App?

The status bar is controlled by the native shell, and the theme-color meta tag on your website does not control it inside a WKWebView or an Android WebView. That meta tag works in mobile browsers, which is exactly why people assume it will work here.

There are two separate things to set, and getting one without the other is the usual half-finished result:

• The background colour behind the status bar. This should match your site's header, not sit as a grey or black strip above it.
• The colour of the icons in it — the clock, battery and signal. These are only ever light or dark, and picking the wrong one makes them vanish against your header. A dark header needs light icons; a light header needs dark icons.

That second point is the one that gets shipped broken. A brand with a white header and light status bar icons has an invisible clock and battery indicator, and it looks like a rendering bug rather than a choice.

What Are Safe Areas, and Why Is My Content Under the Notch?

The safe area is the part of the screen not covered by the notch, the Dynamic Island, the rounded corners or the home indicator — and your content lands underneath them unless your CSS explicitly accounts for it. This half is fixed on your website, not in the shell.

Two pieces are required, and the first is the one people miss:

1. Opt in with the viewport meta tag. The safe-area values are only exposed once the page declares that it wants to draw edge to edge:

<meta name="viewport"
      content="width=device-width, initial-scale=1, viewport-fit=cover">

Without viewport-fit=cover, the inset values read as zero and every rule below silently does nothing — which is why "I added the CSS and it didn't work" is the most common report here.

2. Apply the insets in CSS using the env() function, always with a fallback value so desktop browsers and older devices behave:

/* A fixed site header, clear of the notch */
.site-header {
  padding-top: env(safe-area-inset-top, 0px);
}

/* A sticky bottom bar, clear of the home indicator */
.bottom-tabs {
  padding-bottom: env(safe-area-inset-bottom, 0px);
}

/* Landscape: clear the rounded corners and camera housing */
.content {
  padding-left: env(safe-area-inset-left, 0px);
  padding-right: env(safe-area-inset-right, 0px);
}

The four insets are top, bottom, left and right. Add them as padding on the elements that touch the screen edges, rather than as a margin on the body — padding keeps your header's background colour extending under the status bar, which is the look you want. A margin leaves a strip of blank page above it, which is the look you don't.

If you are working out which devices have which cutouts, our guide to iPhone screen resolutions and sizes covers the hardware side of the same problem.

What Changed in 2025–2026

The biggest change is on Android: apps targeting SDK 35 are drawn edge to edge by default on Android 15, and the old status bar colour API no longer has any effect. Apps that previously set a status bar colour and never thought about insets can regress visually just by raising their target SDK.

Three things worth knowing as of September 2026:

• Android 15 enforces edge-to-edge for apps targeting SDK 35. Your content now draws behind the status and navigation bars by default, so insets must be handled rather than assumed. Window.setStatusBarColor is deprecated and ignored for these apps — the colour now comes from what your content draws there. This ties directly into the Google Play target SDK 35 requirement, which is why a lot of apps hit both at once.
• Gesture navigation is the default on both platforms, which means the home indicator area at the bottom is permanent, not optional. A bottom bar without safe-area-inset-bottom padding sits under a system gesture zone, so taps near it get swallowed.
• Dynamic Island widened the top inset on the devices that have it. Hard-coded pixel values for notch clearance — which were always a bad idea — are now visibly wrong on current hardware. Use env(), never a magic number.

The practical takeaway is that insets moved from a nice-to-have to a requirement. Edge-to-edge is no longer something you opt into on Android; it is what you get.

Bounce, Tap Highlights and Long-Press Menus

Three small CSS defaults are responsible for most of the remaining "this is a web page" tells: the overscroll bounce, the grey flash on tap, and the long-press callout menu on images. All three are one-line fixes, and all three should be applied selectively rather than globally.

Be careful with the last two. Disabling the callout on every image stops users saving a product photo they actually wanted. Disabling text selection on body copy stops them copying an address, a code, or a quote — a genuinely hostile thing to do, and one that will show up in reviews. Apply user-select: none to your navigation, tab bar and buttons, and leave article text alone.

If you remove the tap highlight, replace it with something. A tap that produces no visible feedback at all reads as a broken button, so pair -webkit-tap-highlight-color: transparent with an :active state that changes the background or scales the element slightly. The goal is a deliberate response, not no response.

What Happens When the Keyboard Opens?

When the on-screen keyboard opens, it covers the bottom of the screen, and any fixed-position element anchored there — a bottom tab bar, a sticky "Add to cart" button — can end up floating above the keyboard or hidden behind it. This is the least-tested part of a WebView app and one of the most visible when it breaks.

The behaviour differs by platform and by how the shell configures window resizing, so the reliable approach is to test rather than reason about it. Two things help in practice:

• Hide sticky bottom chrome while an input is focused. Listening for focus and blur on form fields and hiding the tab bar in between avoids the whole class of problem, and it is what most native apps do anyway.
• Scroll the focused field into view yourself. Automatic scroll-into-view is inconsistent inside a WebView, particularly on long forms. A scrollIntoView call on focus is a cheap safety net.

A checkout form where the keyboard hides the submit button is a conversion problem, not a cosmetic one, which is why this deserves a real device test alongside the session persistence checks covered in our previous guide.

Step-by-Step: Adding the Native Touches

Do the CSS half first, because you can verify it in a desktop browser before an app build exists. Six steps, and the first two have to come before the rest.

How Do You Test This Properly?

Safe areas and status bars cannot be verified on a desktop browser or a non-notched device, because the insets you are trying to handle are zero there. A layout that looks perfect in responsive mode can still be sitting under a Dynamic Island.

1. Test on a device with a cutout — a notch or Dynamic Island on iOS, a punch-hole camera on Android. Insets are zero on hardware without one, so it will pass regardless.
2. Rotate to landscape. The left and right insets only become non-zero here, and this is where edge clipping shows up.
3. Scroll halfway down, then swipe down. The page should scroll, not reload. If it reloads, pull-to-refresh is missing its scroll-position check.
4. Toggle dark mode. Confirm the status bar icons are still readable against the header in both themes.
5. Open the keyboard on your longest form and confirm the submit button is reachable.
6. Check the bottom bar against the home indicator, and tap the outermost buttons. If a tap near the bottom edge does nothing, it is being intercepted by the system gesture area.

None of this needs a device lab. One current iPhone and one current Android phone cover the cases that matter, and the whole pass takes about ten minutes. The same real-device discipline applies to file downloads in a WebView app, where simulator behaviour also differs from real hardware.

Common Mistakes

Frequently Asked Questions

Key Takeaways

• Pull-to-refresh and the status bar are shell settings; safe areas and touch defaults are CSS on your site. Know which half is whose.
• viewport-fit=cover is the prerequisite — without it every safe-area inset reads as zero and your CSS does nothing.
• Gate pull-to-refresh on the WebView being scrolled to the top, or mid-page swipes will reload and lose the user's place.
• Set the status bar background and its icon colour, and flip the icon colour for dark mode.
• Android 15 draws apps targeting SDK 35 edge to edge by default, so insets are now mandatory rather than optional.
• Never hard-code notch padding, and never disable text selection on article content.

These details are what separate an app users keep from one they delete after a week — the same category of polish as a properly designed splash screen and a real offline state. They also matter for review: an app that looks like an unmodified website is exactly what Apple's Guideline 4.2 exists to reject, and the gap between a thin wrapper and a real app is covered in our WebView versus native comparison. If you are building the shell yourself, our Android Studio WebView guide covers where these settings live in a real project.