On the open web, a page calls navigator.geolocation.getCurrentPosition() and gets a coordinate — used for store finders, fraud checks, and localized content. Inside a WebView, the same call silently fails. On Android the Geolocation API is disabled by default and only works if the host wires a callback, grants a runtime permission, and serves the page over HTTPS. On iOS every request is routed through a WKUIDelegate method the app must implement. A host-owned runtime bridges native location — one call that resolves to the device GPS on every engine.
Android: geolocation is off until the host turns it on
Android's WebSettings.setGeolocationEnabled() defaults to false. Enabling it is only the first of four requirements: the app must hold ACCESS_FINE_LOCATION / ACCESS_COARSE_LOCATION, it must implement WebChromeClient.onGeolocationPermissionsShowPrompt() and call callback.invoke(origin, true, false), it must request the dangerous permission at runtime on Android 6.0+, and the page must be served over HTTPS (or localhost). Miss any one and getCurrentPosition() returns PERMISSION_DENIED — or, worse, fails with no callback at all. Vendor ROMs (EMUI, MIUI) add background-location restrictions that can leave the WebView unable to obtain a service handle even after permission is granted.
iOS: every request goes through the app
In WKWebView, geolocation is delegated entirely to the app via WKUIDelegate.webView(_:requestGeolocationPermissionFor:initiatedByFrame:decisionHandler:). If the app never implements that method, the request simply dies — no prompt, no fix. Apple also requires NSLocationWhenInUseUsageDescription (and the Always variant if needed) in Info.plist, and the app should request native authorization through CLLocationManager before the web content asks. A page that calls geolocation on load, or without a direct user gesture, is blocked or re-prompted. Without a button-triggered flow, users see confusing duplicate prompts or a silent failure.
What breaks when position is lost
- KYC location verification fails. Broker and exchange onboarding that proves "the user is in an allowed jurisdiction" cannot read a coordinate, so compliant onboarding stalls.
- Branch, ATM, and agent finders go dark. "Find the nearest office" returns nothing because the page never gets a fix.
- Geofenced compliance breaks. Region-locked products and marketing consent rules that depend on location silently misfire.
- Fraud signals weaken. Location is a key risk signal; losing it pushes more legitimate users into false declines.
The runtime fix
A host-owned runtime bridges the location layer. The page calls one uniform API — runtime.getLocation(options) — and the host resolves it through the platform-native provider: FusedLocationProvider / LocationManager on Android, CLLocationManager on iOS. Permission, accuracy, and timeout are handled natively and returned as a coordinate the page can trust. One integration, every engine, a real position at the end of it.
| Dimension | WebView | Host-owned runtime |
|---|---|---|
| Android default | Geolocation API off (setGeolocationEnabled=false) | Native provider, always on |
| Permission flow | Host callback + runtime grant + HTTPS | One runtime.getLocation() |
| iOS path | WKUIDelegate method, or it dies | Native CLLocationManager |
| Failure mode | Silent PERMISSION_DENIED / no callback | Explicit, observable error |
| KYC / geofence | Breaks | Works |
| Consistency | Per-engine | Uniform |
A native app reads the device GPS on every device. A stock WebView reads it on almost none. A runtime gives the page one location call — and a coordinate it can act on.
Sources
- Android WebSettings — setGeolocationEnabled — geolocation is disabled by default in WebView; enabling requires app permission, a
WebChromeClientcallback, and HTTPS. - Android WebChromeClient — onGeolocationPermissionsShowPrompt — the host must implement this callback and invoke it to grant or deny.
- Apple Developer — WKUIDelegate requestGeolocationPermissionFor — WKWebView delegates geolocation to the app; without this method the request fails.
- Apple Developer — CLLocationManager — native iOS location authorization the app must request before web content asks.
- WebApp2App — Button-triggered geolocation in iOS WebView — WKWebView requires a user gesture and a single native permission layer; load-time calls are blocked or re-prompted.
