In a taxi booking app the form takes a week. Dispatch takes the rest of the year.
Every taxi booking app demo shows the same thing: a pin, a destination, a button. That part is a week of work. What decides whether the app survives a Friday night is what happens in the ninety seconds afterwards, when a job has to reach a driver who is willing to take it, and the passenger is watching a screen that says nothing. It is the same sort of problem a booking and scheduling app builder has to solve, with the twist that the resource moves.
This page is about dispatch, the difference between an advance booking and an immediate job, why a street address is not a pickup point, and the licensing question you have to answer locally rather than generally.
See how a job reaches a driverThe short version
An offer is a job nobody has taken yet, and the rule you pick shapes the fleet.
A dispatch system has one central rule: who gets offered the job, for how long, and what happens when they do not answer. Every driver in your fleet will work out that rule within a fortnight and behave accordingly, so choosing it casually means choosing your fleet's behaviour casually.
The second thing to model properly is time. An immediate job needs a driver now and fails loudly. An advance booking needs a driver in eleven hours and fails silently at six in the morning when nobody has been assigned. Same table, completely different failure.
How a job reaches a driver
The offer is the core of dispatch and it is a state machine, not a notification. A job is offered, and then it is accepted, declined, or it times out, and each of those has to do something specific.
A time-out is a decision
Silence from a driver has to mean something. If an unanswered offer simply sits there, the passenger waits on a job that has been assigned to somebody who is asleep. Twenty seconds, then move on, and record the non-answer, because a driver who never answers is information the controller needs.
What happens when nobody takes it
Every dispatch system eventually runs out of drivers, and this is the case nobody designs. The honest answers are to escalate to a human controller, or to tell the passenger plainly that there is nothing available. What does not work is leaving the job in an offered state forever while the app shows a spinner.
Try it
Who gets offered the job
This one rule decides how your fleet behaves. Pick it deliberately, because drivers will optimise against whatever you choose.
Fast and usually close
The pragmatic middle. Keeps distance roughly honest without waiting on one person.
Where the passenger actually is
A pickup is a physical place a car can stop, and an address is often not that. Hotels have a side entrance. Stations have four. A house on a dual carriageway can only be approached from one direction. Every experienced controller knows a list of these, and that list is worth more than any routing feature you could build.
So the app should let a pickup carry a note that sticks to the location rather than to the booking, and should show it to the driver automatically the next time anyone is picked up there. This is the cheapest feature in the whole system and the one drivers notice first.
On the technical side, location permission is worth handling carefully because iOS is strict. The purpose strings have to be declared before any request is made, NSLocationWhenInUseUsageDescription for when in use or always and NSLocationAlwaysAndWhenInUseUsageDescription for always, and Apple's documentation warns that requests fail immediately if the keys are absent. An app already holding when in use authorisation can escalate to always, but only once, so the moment you ask matters more than most people expect.
Apple Developer, requesting authorization to use location services
Taking money, and the rule people get wrong
A ride is a service consumed in the real world, which puts it squarely inside Apple's rule for goods and services outside the app. Apple's guidelines say that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase, such as Apple Pay or traditional credit card entry. So the App Store commission does not apply to fares, and card entry is the expected route rather than a workaround.
What Apple does not give you is the payment itself. Newly builds and ships the app; it does not process cards. Taking fares means an account with a payment provider, and their rules on refunds and chargebacks become your rules.
There is a separate decision about quoted versus metered fares, and it is worth making early because it changes the data model. A quote is a promise made before the journey and has to survive a longer route. A meter is a calculation made after. An app that stores one number for both cannot explain a difference to anybody.
Apple App Store Review Guidelines, 3.1.3(e) goods and services outside of the app
Licensing is local, and it can reach the software
It is tempting to assume that licensing applies to cars and drivers and leaves the software alone. That is not safe to assume, because in at least one major market the dispatching business itself is licensed.
In New York City, a business that dispatches more than 10,000 for-hire vehicle trips a day must hold a high-volume for-hire service licence, and the Taxi and Limousine Commission treats that licence as a type of base licence, so no separate base licence is needed to dispatch trips. The threshold is high and most operators will never approach it, but the principle is the one to take away: dispatch can be a licensed activity, not merely a technical one.
Outside that example we did not verify a rule that applies to dispatch software generally, and it would be wrong to imply one. Licensing of vehicles, drivers and operators is set locally and varies a great deal. Ask the authority where you operate before you build, not after, and treat anything you read in a summary like this one as a prompt to check rather than an answer.
What each way of running jobs gives a controller
| Option | Job reaches drivers fast | Non-answers recorded | Advance bookings safe | Pickup notes reused |
|---|---|---|---|---|
| Radio and a paper book | yes, one at a time | No | if somebody checks the book | in the controller's head |
| Group chat with drivers | Yes | No | No | No |
| Off-the-shelf dispatch platform | Yes | Yes | Yes | sometimes |
| A taxi app you build | Yes | Yes | Yes | Yes |
Building one around your own fleet
Dispatch platforms are usually priced per vehicle per month and shaped around a ride-hailing model: strangers, ratings, surge, an app on both sides. A lot of operators are not that. A local firm with fifteen cars and forty account customers, a hospital contract with wheelchair-accessible vehicles, a firm whose busiest hours are school runs booked a term in advance.
Newly is an AI app builder. You describe the app you want, including how your jobs are actually allocated, 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 does not process card payments and it is not a dispatch platform. It is what you use when the platform assumes a business you do not run.
Design one thing before the rest: what the passenger sees while the job is being offered. Getting that honest is worth more than any map animation, and it depends on reading pickup location accurately in the first place. For anything that looks like a shared ride rather than a hire, the shape is closer to a carpool app, and if you are matching independent drivers to customers rather than dispatching your own, you are building a marketplace app with different problems.
Questions people ask about taxi booking apps
Dispatch. The booking form is a week of work, but deciding which driver is offered a job, for how long, what a non-answer means, and what happens when nobody accepts is the part that determines whether the app works on a busy night. Drivers will adapt to whatever rule you pick, so pick it deliberately.
Describe how your jobs actually get allocated
Write down who decides which driver takes a job and what happens when nobody does, and build the dispatch around that rather than around a template.
Start building