Na web aberta, uma página chama navigator.geolocation.getCurrentPosition() e obtém coordenadas — para buscas de lojas, verificação antifraude e conteúdo localizado. Dentro de um WebView, a mesma chamada falha em silêncio. No Android a API de geolocalização está desativada por padrão e só funciona se o host conectar um callback, conceder permissão em tempo de execução e servir a página via HTTPS. No iOS cada pedido passa por um método WKUIDelegate que o app deve implementar. Um runtime de propriedade do host conecta a localização nativa — uma chamada que resolve para o GPS do dispositivo em cada motor.
Android: a geolocalização fica desligada até o host ligá-la
WebSettings.setGeolocationEnabled() do Android é falso por padrão. Habilitá-lo é apenas o primeiro de quatro requisitos: o app precisa ter ACCESS_FINE_LOCATION / ACCESS_COARSE_LOCATION, implementar WebChromeClient.onGeolocationPermissionsShowPrompt() e chamar callback.invoke(origin, true, false), solicitar a permissão perigosa em tempo de execução no Android 6.0+, e a página precisa ser servida via HTTPS (ou localhost). Falte um e getCurrentPosition() retorna PERMISSION_DENIED — ou, pior, falha sem nenhum callback. ROMs de fabricantes (EMUI, MIUI) adicionam restrições de localização em segundo plano que podem deixar o WebView incapaz de obter um handler do serviço mesmo após a permissão ser concedida.
iOS: cada pedido passa pelo app
No WKWebView, a geolocalização é totalmente delegada ao app via WKUIDelegate.webView(_:requestGeolocationPermissionFor:initiatedByFrame:decisionHandler:). Se o app nunca implementa esse método, o pedido simplesmente morre — sem aviso, sem conserto. A Apple também exige NSLocationWhenInUseUsageDescription (e a variante Always se necessário) no Info.plist, e o app deve solicitar autorização nativa via CLLocationManager antes do conteúdo web pedir. Uma página que chama geolocalização no carregamento, ou sem um gesto direto do usuário, é bloqueada ou reapresenta o aviso. Sem um fluxo acionado por botão, os usuários veem avisos duplicados confusos ou uma falha silenciosa.
O que quebra quando a posição se perde
- Falham as verificações KYC de localização. A onboarding de corretoras e exchanges que prova "o usuário está em uma jurisdição permitida" não consegue ler coordenadas, e a onboarding conforme trava.
- Buscas de agências, caixas e agentes escurecem. "Encontre a agência mais próxima" não retorna nada porque a página nunca obtém uma posição.
- Geofences de conformidade quebram. Produtos restritos por região e regras de consentimento de marketing que dependem de localização falham em silêncio.
- Sinais antifraude enfraquecem. A localização é uma indicação de risco importante; perdê-la empurra mais usuários legítimos para falsas recusas.
A solução do runtime
Um runtime de propriedade do host conecta a camada de localização. A página chama uma API uniforme — runtime.getLocation(options) — e o host a resolve pelo provedor nativo da plataforma: FusedLocationProvider / LocationManager no Android, CLLocationManager no iOS. Permissão, precisão e tempo de espera são tratados nativamente e retornados como uma coordenada na qual a página pode confiar. Uma integração, cada motor, uma posição real no fim.
| Dimensão | WebView | Runtime de propriedade do host |
|---|---|---|
| Padrão Android | API de geolocalização desligada (setGeolocationEnabled=false) | Provedor nativo, sempre ativo |
| Fluxo de permissão | Callback do host + concessão em runtime + HTTPS | Um runtime.getLocation() |
| Caminho no iOS | Método WKUIDelegate, ou morre | CLLocationManager nativo |
| Modo de falha | PERMISSION_DENIED silencioso / sem callback | Erro explícito e observável |
| KYC / geofence | Quebra | Funciona |
| Consistência | Por motor | Uniforme |
Um app nativo lê o GPS do dispositivo em todos os dispositivos. Um WebView padrão em quase nenhum. Um runtime dá à página uma chamada de localização — e uma coordenada com a qual agir.
Fontes
- Android WebSettings — setGeolocationEnabled — a geolocalização é desativada por padrão no WebView; habilitá-la exige permissão do app, callback de WebChromeClient e HTTPS.
- Android WebChromeClient — onGeolocationPermissionsShowPrompt — o host deve implementar esse callback e invocá-lo para conceder ou negar.
- Apple Developer — WKUIDelegate requestGeolocationPermissionFor — WKWebView delega a geolocalização ao app; sem esse método o pedido falha.
- Apple Developer — CLLocationManager — autorização de localização nativa do iOS que o app deve solicitar antes do conteúdo web perguntar.
- WebApp2App — Geolocalização acionada por botão no WebView iOS — WKWebView exige um gesto do usuário e uma única camada de permissão nativa; chamadas no carregamento são bloqueadas ou reaviso.
