WebViewGold Documentation · iOS
🇺🇸 English
Get WebViewGold

Pull-to-Refresh API

Enable the native pull-to-refresh gesture in your iOS WebView app, customize its colors, and toggle it dynamically from your web app.

The Pull-to-Refresh API adds the native iOS pull-to-refresh gesture to your WebView app: users drag the page down to reload the current URL — just like in native apps such as Mail or Safari.

How to Enable:

Open Config.swift and set:

var pulltorefresh = true
var preventoverscroll = false
  • pulltorefresh activates the native refresh control.
  • preventoverscroll must be set to false — the gesture needs the WebView bounce/overscroll animation to work.

Customize the Colors:

You can style the loading spinner and its background separately for Light and Dark Mode in Config.swift:

var pulltorefresh_loadingsigncolour_lightmode = #colorLiteral(...)
var pulltorefresh_backgroundcolour_lightmode = #colorLiteral(...)
var pulltorefresh_loadingsigncolour_darkmode = #colorLiteral(...)
var pulltorefresh_backgroundcolour_darkmode = #colorLiteral(...)

Tip: Click the color swatch next to each #colorLiteral in Xcode to pick a color visually. The Dark Mode variants require iOS 13 or higher.

Toggle Dynamically from Your Web App:

You can switch pull-to-refresh on or off at runtime — for example, to disable it on pages with their own swipe gestures (maps, sliders, games):

<a href="enablepulltorefresh://">Enable pull to refresh</a>
<a href="disablepulltorefresh://">Disable pull to refresh</a>

Or via JavaScript:

window.location.href = "disablepulltorefresh://";

Both commands are also supported inside a MultiAPICall request.

Good to Know:

  • The refresh control reloads the URL that is currently displayed in the WebView.
  • If you use the Dynamic UI API to change the bottom bar color at runtime, the pull-to-refresh colors are adjusted automatically to match.

SDK-style implementation notes

Treat this feature as a native capability exposed to your web layer: keep your production website or PWA as the source of truth, then use the documented WebViewGold configuration flags, URL commands, and JavaScript bridge calls to opt in to native iOS behavior only where it adds value. This approach keeps your codebase maintainable because the same web application can serve browsers, WebViewGold for iOS, and the other WebViewGold platforms with minimal conditional logic.

For reliable results, prefer HTTPS endpoints, stable route names, explicit success/error states in your UI, and small JavaScript helper functions that wrap native calls. For example, a web app built with jQuery Mobile, Lovable, Base44, Bolt, WordPress, Bubble, a custom React/Vue/Angular stack, or static HTML can expose a single button or event handler that triggers the native WebViewGold API while still showing a graceful browser fallback.

  • Recommended integration pattern: detect the app context, call the WebViewGold API, then update your web UI after the native callback or route change.
  • Testing checklist: validate the feature on a real device or packaged build, verify permissions and store review text, and confirm that browser-only users still receive a useful fallback.
  • SEO benefit: keep feature pages, route titles, and structured content indexable on your website while WebViewGold delivers the native app shell for iOS users.

Too busy? We set up your app for you.

Our team configures, builds & submits your WebViewGold app — done-for-you, fast turnaround, Made in Germany.

Get your app set up →

Build in your browser

No Mac, no IDE: the WebViewGold Cloud Builder configures, builds & uploads your app online.

Discover Cloud Builder →