A local delivery app is two apps and the driver has the hard one.
A local delivery app built by the business that makes the goods is a different animal from a marketplace, and copying the marketplace is how these projects go wrong. You are not matching supply to demand across a city. You have two drivers, a van, a cut-off time and a list of drops that has to be in the right order by ten. The software that serves that is small and specific, and very little of it is the customer screen. If the goods come out of a kitchen, the surrounding decisions sit on the restaurant app builder page.
This page covers what the driver app does that the customer view does not, why the order of the drops matters more than the distance between them, when background location is justified and what iOS demands before it grants any, what the handover has to record, and why a marketplace's economics are not yours.
See what the drop order does to the windowsThe short version
Route order is the product, not the map.
For a business running its own drivers, the hard problem is not drawing a line on a map. It is deciding which drop goes first when four of them have windows, one is a school that shuts its gate at two, and the van holds one load. Shortest distance is a tiebreaker, not the goal.
The second thing is the record at the door. Delivered is not a status somebody taps, it is a fact with a time, a place and a name attached, because the only moment anyone looks at it is when a customer says it never arrived.
Route order beats distance, and batching is where it shows
Batching is putting several drops in one run so a driver leaves once instead of four times. It is also where the promise to each customer holds or breaks, because the fourth drop pays for the first three. The moment you batch, the sequence becomes the decision and distance becomes an input to it.
Nearest first feels efficient and it is the wrong default. It sorts by the driver's convenience rather than the customer's window, and the drop with the tightest deadline ends up last because it happens to be furthest away. Sorting by promised time and letting distance break ties produces slightly more driving and considerably fewer late deliveries.
The sequence also has to respect the load. A van packed front to back has an unloading order whether the route agrees or not, and a route that asks a driver to climb over three crates to reach the second drop will be ignored. If loading order and route order disagree, the driver fixes it silently at the kerb, and your arrival times stop matching reality.
Try it
Four drops, one van, two ways to sort them
Each leg is held at a fixed number of minutes so the only thing changing is the order. Minutes at the door are yours to set. Nothing here is a benchmark, it is the arithmetic a dispatcher does in their head.
arrives at 9 min, promised by 75 min
arrives at 20 min, promised by 60 min
arrives at 34 min, promised by 35 min
arrives at 51 min, promised by 50 min
1 of 4 drops miss the window
Shortest leg first is the driver sorting by convenience. The tightest deadline waits because it happens to be furthest away. Push the time at each door up and watch which order survives it.
The driver app is not the customer app in a different colour
These are two products sharing a database. The customer has one question, asked repeatedly: where is it and when does it get here. The driver has a shift: a list, a next action, a way to say something went wrong, and a way to finish. Build the driver side first, because it produces every fact the customer side displays.
The driver app is used one handed, outdoors, in the rain, sometimes with gloves, usually on a phone clipped to a windscreen. That argues for large targets, one screen for the current drop and no flow needing two hands or careful aim. It also argues for working offline. A basement car park has no signal, and a driver who cannot mark a drop done will finish the run and mark six at once, at which point every timestamp you hold is fiction.
What the customer view should not promise
A live map of the driver is the feature everyone asks for and the one that generates the most complaints, because it invites a customer to watch a dot go the wrong way down a one way street. A status and an honest window are usually the better product. The tradeoff behind that is the whole subject of the delivery tracking app page.
Background location, and what iOS wants before it gives you any
Tracking a driver for the length of a shift means location while the app is in the background, and that is allowed. Apple's review guidelines list location among the permitted background uses at 2.5.4, which says multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, and so on. Dispatching deliveries is such a purpose. Following the same person after the shift ends is not.
What trips builds up is the plumbing rather than the policy. Core Location needs a purpose string in the app configuration before it will even ask: NSLocationWhenInUseUsageDescription when you request When in Use, and NSLocationAlwaysAndWhenInUseUsageDescription when you request Always. Authorization requests fail immediately if the required keys are not present, which presents as a silent bug rather than a permission problem. An app holding When in Use can later ask for Always, but per Apple's Core Location documentation you can make that request only once, so spend the one prompt at a moment the driver understands.
Consent is the other half of it. Guideline 5.1.1(ii) requires apps that collect user data to secure consent, to provide an accessible way to withdraw it, and to ensure your purpose strings clearly and completely describe your use of the data. For a driver app that means saying, in the string and in writing, that location is collected during a shift, for dispatch, and stops when the shift does. Then making it actually stop.
App Store Review Guidelines, 2.5.4 background services and 5.1.1(ii) data collection
The handover record, and why a marketplace's numbers are not yours
Delivered has to be a record, not a tick. Who took it, at what time, at what location, and what evidence exists. It costs seconds at the door and it is the only thing that settles an argument three weeks later, which is the entire case made on the proof of delivery app page.
Failed drops deserve the same discipline and almost never get it. Nobody home, gate locked, wrong address, customer refused: four different outcomes with four different next steps. An app offering only delivered or not delivered pushes all of that into a phone call the office will not remember by Thursday.
Then the economics, which is where copied plans die. A marketplace runs on density: many merchants, many drivers, enough orders per square mile that a driver is rarely empty. You have none of that. Your driver costs the same whether the van carries two drops or nine, so your cost per drop falls with basket size and route density rather than with demand. The levers are minimum order value, cut-off times and which days you deliver. Any plan that starts by being the Uber of something has borrowed a cost structure it does not have.
What each way of running local delivery gives you
| Option | You keep the customer | Driver sees the whole run | Live location without asking | What it costs |
|---|---|---|---|---|
| A national marketplace | No | No | Yes | commission, set by them |
| Phone calls and a group chat | Yes | in their head | No | nothing, until it goes wrong |
| A shared spreadsheet | Yes | Yes | No | nothing extra |
| An off the shelf courier platform | Yes | Yes | Yes | per driver per month |
| An app you build | Yes | Yes | Yes | your build and your hosting |
Building one around your own drivers
Courier platforms are priced per driver per month and built for companies whose product is delivery. If delivery is the last twenty minutes of a product you already make, most of that software is for somebody else, and the parts you actually need are the ones it will not bend on: your cut-off, your zones, your rule that the Tuesday run goes north and nothing else does.
Newly is an AI app builder. You describe the app, including how the van is loaded and in what order the run goes, 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 delivery platform and does not pretend to be one: no driver network, no dispatch engine to buy, and no card processing, since taking money means your own provider such as Stripe or Apple Pay under your own account.
Before designing anything else, get straight what a phone can and cannot tell you about driver location, because most of the disappointment in this category is an assumption about accuracy and battery life that was never true.
Questions people ask about local delivery apps
It is software for a business delivering its own goods with its own drivers, rather than a marketplace matching couriers to strangers. It comes in two connected pieces: a driver app holding the run, the sequence and the handover record, and a customer view answering one question about arrival. The driver side produces every fact the customer side displays, so it gets built first.
Describe the run your drivers actually do
Write down the cut-off, the zones, the order the van gets loaded in and what has to be recorded at the door, then build the app around that list.
Start building