How to Build a Mobile App With GPS Tracking: Live Location for Delivery, Logistics and Field Teams in Nigeria

What GPS tracking in an app involves

GPS tracking in a mobile app means reading the device's position from the operating system's location services (which combine satellite GPS, cell towers and Wi-Fi) and doing something with it: showing it, sending it to a server, or triggering an action when it enters or leaves an area. There are three distinct modes, and the difference between them is the difference between a one-day feature and a month-long one:

• Locate once. Get the user's position to fill an address, find nearby branches or set a delivery pin. Simple, and needs only "while in use" permission.
• Track while in use. Update position continuously while the app is open on screen, such as a customer watching a rider approach. Moderate complexity.
• Track in the background. Keep updating position while the app is minimised or the screen is off, such as a rider app during a shift or a fleet app in a van. This requires foreground services on Android, "Always" authorisation on iOS, store policy compliance and serious battery engineering.

Beyond the phone, tracking involves a backend to receive and store positions, a way to stream them live to viewers, map rendering, and usually geofencing and history for reporting.

Which tracking mode does your app need?

The tracking mode should match the business question you are answering, and nothing more, because each step up costs battery, permissions friction and money.

If you can answer the business question with "locate once at key events" (pickup, drop-off, visit check-in), do that first. Continuous background tracking should be reserved for cases where the live position itself is the product.

Permissions and store policies on Android and iOS

Both platforms treat location, and especially background location, as sensitive. As of 2026 the rules below apply; verify the current documentation for each, because they change with every OS release.

Two practical consequences: your rider or driver app must explain clearly why it tracks, when it tracks (only during a shift or active delivery) and how to stop; and your customer app should never ask for background location at all.

Architecture: from the rider's phone to the customer's map

The difference between a tracking system that works and one that drains phones and floods servers is the pipeline design. A typical robust design has five stages:

1. Capture on the device. The rider app subscribes to location updates from the platform's location provider with a chosen interval, minimum distance and accuracy priority, running inside a foreground service on Android.
2. Filter and batch. Discard readings with poor accuracy or impossible jumps; ignore movements below a threshold; batch several points when the network is weak.
3. Transmit. Send batches over a lightweight channel: an HTTPS endpoint for simplicity, or MQTT or WebSocket for lower overhead at high frequency. Queue locally when offline and flush on reconnect.
4. Store and publish. The backend writes the latest position to a fast store (Redis or an in-memory table) for live queries and appends to a history table for reports; it then publishes updates to subscribers (customers, dispatchers) through a real-time channel.
5. Render. Viewer apps and the admin dashboard draw markers on a map, smoothing between updates so the dot glides rather than jumps, and compute estimated arrival using a routing service.

Update frequency is a business decision: every 3 to 5 seconds during an active delivery in the customer's view, every 15 to 60 seconds for fleet monitoring, and only on significant change when idle.

Step-by-step: implementing GPS tracking

1. Define the tracking policy in plain language. Who is tracked, when tracking starts and stops, what is stored, for how long, and who can see it. This becomes your consent screen, your privacy policy text and your store declarations.
2. Choose the map and routing provider (see the cost section) and set up API keys with restrictions and usage alerts.
3. Implement permission flows with rationale screens before the system prompt, graceful fallback when only approximate location is granted, and a clear "tracking on" indicator with an off switch in the rider app.
4. Build the capture service on Android as a foreground service with a persistent notification, and on iOS with background location updates enabled; tune interval, distance filter and accuracy per mode.
5. Add filtering, batching and offline queueing on the device.
6. Build the backend ingestion endpoint, the latest-position store, the history table and the real-time publish channel; enforce that only the assigned customer or dispatcher can subscribe to a rider's position.
7. Implement the live map in the customer app and admin dashboard with marker animation, route polyline and estimated time of arrival.
8. Add geofencing and event capture for pickup, arrival and drop-off, with proof-of-delivery capture at hand-over.
9. Test on real devices and roads: at least three Android brands common in Nigeria, one older iPhone, mixed 3G and 4G, dense urban areas and open roads, with battery drain measured over a full shift.
10. Prepare store submissions with the background location declaration, demo video and prominent disclosure, then submit and expect at least one round of questions.

Battery, accuracy and data: the three trade-offs

Every tracking decision trades battery, accuracy and data against each other, and rider phones are the constraint.

• Battery. GPS radios draw significant power. Reduce drain by using lower accuracy when stationary, larger intervals when idle, distance-based filtering so a parked rider sends nothing, and by stopping tracking automatically when a shift or delivery ends. Educate riders to carry power banks, and detect low battery to switch to a sparser mode.
• Accuracy. Urban canyons, under-bridge routes and indoor markets degrade GPS. Use the platform's fused providers, discard readings with large accuracy radii, and snap positions to roads with a routing service when displaying to customers.
• Data. Frequent updates over mobile data cost riders money if they use personal SIMs. Keep payloads tiny (a few dozen bytes per point), batch when possible, and consider providing data allowances or company SIMs.
• Device diversity. Budget Android phones common among riders vary widely in GPS quality and in how aggressively their manufacturers kill background services. Test on the actual models your riders use and provide setup guides for battery-optimisation exemptions.

Geofencing, proof of delivery and location fraud

Geofencing means defining virtual boundaries and reacting when a device enters or exits them. In business apps it powers "rider has arrived" notifications, automatic check-in at customer sites, and alerts when a van leaves a permitted zone. Both platforms offer geofence APIs with limits on the number of active regions, so most apps combine platform geofences for the few critical zones with server-side checks against incoming positions for everything else. Proof of delivery should combine position, timestamp, a photo and, where appropriate, a customer OTP or signature. Storing the location at hand-over is far more useful in a dispute than a full track history. Location fraud is a real operational issue: riders or reps can use mock-location apps to fake positions, claim trips, or appear at a customer site. Defences include detecting mock providers and rooted devices, checking for impossible speeds between points, cross-checking geofence events against proof-of-delivery photos and OTPs, and auditing outliers in the admin dashboard. None is perfect; together they make fraud unprofitable.

What changes for Nigerian businesses

The engineering is universal; the context is local in five ways.

• Addresses are unreliable, pins are not. Many Nigerian addresses are descriptive ("beside the blue church after the filling station"). Combine a map pin with landmark text, and use the customer's locate-once position to set the pin. Your routing and estimated arrival then work from coordinates rather than text.
• Traffic makes estimated arrival honest only if it is live. Static estimates fail in Lagos. Use a routing service with live traffic where budget allows, or show the moving dot and let the customer judge.
• Rider phones are the weak link. Low-end devices, aggressive battery optimisers and personal data plans all argue for sparse, batched updates and for company-provided phones or data allowances on large fleets.
• Staff tracking needs consent and limits. Tracking field reps during work hours is common, but the Nigeria Data Protection Act 2023 requires a lawful basis, transparency and proportionality. Track only during defined hours, tell staff exactly what is recorded, and set retention limits. Confirm obligations with the Nigeria Data Protection Commission.
• Map costs are in dollars. Google Maps Platform bills in US dollars with a free usage allowance; Mapbox similarly. Exchange-rate moves can double a map bill in naira terms. Restrict keys, cache results, and consider open-source map tiles for internal dashboards.

Example (hypothetical): a Kano distributor's van and rep tracking app

Example (hypothetical): a fast-moving consumer goods distributor in Kano runs eight vans and fourteen sales reps who visit retailers across the city and nearby towns. Management wants to know where vans are, confirm that reps actually visited assigned retailers, and give large retailers a delivery ETA. The tracking design chosen:

• Vans: driver app in background mode during trips, with trips started and ended explicitly; positions every 30 seconds while moving, none when stationary; plus a hardware tracker in each van as a backup because driver phones were unreliable.
• Reps: no continuous tracking. Instead, a visit check-in that captures a locate-once position, time and a shelf photo at each retailer, with a server-side geofence check against the retailer's stored coordinates.
• Retailers: a lightweight customer view showing the assigned van's live position only while their delivery is active.
• Fraud controls: mock-location detection, impossible-speed flags and a weekly outlier report in the admin dashboard.
• Maps: commercial map SDK in the customer-facing screens; open-source tiles for the internal dashboard to control dollar costs.

The design point is that only the vans needed background tracking; the reps' business question ("did you visit?") was answered with locate-once check-ins, which cut battery complaints, permission friction and cost.

How much does GPS tracking cost, including maps?

GPS tracking is a substantial module whose cost depends mainly on the tracking mode. The figures below are indicative 2026 ranges; actual quotes vary with scope, vendor and exchange rate. Compare two or three written quotations on identical scope and ask vendors to state the assumed update frequency and map provider.

Recurring costs: map, geocoding and routing API usage in US dollars (free allowances exist; verify current pricing and set alerts), hosting for the ingestion and real-time services (indicatively ₦150,000–₦800,000+ per year on a VPS or cloud, more at scale), and maintenance at roughly 15–25% of the module's build cost per year, because OS location rules change yearly. A delivery or logistics app with background tracking, payments and dispatch dashboard typically sits in the indicative medium to complex band for Nigerian apps (₦5,000,000–₦15,000,000 and above).

Mistakes to avoid

• Requesting background location from customers. It is unnecessary, invites store rejection and destroys trust. Customers only need to see a rider, not be tracked.
• Tracking riders around the clock. Start and stop tracking with shifts or deliveries. Continuous tracking drains phones, breaches proportionality and invites staff resentment.
• Sending every raw reading to the server. Filter and batch on the device; otherwise you pay for noise in data, battery and hosting.
• Testing only on the developer's phone. Rider fleets run on budget Android devices with aggressive battery managers; test on those.
• No offline queue. Riders pass through dead zones daily; positions must buffer and flush.
• Ignoring store declarations. Google Play's background location review is strict; submit the declaration, video and disclosure with the first build.
• Unrestricted map API keys. Leaked keys generate dollar bills you cannot reverse. Restrict by app and set quotas.
• Trusting positions blindly. Build mock-location and impossible-speed checks before paying incentives based on location.

Conclusion

Building GPS tracking into an app starts with choosing the least intrusive mode that answers the business question: locate once for addresses and check-ins, track while in use for customers watching a delivery, and background tracking only for riders, drivers and vehicles during active work. From there the work is permissions and store declarations, a filtered and batched pipeline from phone to map, deliberate trade-offs between battery, accuracy and data, and fraud and consent controls that fit Nigerian operations. Costed honestly, including dollar-denominated map usage, tracking is a medium-to-large module that pays for itself when the live position is genuinely part of the service. If you are planning a delivery, logistics, ride or field-service app and want the tracking mode, pipeline and store compliance designed correctly from the start, Linestech builds location-aware mobile apps for Nigerian businesses and can help you scope the right approach.

Frequently asked questions

Can my app track a rider when the phone screen is off?

Yes, with background tracking: a foreground service with a persistent notification on Android and "Always" location authorisation with background location mode on iOS. Both stores require a clear justification and prominent disclosure, and manufacturers' battery optimisers may still suspend the service unless the user exempts the app.

Do I need Google Maps to build GPS tracking?

No. Reading the device's position uses the operating system's location services, not a map provider. You need a map provider only to display positions, geocode addresses and compute routes. Google Maps Platform and Mapbox are common choices billed in US dollars; open-source tiles with MapLibre suit internal dashboards.

How often should the app send location updates?

Every 3 to 5 seconds while a customer is actively watching a delivery, every 15 to 60 seconds for fleet monitoring, and nothing while stationary. Use distance-based filtering and batching so the interval adapts to movement and network conditions. Higher frequency costs battery, data and hosting without improving the customer's experience much.

Is it legal to track staff with a mobile app in Nigeria?

It can be, with a lawful basis, transparency and proportionality under the Nigeria Data Protection Act 2023: track only during work hours or active tasks, tell staff exactly what is collected and why, limit who can view it, and set retention periods. This is not legal advice; confirm requirements with the Nigeria Data Protection Commission or a qualified professional.

How do we stop riders faking their location?

Detect mock-location providers and rooted devices, flag impossible speeds between points, require proof of delivery (photo, OTP, position at hand-over), cross-check geofence events against those proofs, and review outliers regularly. No single check is decisive; the combination makes fraud impractical.

Should we use phone tracking or a dedicated vehicle tracker?

Phones are cheaper to deploy and tie tracking to the person and the order; dedicated trackers are more reliable for vehicles because they draw vehicle power and cannot be switched off by a driver. Many Nigerian fleets use both: phones for the app workflow and trackers as a tamper-resistant backup.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Nigeria Data Protection Commission (NDPC)
• Google Search Central Blog
• Node.js documentation