Understand location permission states
Location permission, a returned coordinate, an address, and a business result are separate states. The permission flow can differ between iOS and Android.
:::warning Location information is private
Do not include addresses, coordinates, search text, permission records, device or account identifiers, provider responses, keys, screenshots, or settings details in documentation or diagnostics.
:::
Keep ownership layers separate
| Layer | What it represents | What it does not prove |
|---|---|---|
| Native declaration | A build declares a location purpose or capability | Installed-artifact parity, OS authorization, or a current request |
| OS authorization | The operating system's current decision and scope | App consent, provider consent, a coordinate, or durable availability |
| App-owned state | Loading, disabled, error, toast, fallback, or cached state | The OS decision is unchanged or that another surface agrees |
| Device-location result | A coordinate returned to one native callback | Address ownership, precision, freshness, or permission persistence |
| Reverse-geocode result | A provider translated a coordinate into address data | Saved address, delivery coverage, or trusted current data |
| Map/location display | A map layer or camera used a supplied/cached coordinate | An explicit permission request or accepted business search |
| Saved/order location | Address state owned by account/order/cart surfaces | Device permission, current device position, or provider readiness |
Native declarations differ from runtime authorization. Prompting, denial, limited access, retry, and returning from Settings can differ between iOS and Android.
Explicit location action
When the address form offers a current-location control, selecting it starts a location request. If the device returns coordinates, a location service may convert them into an address suggestion.
If native location reports denial, the form can show a denial message. The control can remember that denial for its current mounted lifetime and show the message again without making another native call. This is App-local state, not a fresh OS authorization check.
The app may not offer a direct link to the device's location settings. If location is unavailable, use a saved address or enter one manually when those options are available.
Passive discovery and map boundaries
Some discovery screens may request location when they open or when the order location changes. A map can also show a current-location marker or recenter control. These features are separate from the location control in an address form.
A visible recenter control does not prove that a device coordinate exists. A user-location display, far-away notice, or moved camera does not prove that the app deliberately requested permission, that authorization remains current, or that a location was saved.
Denied, unavailable, and unknown states
| State | Safe interpretation |
|---|---|
| Control idle | No current action is established. |
| Loading | A native callback or provider result is pending; authorization is not proved. |
| Denied callback | One native attempt reported denial; OS scope and future eligibility remain platform-owned. |
| App-local disabled | This mounted control suppresses another native attempt; OS state may differ. |
| Native error | Location failed for an unspecified platform reason. |
| Provider error or no result | Reverse geocoding did not produce an accepted address candidate. |
| Coordinate returned | One callback produced location data; address and persistence remain pending. |
| App lifecycle change | Prior callbacks and cached state may be stale. |
| Account/project/session change | Earlier coordinates, providers, and responses must not cross ownership generations. |
Do not repeatedly activate location, open Settings, toggle authorization, or move the map to diagnose an unknown outcome. Use a manual or saved-address alternative when the current surface offers one, and preserve unresolved state as unknown.
Provider and data-minimization boundary
Location can cross several independent destinations: the native location module, map SDK, geocoder, autocomplete or business search. An accepted flow must make each destination and purpose explicit, minimize coordinate precision and query data, avoid passive or duplicate requests, redact telemetry, and reject stale callbacks after account, project, session, permission, consent, or surface changes.
A coordinate, provider response, displayed address, map result, or successful navigation does not establish provider consent, address ownership, serviceability, saved state, or cart settlement.
Accessibility and safe troubleshooting
Location controls, denial messages, map alternatives, and accessibility behavior can vary by device and app version. If a prompt is unavailable or unclear, use a saved address or enter one manually when offered. Avoid sharing your location or provider error details when requesting help.
Related guides: Understand location selection states · Add or edit an address · Understand map discovery states · Platform and accessibility behavior · Privacy and consent