A delivery tracking app is a promise about how wrong you are willing to be.
Every delivery tracking app shows a moving dot and an arrival time, and every one of them is guessing. The interesting question is not how to draw the map. It is how narrow a window you can promise without being wrong often enough that people stop believing it, and that question is answered by how often a driver's phone reports in. The same tension runs through field service apps generally.
Underneath that sit two constraints you do not control: what iOS will let you do in the background, and what a phone battery will survive across a shift. Both are worth understanding before the first screen is drawn, because both change the shape of the app.
See what the reporting rate costs youThe short version
Pick a reporting rate first, then promise a window you can keep.
A tracking app has one setting that decides everything downstream: how frequently the driver's device reports its position. Report constantly and the window is tight and the phone is dead by three. Report at each stop and the phone lasts all day and the window is an hour. Everything else in the build, the map, the notifications, the customer page, is arranged around that trade.
The second decision is what the customer sees. A live dot invites people to watch, and watching makes fifteen minutes feel like an hour. A window with a notification when the driver is two stops away usually produces happier customers and fewer calls, using less of everything.
How often the phone reports, and what it costs
There is no correct answer here, only a trade you make on purpose or by accident. What follows is the shape of it.
Distance beats time
Sampling every thirty seconds wastes most of its readings in traffic and misses the moment a van clears a junction. Reporting on significant movement, with a time ceiling so a stationary van still checks in occasionally, gets a better picture for a fraction of the power.
The customer does not need your raw feed
What reaches the person waiting should be derived, not raw. Stops remaining, an arrival window, and an alert when the van is close. Passing through every position fix makes the app feel precise and makes every small delay visible, which is the opposite of reassuring.
Try it
How often you ask for location decides everything else
The delivery window you can promise is a direct function of how often the phone reports in, and so is whether the phone survives the shift.
Honest window: 5 minutes
Manageable across a shift with a car charger.
What iOS requires before you can track anyone
Background location is the permission Apple treats most carefully, and the rules are specific rather than a matter of taste. Before any authorisation request, the app has to declare its purpose strings in its information property list. NSLocationWhenInUseUsageDescription is required when the app requests either when in use or always authorisation, and NSLocationAlwaysAndWhenInUseUsageDescription is required for always. Apple's own documentation warns that authorisation requests fail immediately if the required keys are not present.
There is a sequencing rule people trip over. An app that already holds when in use authorisation can make a separate request for always authorisation later, but it can make that request only once. There is no second chance, so the moment you ask matters: ask when the driver is starting a run and the reason is obvious, not at first launch.
The review guidelines add the other half. Apps may only use background services for their intended purposes, and location is named as one of them. Tracking a driver during a delivery run is squarely within that. Tracking the same phone at the weekend is not, and the purpose string you wrote is the thing you will be held to.
Apple Developer, requesting authorization to use location services
The driver is a person, not a sensor
It is worth saying plainly, because it changes design decisions. An app that reports a driver's position continuously is a surveillance tool as much as a logistics tool, and drivers know it. The ones that get used without resentment tend to share three habits.
They track the run, not the person: location reporting starts when a run starts and stops when it ends, visibly, with a control the driver can see. They show the driver the same information the customer sees, so nobody is being measured against a number they cannot check. And they do not turn the feed into a performance metric without saying so.
Apple's guidelines require that purpose strings clearly and completely describe your use of the data, and that apps collecting user data secure consent and provide an accessible way to withdraw it. Written for the App Store, but it is also just a good description of an app people will accept.
Arrival is a separate record from tracking
Tracking answers where the van is. It does not answer whether the parcel arrived, who took it, or what condition it was in, and conflating the two is how a delivery gets marked complete because the phone entered a geofence.
The arrival record wants its own fields: a timestamp, a name or signature, a photo where the parcel was left, and a reason code when it was not delivered. That last one carries more weight than it looks, because attempted deliveries are where disputes start. A proof of delivery app is the same idea taken seriously.
For a business running its own drivers rather than a national network, the two halves usually live in one app, and the scope stays small. A local delivery app with twenty drops a day needs a fraction of what a parcel carrier needs, and building for the carrier problem is the most common way these projects get heavy.
What each approach gives the person waiting
| Option | Live position | Honest arrival window | Proof of arrival | Phone survives the shift |
|---|---|---|---|---|
| A text when the driver leaves | No | roughly | No | Yes |
| Driver phones ahead | No | yes, if they remember | No | Yes |
| Continuous tracking, always on | Yes | Yes | separate problem | No |
| Stop-based updates plus an alert | approximate | Yes | Yes | Yes |
| A tracking app you build | Yes | Yes | Yes | your choice, made on purpose |
Building one around your own runs
Carrier platforms are built for national networks, priced for them, and shaped by them. A florist with three vans, a pharmacy doing same-day drops, or a builders merchant running deliveries to sites needs perhaps a tenth of that, and needs one or two things the platform does not do at all: a delivery that requires a signature from a named person, a drop that cannot happen before a site opens, a route that has to end at a depot.
Newly is an AI app builder. You describe the app you want, including how your runs are actually planned, and it builds and ships a real mobile app you own. Plans start at $25 a month, there is no free plan, and iOS builds ship through App Store Connect. It is not a logistics platform and does not pretend to route-optimise a fleet. It is what you use when the platform you tried is built for a scale you do not have.
Before designing any of it, get familiar with what the hardware will and will not do, because almost every disappointment in this category traces back to an assumption about location while a driver is moving that was never true.
Questions people ask about delivery tracking apps
It is two connected things: a driver app that reports position and records what happened at each stop, and a view for the person waiting that turns those reports into an arrival window. The second one is what customers mean by tracking, and it is derived from the first rather than being a direct feed of it.
Describe a normal run, awkward drops included
Write down how a delivery day actually goes, including the stop that always needs a phone call, and build the tracking around that.
Start building