Maps and geolocation in apps: the pitfalls behind the pin

01Choose the smallest amount of location data that works

Showing a map, obtaining the device's position, and translating an address into coordinates are separate operations. A branch map can display your own stored addresses without accessing the visitor's location. Geocoding turns text into coordinates; reverse geocoding produces an address or place description from coordinates. Neither automatically proves that someone is physically there.

Write down why the feature needs a position, its acceptable uncertainty, and whether it needs one reading or continued updates. A delivery address may need an entrance rather than the building's center. A regional stock forecast may need no individual route history at all. The answer should come from the workflow.

02Treat permission and accuracy as changing conditions

The W3C Geolocation specification describes position estimates from several possible sources, not just GPS. It provides accuracy and a timestamp, supports single readings and ongoing updates, and requires user permission. Web implementations also need a secure context and an appropriate Permissions Policy. A high-accuracy request is a preference, not a promise.

Use the timestamp and reported accuracy in the feature's decision. An old position might be adequate for suggesting a region and unsuitable for locating a moving vehicle. Show uncertainty when it matters. Do not label a stale position as live, and do not interpret a broad accuracy estimate as proof that a worker crossed a narrow boundary.

Ask when the feature needs it

Apple recommends requesting authorization when someone engages with the feature that requires it, and preferring When In Use access where possible. Background behavior depends on authorization, app configuration, and the location service involved. Always authorization is not a blanket requirement for every background scenario, nor a guarantee of uninterrupted updates.

Android distinguishes foreground and background access from precise and approximate location. Users can choose approximate access even when the app requests precise access. Its background-permission flow also varies by OS and target SDK version. Test the actual supported versions rather than copying one permission screenshot into the specification.

Provide a usable path for refusal, changed settings, timeouts, and unavailable readings. Explain what the person can still do and how to enable a feature later. Stop repeated requests after refusal. If a task genuinely requires precise location, explain the requirement at that task instead of blocking unrelated parts of the app.

03A device permission is not automatically a legal basis

The operating system's dialog authorizes access to a device capability. It does not, by itself, establish that every subsequent use, recipient, or retention period is lawful. Sending a position to a dispatcher and reusing it for advertising are different purposes. Define both the permission flow and the rules governing the data.

Applicable law depends on the markets, people, and processing involved. The GDPR has a defined territorial scope, including certain offering or monitoring activities by organizations outside the EU. Where it applies, assess the lawful basis for each purpose, minimize collection, limit retention, provide transparency, and secure the data. Processor arrangements and international transfers need their own assessment. A vendor's location or a user's nationality alone does not settle the scope.

When relying on GDPR consent, the EDPB's consent guidelines require a freely given, specific, informed, and unambiguous choice, with an easy way to withdraw it. Employment relationships raise particular concerns about whether refusal is truly free. Avoid assuming that a worker tapping Allow resolves the legality of workforce tracking.

Keep these choices understandable. Explain what the feature does, whether it continues outside the visible screen, who receives the information, and how users control it. A privacy notice should describe the implemented behavior. It cannot compensate for an SDK quietly collecting more than the feature needs.

Use a consent platform for the data flows it actually controls

Configure a consent management platform to record relevant web choices and block third-party services until consent is obtained where the applicable rules require it. It does not grant native OS permission or determine your lawful basis. Connect it to the actual purposes and providers, and test what loads before and after each choice. Adding a cookie banner to a native location screen does not solve either task.

04Follow the coordinates beyond your own database

List every destination before choosing an SDK: your API, the map renderer, geocoding service, analytics, crash reports, logs, support exports, and backups. A map request can disclose information even if your own server never stores a coordinate. Ask what each provider receives and whether its role is a processor, an independent controller, or something else for the actual service.

Reduce exposure in the implementation. Exclude raw coordinates and full addresses from routine diagnostics where they are unnecessary. Limit which staff can see individual routes. Avoid making a tracking link readable to anyone who guesses an order number. Our guide to mobile app security covers the wider API and storage controls.

Set a retention rule for each record type, with an owner and a deletion mechanism. An active position, delivery event, support record, and analytical aggregate may serve different purposes. Specify what happens to copies and exports as well as the primary table. Test deletion with sample records instead of accepting a policy document as evidence.

Removing a name does not necessarily make a route anonymous. A repeated home address, workplace, or persistent account identifier can still reveal whose activity it represents. Treat aggregation as a design to evaluate, not a label to attach. Review vendor changes too: an SDK update can alter collection, permissions, or network destinations.

05Map data rights and hosting are separate decisions

Read the terms for the particular product and agreement you will use. Check attribution, permitted displays, stored results, refresh requirements, offline use, and combinations with other providers. Keep your own customer-entered address distinct from a provider's response so you can apply the appropriate rules to each.

For example, Google's Geocoding API policies describe storage restrictions, an exception for place IDs, and display and attribution requirements. Its Map Tiles API policies separately restrict prefetching and caching except under the applicable terms, and require honoring relevant cache headers. Do not turn either example into a rule for every Google product or every map provider.

Open data does not mean unlimited use of a public server. The OpenStreetMap Foundation's standard raster tile policy requires attribution and normal caching, prohibits bulk prefetch and offline-download features, and offers no service-level guarantee. An app needing offline areas should use hosting and licensing that explicitly support that feature, including suitable self-hosted or commercial options.

Validate geocoding with the addresses your users actually enter. Include local scripts, apartment details, rural properties, duplicate street names, and missing postal codes. Let people confirm the destination and add access instructions. A successful API response is not the same as a usable delivery address.

06Protect API access and model the bill per workflow

A client-side map key should be designed for its intended exposure. Putting it in an environment variable during the build does not make it secret after it appears in the app or page. Use the provider's supported restrictions and avoid sharing one unrestricted credential across web, mobile, and server calls.

Google's security guidance distinguishes application restrictions from API restrictions and recommends separate keys for separate apps. Server web-service calls may need a secured proxy or other supported authentication. Protect that proxy with authentication, authorization, and rate controls; an open proxy merely moves the abuse to your server.

Estimate usage from the customer journey: map loads, address suggestions, geocoding, routes, retries, and background updates. Check which events the chosen service bills, along with current quotas and agreement terms. Load-test the journey and inspect actual requests. Re-rendering a component or retrying without a limit can produce calls nobody intended to buy.

Set usage alerts and a response owner. Google Cloud's alerts-only budgets do not automatically cap Google Maps Platform spending. Other cost controls have their own coverage and consequences. Verify what your chosen control actually stops, then decide which features can degrade safely when a quota or cost limit is reached.

Keep address entry available if the map cannot load, bound retries, and record failures without exposing location unnecessarily. For wider integrations, our API integration guide explains how to plan service dependencies and recovery paths.

07Run a pilot that includes refusal, outages, and deletion

1. Agree on the feature boundary. Name its purpose, minimum precision, start and stop conditions, fallback, recipients, retention, and accountable owners.
2. Test real permission states. Include refusal, approximate access, settings changes, and background transitions on supported devices and browser contexts.
3. Inject operational failures. Try stale and inaccurate readings, provider errors, lost connectivity, exhausted quotas, and interrupted tracking. Check what the user sees.
4. Inspect the data and bill. Observe SDK destinations, diagnostic records, request counts, access controls, and deletion. Resolve unexpected behavior before expanding the rollout.

Use a limited group whose locations and devices reflect real conditions. Agree on acceptance evidence rather than an arbitrary accuracy promise: can a person complete the task, recognize an uncertain position, and recover from a failure? A successful indoor demo says little about a rural delivery route or a phone with approximate access.

Keep someone responsible after launch. Monitor provider and platform changes, review abnormal call volumes, test supported OS updates, and rehearse key rotation. Location features continue to depend on systems your team does not control.

08Questions to settle before development