How do you stop double bookings in a booking app?

By treating the slot, not the calendar entry, as the thing being reserved, and by checking availability at the moment of confirmation rather than at the moment the form was opened. Two customers can load the same page at the same time, so the guard has to sit on the write, not the read. In practice that means the booking is created only if the slot is still free at that instant, and the second request is rejected and offered alternatives.

What should a cancellation policy record?

When the booking was made, when it was cancelled, who cancelled it, and which policy applied at the time. Policies change, so storing only a link to the current policy makes old disputes unanswerable. Recording the policy version against the booking is what lets you explain a charge months later.

Does Apple take a cut of bookings taken in an app?

Not for services delivered in the real world. Apple's App Store Review Guidelines say that if your app enables people to purchase physical goods or services consumed outside the app, you must use a purchase method other than in-app purchase, such as Apple Pay or card entry. A haircut, a table or a repair visit falls in that category, so the in-app purchase commission does not apply.

Should a booking app work offline?

Reading should, writing should not. Staff need to see today's diary in a basement or a van with no signal, so the current day should be readable from a cached copy. Creating a booking offline is dangerous, because the slot cannot be checked against anyone else, and two devices can both think they got it.

Is it worth building your own booking app?

It is worth considering when your rules do not fit a packaged product: services with different durations per staff member, buffers that depend on the previous job, deposits that only apply above a certain value, or an approval step before a booking is confirmed. If you are running a spreadsheet alongside the booking tool you already pay for, the tool does not fit.

Articles · App ExamplesUpdated September 2026

A booking management app is the guard, not the grid.

Any booking management app can draw a week and let people click a box. The work is in what it refuses: the slot already taken three seconds ago, the 90 minute job dropped into a 30 minute gap, the staff member who cannot actually do that service. Getting those refusals right is most of what a booking and scheduling app builder is really for.

This page is the operator side: where the availability check has to sit, what a cancellation has to record to be defensible later, and what actually happens to your money when a booking is paid for in an app.

See where the check has to sit

The short version

Check at the write, store the policy, not a link to it.

Two rules carry most of the weight. Availability is checked when the booking is created, not when the page was loaded, because that gap is where double bookings are born. And the cancellation policy in force is copied onto the booking, because policies change and disputes arrive late.

The pleasant surprise is the money. Services consumed in the real world are explicitly outside Apple's in-app purchase rules, so the commission people fear does not apply to a haircut or a table.

Where the availability check has to sit

Almost every double booking has the same cause, and it is not carelessness. The app checked availability when the customer opened the page, then the customer spent two minutes typing their phone number. In those two minutes somebody else took the slot. The check was real. It was just answered before the question mattered.

The fix is to move the check onto the write. The booking is created only if the slot is still free at that instant, and if it is not, the request fails and the customer is offered the next times that are. That is unglamorous and it is the whole difference between a diary you trust and one you check by phone.

Reserve the slot, not the calendar entry

If bookings are just rows with a start time, two overlapping rows are perfectly valid data. If the thing being reserved is a slot belonging to a person on a day, the second attempt has something concrete to collide with. The shape of the data decides whether the rule is even expressible.

Try it

Two customers, one slot, three seconds apart

Pick where your booking app checks availability, and see what the second customer experiences.

Both bookings are created, quietly

Both customers saw the slot as free, because both of them did. The second submission overwrites or duplicates the first, and the app reports success to a customer who does not have a booking.

The rules worth writing down before you build

Rule	Why it exists	Refuse the booking?
Slot is still free at the moment of confirmation	The only guard that actually prevents a double booking.	Hard stop
The staff member can perform that service	A slot is not availability if the person in it cannot do the job.	Hard stop
Buffer after the previous job is respected	Clean-down, travel, or writing up the last appointment.	Warn only
Service duration comes from the service, not the grid	A 90 minute job should not be bookable into a 30 minute gap.	Hard stop
Deposit taken when the booking value is above your threshold	The no-show cost you actually care about.	Warn only
The policy version in force is stored on the booking	Lets you explain a cancellation charge months later.	Warn only

Cancellations are a record, not a status

Flipping a booking to cancelled throws away the thing you will need: when it was made, when it was cancelled, by whom, and which policy applied at that moment. Policies get edited. If the booking only points at the current policy, a dispute from two months ago cannot be answered honestly, because the document has changed underneath it.

Copy the policy terms onto the booking when it is created. It is a few extra fields and it is the difference between explaining a charge and arguing about it.

No-shows deserve their own state rather than being folded into cancelled. They have different consequences, and you almost certainly want to count them per customer. That is the same reasoning behind treating reminders seriously, which the appointment reminder app side of this problem exists to solve.

What Apple actually takes from a booking

The commission most people worry about does not apply here. Apple's App Store Review Guidelines are explicit: if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use a purchase method other than in-app purchase, such as Apple Pay or traditional credit card entry.

A table, a haircut, a repair visit and a delivery are all consumed outside the app. So the question is not whether you can avoid the in-app purchase cut, it is which payment provider you use, and that is a decision you make outside the app builder. This is the same rule that shapes how a salon booking app handles deposits.

Apple App Store Review Guidelines, 3.1.3(e)

The confirmation is a document, not a message

A booking confirmation does two jobs. It tells the customer the booking exists, and it puts the appointment somewhere they will see it again. Most booking apps do the first and skip the second, then wonder why the no-show rate will not move.

The second job is a solved problem. iCalendar, defined in RFC 5545, is the format every calendar application understands, and an attached calendar file puts your appointment into the customer's own diary with a single tap. The fields that matter are the ones people forget: a stable unique identifier so an update replaces the original rather than adding a second entry, an explicit time zone, and a sequence number that increments when you change the booking.

Get the identifier right and a reschedule moves the entry the customer already has. Get it wrong and every change leaves another appointment in their calendar, which is worse than sending nothing, because now the customer has three possible times and trusts none of them.

RFC 5545, Internet Calendaring and Scheduling Core Object Specification

Building one around your own diary

Packaged booking products assume a shape: fixed service durations, one buffer, one deposit rule, one approval flow. Businesses that do not match that shape end up keeping a parallel spreadsheet, which is the clearest evidence the product does not fit.

Newly is an AI app builder: you describe the app, including the rules above, 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 booking product and does not compete feature for feature with one. It is what you reach for when the booking product you tried cannot express your rules.

Decide early who is allowed to see and change a booking, because that shapes the data model rather than the screens. It is worth reading up on who can see and change a booking before you draw a single screen.

Questions people ask about booking apps

A booking management app is the operator side of a diary. It holds the services you offer, how long each takes, who can perform them, when they are available, and every booking, cancellation and no-show against that calendar. The customer-facing booking form is only the front door; the management app is where the rules live.

Describe the diary you actually run

Write down the rules, including the awkward one nobody else supports, and build the booking app around them.

Start building