Geolocation permission in PWAs needs explicit timing and fallback UX

Why this matters for OpenPWA

Geolocation is one of the most powerful but also most sensitive capabilities. In installed PWAs the permission prompt appears in the context of an app the user has already chosen to keep on their device, so the stakes for trust are higher.

Poor timing or missing context leads to permanent denial and lost functionality.

Decision framework for location requests

1. Only request after the user has performed an action that clearly benefits from location (e.g., "Find stores near me").
2. Show a short in-app explanation before the browser prompt appears.
3. Always provide a "Not now" or manual zip-code entry fallback.
4. Store the permission result and never re-prompt on every visit.
5. Respect permission.state changes and update UI accordingly.

Official source facts

• Geolocation API is defined in https://w3c.github.io/geolocation-api/
• Permission status can be queried via the Permissions API: https://developer.mozilla.org/en-US/docs/Web/API/Permissions_API
• Chrome and Edge show a one-time or persistent prompt; Safari on iOS shows a more restrictive sheet.

Checklist for production PWAs

• [ ] Request only after explicit user gesture tied to a location feature
• [ ] Display value proposition text before prompt
• [ ] Handle GeolocationPositionError codes gracefully
• [ ] Offer manual location input as fallback
• [ ] Cache last known position with reasonable staleness rules

Next step

Review every place your PWA calls getCurrentPosition or watchPosition. Add a lightweight pre-prompt UI component and test the full denial path on real devices.