GuideSep 14, 202613 min read

How to Add Maps and Location Tracking to a Mobile App

Contents

To add maps and location tracking to a mobile app, separate the visual map from device location. The map renders markers, routes, and regions. The location service requests permission and supplies coordinates. Your backend stores only the location data the product needs and controls who may read it.

Most apps should begin with foreground location. Background tracking adds battery, privacy, platform policy, and review requirements that are unnecessary for a nearby-store map or one-time address selection.

Key takeaways:

Request location only when the user starts a feature that needs it, support approximate and denied permission states, keep the map usable without live tracking, send location updates according to distance and time thresholds, and use background access only when it is central to the product.

Define the location feature precisely

"Add a map" can mean several different products. Choose the smallest use case before selecting libraries or requesting permissions.

Use case	Location access needed	Backend needed?
Show fixed store locations	None	Usually only for store data
Let user choose a place on a map	None or optional foreground access	Save selected coordinates and address
Find nearby results	Foreground approximate or precise location	Often, for searching and ranking
Track a delivery during an active trip	Foreground and possibly background	Yes, for authorized live updates
Record a fitness route	Foreground and background during a user-started session	Yes, if routes sync across devices
Trigger arrival or departure actions	Geofencing and possible background access	Usually

Write down the acceptable accuracy, update frequency, retention period, and viewers. A delivery customer may need the driver's rough progress, while the operations team needs a more precise current position. Those do not have to be the same data feed.

Choose the map and location layers

In an Expo or React Native app, the map component and the location API are separate packages.

Expo documents react-native-maps as a map component that uses Google Maps on Android and Apple Maps or Google Maps on iOS. Its map view guide also lists expo-maps as an Expo-built alternative.

The location layer comes from a package such as expo-location, which handles current position, ongoing updates, geocoding, geofencing, and permission requests. The official Expo Location documentation describes foreground and background behavior.

Layer	Responsibility
Map view	Camera region, markers, shapes, overlays, and user interaction
Location service	Coordinates, accuracy, heading, permissions, and background tasks
Geocoding service	Address to coordinates and coordinates to address
Routing service	Route geometry, distance, duration, and navigation instructions
Backend	Location sharing, trip state, access control, retention, and notifications

A map provider does not automatically include routing or place search. Check its terms, attribution, coverage, and production key restrictions.

Design the permission flow before writing code

Ask for permission when the user starts the location-based action. A screen that explains the benefit, followed immediately by the system prompt, gives the request context.

Android's runtime location guidance recommends requesting access in context. It also explains that users can grant approximate location even when the app asks for precise access.

Apple's Core Location authorization guide similarly requires checking the current authorization state and requesting the level the feature needs.

Handle every result:

Permission state	App behavior
Not requested	Explain the feature, then request when the user continues
Foreground precise	Run the full foreground feature
Foreground approximate	Use the feature at reduced precision when possible
Denied	Keep the map usable and offer manual search or pin selection
Permanently denied	Explain how to open system settings without repeated prompts
Background denied	Continue the foreground feature if it still has value
Location services off	Explain that device location is disabled and provide a retry action

Do not block an entire app because one optional map feature lacks permission. A user should still be able to type an address, browse fixed locations, or choose a point manually.

The permission description in the app configuration must say what the feature does. "We need your location" is weaker than "Allow location while using the app to show nearby pickup points."

Expo's permissions guide explains that standalone and development builds need native build-time permission configuration in addition to runtime requests.

Show the user's current position

When the map opens, you can show a broad default region immediately, then request or read location. Do not leave the screen blank while waiting for GPS.

A practical sequence is:

text

Map opens with default region
  -> permission state loads
  -> app requests foreground access if user started the feature
  -> last known location provides a fast initial position when suitable
  -> fresh location arrives
  -> map animates only if the user has not moved it manually

The last known position can be faster but stale. A fresh request can take longer, especially indoors. Show a loading state and define how old or inaccurate a cached position may be for your use case.

Do not force the camera back to the user's dot after every update. Once the user pans or zooms, respect that action. A separate recenter button can return to the current location.

Display accuracy honestly. A large accuracy circle or a "location is approximate" message is better than placing a precise-looking pin on uncertain coordinates.

Store locations with a clear data model

Coordinates are only part of a location record. Save the context needed to interpret them.

Field	Purpose
`latitude`, `longitude`	Geographic point
`accuracy_meters`	Reported horizontal uncertainty
`recorded_at`	Time the device measured the point
`received_at`	Time the backend received it
`source`	GPS, manual pin, geocoded address, or imported data
`trip_id` or `resource_id`	The delivery, route, place, or event it belongs to
`user_id` or `device_id`	Authorized source identity

Do not use the client-provided user ID as proof of ownership. Derive identity from the verified session. If the app tracks a courier or field worker, verify that the user is assigned to the active trip before accepting an update.

For a live trip, keep the current position in a fast-access record and append history only if the product needs route playback or audit. Avoid retaining detailed trails without a clear purpose.

Add markers without slowing the map

A few fixed markers are simple. Hundreds or thousands require server-side filtering and clustering.

Fetch points within the visible map bounds or near the search center. Do not download every location in the country and hide most of them in the client.

Marker behavior should include:

Stable identifiers and visual selection states.
Clustering when many points overlap.
Accessible labels and a selected-place detail card.
Clear empty and loading states.

Debounce region-based searches while the map is moving. Request results after the gesture settles, and ignore stale responses if a newer region request has already started.

Convert addresses and coordinates carefully

Geocoding converts an address into coordinates. Reverse geocoding converts coordinates into a readable place. Both can return uncertain or incomplete results.

Keep the coordinates as the canonical location for map placement. Store the formatted address as display data, along with useful structured fields such as city, region, postal code, and country when available.

Let users correct the result. A typed address may point to the center of a building, postal area, or street instead of the exact entrance. Delivery and service apps often need an adjustable pin plus a note such as apartment, floor, gate, or landmark.

Do not reverse geocode every tracking update. Convert only when the interface needs a readable place.

Add routing as a backend or provider request

A straight line between two markers is not a road route. Use a routing service to calculate route geometry, distance, duration, and optional turn instructions.

Keep route requests separate from raw location updates. Recalculate when the destination changes, the user moves far enough from the current route, or the product explicitly requests a refresh.

API keys used only for client map rendering may be designed for mobile use, but they should still be restricted by application identifier, platform, and enabled APIs. Routing or geocoding secrets that grant privileged access belong on the backend.

Build live tracking around a session

Location tracking should start because the user starts a trip, workout, shift, or sharing session. It should stop when that session ends.

A tracking record can move through these states:

text

idle -> requesting permission -> active -> paused -> completed
                         \-> error

During an active session, collect updates based on both time and distance. Sending every small GPS fluctuation wastes battery and backend capacity. The right thresholds depend on movement speed and product expectations.

Each update should include its timestamp and accuracy. The backend can reject stale points or updates unrelated to the active assignment.

For viewer screens, subscribe only to the active trip. If a socket disconnects, fetch the latest saved point after reconnecting. Show when the location was last updated so the customer does not mistake a stale marker for a live one.

Use background location only when essential

Background access lets tracking continue when the user switches apps or locks the screen, but mobile operating systems limit it.

Expo states that background location needs granted permissions and a task defined at top level with TaskManager. On iOS, it also requires the location background mode, and it needs a development build because Expo Go does not support background location. Review the current requirements in the Expo Location guide.

Google's background location guidance says apps should request it only when it is critical to a user-facing feature. Android also limits background update frequency to protect battery, and Google Play applies additional policy review.

Before adding background access, confirm:

The core feature fails without it.
The user explicitly starts and can stop tracking.
The app clearly indicates when tracking is active.
The privacy policy explains collection, use, sharing, and retention.
The Android and iOS permission descriptions match actual behavior.
The product works reasonably when background access is denied.
You have tested process termination, device restart, and vendor-specific battery behavior.

Never start continuous background tracking merely because a user signed in.

Control battery and data usage

Accuracy, frequency, and background duration affect battery. Use balanced accuracy when precise GPS is unnecessary, increase intervals when movement is slow, stop updates when the feature ends, and avoid repeated geocoding or routing. Test a realistic session with weak signal, screen-off, and background periods.

Protect location privacy

Location can reveal home, work, routines, and relationships. Collect less of it and limit who can see it.

Apply server-side authorization to every location query. A customer should read only the trip assigned to them. A courier should update only their active assignment. Support staff access should be logged and limited to a valid reason.

Additional controls include:

Encrypt data in transit and use protected backend storage.
Avoid precise coordinates in analytics and crash logs.
Remove location from push notification text and payloads unless needed.
Use shorter retention for detailed routes than for completed trip summaries.
Provide clear controls to stop sharing and delete eligible history.
Prevent predictable trip IDs from granting access.

If public discovery needs only a city or broad area, do not expose an exact home coordinate.

Handle location failures in the interface

GPS may be slow, denied, inaccurate, or unavailable. Design those states as normal product behavior.

Problem	Helpful response
Permission denied	Manual search or pin selection plus a settings option
Approximate location	Continue with wider search radius or request precision only when necessary
GPS timeout	Keep the existing map and offer Retry
Weak accuracy	Show uncertainty and wait or let user adjust
Network unavailable	Keep cached map state and queue eligible updates
Route service fails	Retain endpoints and allow another attempt
Live position becomes stale	Show last update time instead of pretending it is current

Do not turn every failure into a blocking alert. Inline messages near the map usually preserve context better.

Test maps and tracking on real devices

Simulator locations help during development, but release testing needs real devices and real movement.

Test:

First permission request, denial, and later change in Settings.
Approximate and precise access.
Location services disabled at device level.
Indoor, outdoor, and weak-signal conditions.
App backgrounded, screen locked, and process terminated.
Network switching and full offline periods.
A user panning while new locations arrive.
Dense markers and rapid region changes.
Stale route and geocoding responses.
Account B attempting to read account A's trip.
Tracking stopping at the end of a session.
Release builds with production map keys and restrictions.

Use the broader AI-built mobile app testing guide before store submission.

Build your location-based app with Huxly

Huxly helps you build the mobile map interface, authentication, backend, location database, live trip updates, and permission states in one project. You can test the full Expo, Flutter, or SwiftUI experience on real devices and prepare it for TestFlight and Google Play with the production configuration included.

FAQ

Do I need location permission just to show a map?

No. A map can display fixed markers, searched places, and manually selected points without reading the device's location.

Should I request precise or approximate location?

Request the least precise level that supports the feature. Nearby discovery may work with approximate access, while active navigation or route recording may need precision.

Can location tracking continue when the app is closed?

Background behavior depends on platform rules, granted permissions, build configuration, and whether the app was backgrounded or terminated. Do not promise continuous tracking until you have tested the exact release build and device states.

How often should a tracking app send location updates?

There is no universal interval. Choose time and distance thresholds based on speed, required freshness, battery cost, and backend load. Send less often when the product does not need turn-by-turn precision.

Should live location be stored forever?

Usually not. Define separate retention for current position, detailed route history, and completed trip summaries. Keep only what the product and legal requirements justify.

Is a mobile map API key secret?

Some provider keys are designed to ship in mobile apps, but they must be restricted to the correct app identifiers, platforms, and APIs. Privileged service credentials still belong on the backend.

Conclusion

Maps and location tracking work best when permission, accuracy, storage, and visibility match one product use case. Keep the map useful without device location, then add foreground positioning where it improves the task.

Background tracking should be the final step, not the default. It needs a user-started session, clear disclosure, careful battery settings, strict backend access, and testing across the operating-system states that a development preview cannot reproduce.